> 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). # Migrer et restaurer Migrez ou restaurez un serveur PowerShell Universal, en couvrant les données de configuration, les types de base de données, appsettings.json et la migration du coffre de secrets. Il est souvent souhaitable de migrer une configuration de serveur PowerShell Universal d'une machine à une autre. Cela peut être dû à un changement d'infrastructure ou à une restauration à partir d'une sauvegarde de données. Cela peut être pour des mises à niveau du système d'exploitation ou pour la maintenance générale du centre de traitement 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 pourrait ne pas être nécessaire 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. Ceux-ci comprennent des fonctionnalités telles que les API, les scripts et les applis. Le répertoire entier est nécessaire au fonctionnement de la configuration du système cible. Vous pouvez copier le dossier manuellement ou au moyen de 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épendra du type de base de données utilisé. ### SQLite Vous devrez copier le fichier de base de données SQLite à l'emplacement de base de données configuré ou par défaut. Dans une installation par défaut, il s'agira de `%ProgramData%\UniversalAutomation\database.db`. Le compte de machine ou le compte de service cible 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 restaurez à partir d'une sauvegarde de données, 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 Comme ces bases de données sont stockées à l'extérieur du serveur PowerShell Universal, vous n'avez pas besoin d'effectuer une migration de la base de données elle-même. Vous devrez vous assurer que le serveur cible a un accès réseau à l'hôte SQL. Si vous restaurez à partir d'une sauvegarde de données, 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 vers 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 d'API et 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 il est peu probable que vous ayez besoin d'effectuer cette action lors d'une restauration. ## Coffres de secrets PowerShell Universal comprend 3 coffres de secrets intégrés qui pourraient devoir être migrés. 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 ayez à effectuer ces opérations de restauration, à moins que les coffres de secrets 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, en utilisant un chiffrement symétrique. Une clé de chiffrement par défaut est incluse dans 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 propre à l'utilisateur pour s'assurer que les 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 `BuiltInLocalVault` est disponible uniquement sur Windows et utilise le Gestionnaire d'identifiants pour stocker les secrets. Vous devrez recréer ces secrets dans le magasin du Gestionnaire d'identifiants sur le nouveau système. Dans le Gestionnaire d'identifiants, vous trouverez les secrets PowerShell stockés avec un préfixe `ps:`. Bien qu'il ne soit pas possible d'extraire les identifiants directement à partir de l'interface du Gestionnaire d'identifiants, vous pouvez utiliser directement les modules Secret Management. Pour récupérer les 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 faire l'inverse et appeler `Set-Secret`. Notez que ces commandes doivent être exécutées en tant que compte de service exécutant PowerShell Universal afin de les stocker correctement dans le compte du Gestionnaire d'identifiants de l'utilisateur. ## Authentification Certains types d'authentification nécessiteront une configuration à l'extérieur de PowerShell Universal. À moins que vous ne déplaciez la machine exécutant PowerShell Universal ou que vous 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é (p. ex. 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 pourrait y avoir d'autres ressources que PowerShell Universal utilise sur le système et dont il faut tenir compte lors de la migration ou de la restauration des serveurs. Habituellement, 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 * Permissions du système de fichiers * Configuration du proxy * Certificats * Clés SSH ou identifiants Git * Paramètres DNS ## Fichiers d'application Une fois toutes les étapes suivantes effectuées, vous pouvez maintenant installer PowerShell Universal sur le nouveau serveur. Si vous rétrogradez lors d'une restauration, veuillez consulter la documentation [Rétrograder](/powershell-universal/fr/getting-started/downgrade.md). ### MSI \ Kestrel Le paquet 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://devolutions.net/download-center/powershell-universal/) et exécutez-le. Nous recommandons d'utiliser exactement la même version que celle du serveur source. Pendant l'installation du MSI, laissez tous les paramètres par défaut. Nous recommandons de laisser le compte de service vide et de décocher la case indiquant de démarrer le service PowerShell Universal après la fin de l'installation. 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 pourriez rencontrer des problèmes découlant des différences de configuration entre les deux systèmes. Voici les endroits où chercher plus d'information. ### Observateur d'événements Si le service démarre et s'arrête, il peut y avoir un problème avec l'accès à la base de données. Nous recommandons de consulter le journal Application dans l'Observateur d'événements. PowerShell Universal signalera deux erreurs d'application qui comprendront .NET dans le nom. La deuxième des deux erreurs fournira une exception lisible par un humain 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 recueillir plus d'information sur les problèmes liés à l'installation. ### Notifications Après avoir migré le service, vérifiez s'il y a des notifications d'erreur qui pourraient 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.devolutions.net/powershell-universal/fr/getting-started/migration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.