> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/powershell-universal/fr/getting-started/migration.md). # Migration et restauration Il est souvent souhaitable de migrer la configuration d'un serveur PowerShell Universal d'une machine à une autre. Cela peut être dû à un changement d'infrastructure ou à une restauration à partir d'une sauvegarde. Cela peut également concerner des mises à niveau du système d'exploitation ou une maintenance générale du centre de données. Ce document explique les étapes nécessaires pour migrer la configuration de PowerShell Universal vers une autre machine. Nous recommandons d'arrêter le service PowerShell Universal avant d'effectuer la migration ou la restauration. ```powershell Stop-Service 'PowerShellUniversal' ``` Selon le type de migration ou de restauration, il est possible que vous n'ayez pas besoin d'effectuer toutes ces actions. ## Données de configuration Les fichiers de données de configuration sont stockés dans `%ProgramData%\UniversalAutomation\Repository` par défaut. Ils comprennent des fonctionnalités telles que les API, les scripts et les applications. L'ensemble du répertoire est nécessaire au bon fonctionnement de la configuration du système cible. Vous pouvez copier le dossier manuellement ou via PowerShell. Assurez-vous d'inclure tous les sous-répertoires. ```powershell Copy-Item $ENV:ProgramData\UniversalAutomation\Repository \\newServer\C$\ProgramData\UniversalAutomation\Repository -Recurse ``` ## Base de données La migration de la base de données dépend du type de base de données utilisé. ### SQLite Vous devrez copier le fichier de base de données SQLite vers l'emplacement de base de données configuré ou par défaut. Sur une installation par défaut, il s'agit de `%ProgramData%\UniversalAutomation\database.db`. Le compte de la machine cible ou le compte de service devra avoir un accès en lecture et en écriture à ce fichier de base de données. ```powershell Copy-Item $ENV:ProgramData\UniversalAutomation\database.db \\newServer\C$\ProgramData\UniversalAutomation\database.db ``` Si vous effectuez une restauration à partir d'une sauvegarde, vous devrez peut-être [rétrograder](/powershell-universal/fr/getting-started/downgrade.md) le schéma si vous avez mis à niveau la version. ### SQL et PostgreSQL Ces bases de données étant stockées en dehors du serveur PowerShell Universal, vous n'avez pas besoin d'effectuer de migration de la base de données elle-même. Vous devrez vous assurer que le serveur cible dispose d'un accès réseau à l'hôte SQL. Si vous effectuez une restauration à partir d'une sauvegarde, vous devrez peut-être [rétrograder](/powershell-universal/fr/getting-started/downgrade.md) le schéma si vous avez mis à niveau la version. ## Paramètres de l'application Le fichier `appsettings.json` de PowerShell Universal est nécessaire pour fournir les paramètres de serveur appropriés à la plateforme. Par défaut, il est stocké dans `%ProgramData%\PowerShellUniversal\appsettings.json`. Vous devrez le copier sur le nouveau serveur au même emplacement. Ce fichier contient des paramètres de configuration tels que le certificat HTTP, l'authentification, les paramètres de synchronisation git, les options de configuration de l'API et bien plus encore. ```powershell Copy-Item $ENV:ProgramData\PowerShellUniversal\appsettings.json \\newServer\C$\ProgramData\PowerShellUniversal\appsettings.json ``` Les fichiers appsettings.json ne changent pas entre les mises à niveau et vous n'aurez probablement pas besoin d'effectuer cette action lors d'une restauration. ## Coffres de secrets PowerShell Universal inclut 3 coffres de secrets intégrés qui peuvent nécessiter une migration. Le coffre de base de données est inclus dans la migration de la base de données et ne nécessite pas d'étapes supplémentaires. Si vous effectuez une restauration, il est peu probable que vous deviez effectuer ces opérations de restauration, à moins que les coffres de secrets ne soient corrompus. ### PSUSecretStore Le coffre `PSUSecretStore` utilise le [module SecretStore](https://learn.microsoft.com/en-us/powershell/utility-modules/secretmanagement/get-started/using-secretstore?view=ps-modules) de Microsoft. Ce module stocke les secrets sur disque à l'aide d'un chiffrement symétrique. Une clé de chiffrement par défaut est incluse avec les installations de PowerShell Universal. Si la clé a été mise à jour, la nouvelle clé se trouvera dans le fichier appsettings.json que vous avez migré à l'étape précédente. Vous devrez également déplacer le magasin de secrets physique vers le système de fichiers du nouveau serveur. Le module SecretStore utilise un emplacement de stockage spécifique à l'utilisateur pour garantir que les listes de contrôle d'accès (ACL) sont appliquées aux fichiers eux-mêmes. Vous devrez vous assurer de copier le contenu du coffre vers le compte de l'utilisateur qui exécutera PowerShell Universal sur le nouveau système. ```powershell Copy-Item $Env:LOCALAPPDATA\Microsoft\PowerShell\secretmanagement\localstore \\newServer\C$\Users\myServiceAccount\AppData\Local\Microsoft\PowerShell\secretmanagement\localstore ``` ### BuiltInLocalVault Le coffre `BuiltInLocalVault` est uniquement disponible sur Windows et utilise le Gestionnaire d'informations d'identification pour stocker les secrets. Vous devrez recréer ces secrets dans le magasin du Gestionnaire d'informations d'identification sur le nouveau système. Dans le Gestionnaire d'informations d'identification, vous trouverez les secrets PowerShell stockés avec le préfixe `ps:`.
Bien qu'il ne soit pas possible d'extraire les informations d'identification directement depuis l'interface utilisateur du Gestionnaire d'informations d'identification, vous pouvez utiliser les modules Secret Management directement. Pour récupérer des secrets, vous pouvez procéder comme suit. ```powershell Install-Module Micorosoft.PowerShell.SecretManagement Install-Module SecretManagement.JustinGrote.CredMan Register-SecretVault -Name 'BuiltInLocalVault' -ModuleName SecretManagement.JustinGrote.CredMan Get-SecretInfo -Vault BuiltInLocalVault $Secret = Get-Secret -Name 'TestApiKey' -Vault 'BuiltInLocalVault' -AsPlainText ``` Sur le nouveau serveur, vous pouvez effectuer l'opération inverse en appelant `Set-Secret`. Notez que ces commandes doivent être exécutées sous le compte de service exécutant PowerShell Universal afin de les stocker correctement dans le compte du Gestionnaire d'informations d'identification de l'utilisateur. ## Authentification Certains types d'authentification nécessiteront une configuration en dehors de PowerShell Universal. À moins que vous ne déplaciez la machine exécutant PowerShell Universal ou que vous ne changiez les URL accessibles, vous n'aurez pas besoin d'effectuer ces actions. ### OpenID Connect Assurez-vous que les URL de connexion appropriées sont configurées dans votre fournisseur d'identité (par exemple Azure AD ou Okta) si le nom d'hôte du serveur change. Sans URL de connexion correctement configurées, les utilisateurs ne pourront pas se connecter au nouveau système. ### Windows L'[authentification Windows](/powershell-universal/fr/securite/enterprise-security/windows-sso.md) nécessite la configuration d'un SPN pour le compte de service exécutant le service PowerShell Universal. Assurez-vous que ce SPN est en place avant de tenter d'utiliser l'authentification Windows avec le nouveau système. ## Autres ressources et considérations Il peut exister d'autres ressources utilisées par PowerShell Universal sur le système qui doivent être prises en compte lors de la migration ou de la restauration des serveurs. En règle générale, vous n'aurez pas à vous soucier de ces ressources lors d'une restauration, car elles devraient rester les mêmes si la machine n'a pas changé. * Modules PowerShell * Variables d'environnement * Privilèges des comptes locaux * Autorisations du système de fichiers * Configuration du proxy * Certificats * Clés SSH Git ou informations d'identification * Paramètres DNS ## Fichiers de l'application Une fois toutes les étapes suivantes effectuées, vous pouvez maintenant installer PowerShell Universal sur le nouveau serveur. Si vous effectuez une rétrogradation lors d'une restauration, veuillez suivre la documentation [Rétrogradation](/powershell-universal/fr/getting-started/downgrade.md). ### MSI \ Kestrel Le package MSI pour PowerShell Universal installe la plateforme en tant que service Windows qui héberge son propre serveur web appelé Kestrel. Pour installer le service, [téléchargez le MSI](https://powershelluniversal.com/downloads) et exécutez-le. Nous recommandons d'utiliser exactement la même version que le serveur source. Lors de l'installation du MSI, laissez tous les paramètres par défaut. Nous recommandons de laisser le champ du compte de service vide et de décocher la case indiquant de démarrer le service PowerShell Universal une fois l'installation terminée. Une fois l'installation terminée, le service sera créé mais ne sera pas en cours d'exécution. Ouvrez le Gestionnaire de contrôle des services (`services.msc`) et définissez le compte de service pour le service PowerShell Universal. Démarrez le service. ## Débogage des problèmes Lors de la migration d'un service PowerShell Universal, vous pouvez rencontrer des problèmes résultant de différences de configuration entre les deux systèmes. Voici les endroits où chercher plus d'informations. ### Observateur d'événements Si le service démarre puis s'arrête, il peut y avoir un problème d'accès à la base de données. Nous recommandons de consulter le journal des applications dans l'Observateur d'événements. PowerShell Universal signalera deux erreurs d'application incluant .NET dans leur nom. La deuxième de ces deux erreurs fournira une exception lisible par l'utilisateur avec plus de détails. ### Journaux système PowerShell Universal écrira les journaux système dans le répertoire %ProgramData%\PowerShellUniversal. Recherchez les chaînes commençant par `[ERR]` pour obtenir plus d'informations sur les problèmes liés à l'installation. ### Notifications Après avoir migré le service, vérifiez s'il existe des notifications d'erreur susceptibles d'indiquer une mauvaise configuration du système. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.devolutions.net/powershell-universal/fr/getting-started/migration.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.