Share via

Migrer les paramètres des applications

Un fichier de.xml personnalisé peut être créé pour migrer des paramètres d’application métier spécifiques ou pour modifier le comportement de migration par défaut de l’outil de migration d’état utilisateur (USMT). Pour que ScanState et LoadState utilisent ce fichier, le fichier .xml personnalisé doit être spécifié sur les deux lignes de commande.

Cet article explique comment créer un fichier de.xml de migration personnalisé qui migre les paramètres d’une application qui n’est pas migrée par défaut à l’aide MigApp.xmlde . Les paramètres doivent être migrés après l’installation de l’application, mais avant que l’utilisateur n’exécute l’application pour la première fois.

Cet article ne contient pas d’informations sur la migration des applications qui stockent des paramètres dans un magasin spécifique à l’application, mais uniquement les applications qui stockent les informations dans des fichiers ou dans le Registre. Il ne contient pas non plus d’informations sur la migration des données créées par les utilisateurs à l’aide de l’application. Par exemple, si l’application crée des fichiers.doc à l’aide d’un modèle spécifique, cet article ne décrit pas comment migrer les fichiers et modèles.doc eux-mêmes.

Avant de commencer

Un ordinateur de test qui contient le système d’exploitation des ordinateurs sources doit être identifié. L’ordinateur de test doit également avoir les applications dont les paramètres doivent être migrés. Par exemple, si vous effectuez une migration de Windows 10 vers Windows 11, installez Windows 10 sur l’ordinateur de test, puis installez les applications.

Étape 1 : Vérifier que l’application est installée sur l’ordinateur source et qu’il s’agit de la même version que la version à installer sur l’ordinateur de destination

Avant que l’outil USMT ne migre les paramètres, case activée si l’application est installée sur l’ordinateur source et qu’il s’agit de la version correcte. Si l’application n’est pas installée sur l’ordinateur source, USMT passe toujours du temps à rechercher les paramètres de l’application. Plus important encore, si l’outil USMT collecte les paramètres d’une application qui n’est pas installée, il peut migrer les paramètres qui entraînent le fonctionnement incorrect de l’ordinateur de destination. Déterminez également s’il existe plusieurs versions de l’application, car la nouvelle version peut stocker les paramètres dans un autre emplacement. Des versions d’application incompatibles peuvent entraîner des résultats inattendus sur l’ordinateur de destination.

Il existe de nombreuses façons de détecter si une application est installée. La meilleure pratique consiste à case activée pour une clé de désinstallation d’application dans le Registre, puis à rechercher sur l’ordinateur le fichier exécutable qui a installé l’application. Il est important de case activée pour ces deux éléments, car des versions différentes de la même application partagent parfois la même clé de désinstallation. Même si la clé est là, elle peut correspondre à une autre version de l’application souhaitée.

Rechercher une clé de désinstallation d’application dans le Registre

Lorsque de nombreuses applications sont installées (en particulier celles installées à l’aide de la technologie Microsoft Windows Installer), une clé de désinstallation d’application est créée sous :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

Par exemple, quand Adobe Acrobat Reader 7 est installé, il crée une clé nommée :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall \{AC76BA86-7AD7-1033-7B44-A70000000000}

Par conséquent, si un ordinateur contient cette clé, Adobe Acrobat Reader 7 est installé sur l’ordinateur. L’existence d’une clé de Registre peut être vérifiée à l’aide de la fonction d’assistance DoesObjectExist .

En règle générale, cette clé se trouve en effectuant une recherche sous :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

pour le nom de l’application, le nom du fichier exécutable de l’application ou pour le nom de la société qui crée l’application. Le Rédacteur du Registre, Regedit.exe situé dans , %SystemRoot%peut être utilisé pour effectuer une recherche dans le Registre.

Vérifier le système de fichiers pour le fichier exécutable de l’application

Les fichiers binaires de l’exécutable qui a installé l’application doivent également être vérifiés. Pour case activée pour les fichiers binaires d’application, déterminez où l’application est installée et quel est le nom de l’exécutable. La plupart des applications stockent l’emplacement d’installation des fichiers binaires d’application dans le Registre. Vous devez effectuer une recherche dans le Registre sur l’un des éléments suivants jusqu’à ce que la valeur de Registre qui contient le chemin d’installation soit trouvée :

  • Nom de l’application.
  • Nom de l’exécutable de l’application.
  • Nom de la société qui crée l’application.

Une fois que le chemin d’accès à l’exécutable de l’application est déterminé, la DoesFileVersionMatch fonction d’assistance peut être utilisée pour case activée la version correcte de l’exécutable de l’application. Pour obtenir un exemple d’utilisation de la DoesFileVersionMatch fonction d’assistance, consultez la section Windows Live™ Messenger du MigApp.xml fichier.

Étape 2 : Identifier les paramètres à collecter et déterminer où chaque paramètre est stocké sur l’ordinateur

Ensuite, parcourez l’interface utilisateur et dressez une liste de tous les paramètres disponibles. La liste peut être réduite si certains paramètres n’ont pas besoin d’être migrés. Pour déterminer l’emplacement de stockage de chaque paramètre, modifiez le paramètre. À mesure que le paramètre est modifié, surveillez l’activité sur le Registre et le système de fichiers via un outil tel que Process Monitor. Les fichiers binaires et les paramètres du Registre créés lors de l’installation de l’application n’ont pas besoin d’être migrés. Lorsque l’application est réinstallée sur l’ordinateur de destination, elle recrée ces paramètres. Seuls les paramètres personnalisés doivent être migrés.

Comment déterminer l’emplacement de stockage de chaque paramètre

  1. Téléchargez un outil de surveillance des fichiers et du Registre, tel que Process Monitor (Procmon) à partir du site Web Sysinternals.

  2. Arrêtez autant d’applications que possible pour limiter l’activité du Registre et du système de fichiers sur l’ordinateur.

  3. Filtrez la sortie des outils afin qu’elle affiche uniquement les modifications apportées par l’application.

    Remarque

    La plupart des applications stockent leurs paramètres sous le profil utilisateur. Autrement dit, les paramètres stockés dans le système de fichiers se trouvent dans le %UserProfile% répertoire et les paramètres stockés dans le Registre se trouvent sous la HKEY_CURRENT_USER ruche. Pour ces applications, la sortie des outils de surveillance des fichiers et du Registre peut être filtrée pour afficher l’activité uniquement sous ces emplacements. Ce filtrage réduit considérablement la quantité de sortie à examiner.

  4. Démarrez le ou les outils de surveillance, modifiez un paramètre et recherchez les écritures du Registre et du système de fichiers qui se sont produites lors de la modification du paramètre. Assurez-vous que les modifications apportées prennent réellement effet. Par exemple, si vous modifiez un paramètre dans Microsoft Word en sélectionnant une zone de case activée dans la boîte de dialogue Options, la modification ne prend généralement pas effet tant que la boîte de dialogue n’est pas fermée en sélectionnant OK.

  5. Lorsque le paramètre est modifié, notez les modifications apportées au système de fichiers et au Registre. Il peut y avoir plusieurs valeurs de fichier ou de Registre pour chaque paramètre. L’ensemble minimal de modifications de fichier et de Registre requises pour modifier ce paramètre doit être identifié. Cet ensemble de fichiers et de clés de Registre est ce qui doit être migré pour migrer le paramètre.

    Remarque

    La modification d’un paramètre d’application entraîne invariablement l’écriture dans des clés de Registre. Si possible, filtrez la sortie de l’outil de surveillance des fichiers et du Registre pour afficher uniquement les écritures dans les fichiers et les clés/valeurs de Registre.

Étape 3 : Identifier comment appliquer les paramètres collectés

Si la version de l’application sur l’ordinateur source est identique à celle de l’ordinateur de destination, les fichiers et clés de Registre collectés n’ont pas besoin d’être modifiés. Par défaut, USMT migre les fichiers et les clés de Registre de l’emplacement source vers l’emplacement correspondant sur l’ordinateur de destination. Par exemple, si un fichier a été collecté à partir du C:\Users\User1\Documents dossier et que le répertoire de profil sur l’ordinateur de destination se trouve à D:\Users\User1l’emplacement , USMT migre automatiquement le fichier vers D:\Users\User1\Documents. Toutefois, il peut être nécessaire de modifier l’emplacement de certains paramètres dans les trois cas suivants :

Cas 1 : La version de l’application sur l’ordinateur de destination est plus récente que celle de l’ordinateur source

Dans ce cas, la version la plus récente de l’application peut être en mesure de lire les paramètres à partir de l’ordinateur source sans modification. Autrement dit, les données collectées à partir d’une version antérieure de l’application sont parfois compatibles avec la version la plus récente de l’application. Toutefois, il peut être nécessaire de modifier l’emplacement du paramètre si l’une des conditions suivantes est remplie :

  • La version la plus récente de l’application a la possibilité d’importer des paramètres à partir d’une version antérieure. Ce mappage se produit généralement la première fois qu’un utilisateur exécute la version la plus récente après la migration des paramètres. Certaines applications importent automatiquement les paramètres après la migration des paramètres. Toutefois, d’autres applications importent les paramètres uniquement si l’application a été mise à niveau à partir de l’ancienne version. Lorsque l’application est mise à niveau, un ensemble de fichiers et/ou de clés de Registre est installé, indiquant que l’ancienne version de l’application a été précédemment installée. Si une installation propre de la version la plus récente est effectuée, l’ordinateur ne contient pas ces fichiers et clés de Registre. Si les fichiers et les clés de Registre ne sont pas présents, le mappage ne se produit pas. Pour inciter la version la plus récente de l’application à lancer ce processus d’importation, le script de migration peut avoir besoin de créer ces fichiers et/ou clés de Registre sur l’ordinateur de destination.

    Pour identifier les fichiers et/ou les clés/valeurs de Registre qui doivent être créés pour que l’importation fonctionne :

    1. Mettez à niveau l’ancienne version de l’application vers la version la plus récente.
    2. Surveillez les modifications apportées au système de fichiers et au Registre à l’aide du processus décrit dans Comment déterminer l’emplacement de stockage de chaque paramètre.

    Une fois que l’ensemble de fichiers dont l’ordinateur a besoin est connu, l’élément <addObjects> peut être utilisé pour les ajouter à l’ordinateur de destination.

  • La version la plus récente de l’application ne peut pas lire les paramètres à partir de l’ordinateur source et elle ne peut pas non plus importer les paramètres dans le nouveau format. Dans ce cas, créez un mappage pour chaque paramètre, des anciens emplacements aux nouveaux emplacements. Pour créer le mappage, déterminez où la version la plus récente stocke chaque paramètre à l’aide du processus décrit dans Comment déterminer l’emplacement de stockage de chaque paramètre. Après avoir créé le mappage, appliquez les paramètres au nouvel emplacement sur l’ordinateur de destination à l’aide de l’élément <locationModify> et des fonctions d’assistance RelativeMove et ExactMove .

Cas 2 : l’ordinateur de destination contient déjà les paramètres de l’application

Microsoft recommande de migrer les paramètres après l’installation de l’application, mais avant que l’utilisateur n’exécute l’application pour la première fois. Microsoft recommande ce processus, car ce processus garantit qu’il n’existe aucun paramètre sur l’ordinateur de destination lors de la migration des paramètres. Si l’application doit être installée avant la migration, tous les paramètres existants doivent être supprimés à l’aide de l’élément <destinationCleanup> . Si, pour une raison quelconque, les paramètres qui se trouvent sur l’ordinateur de destination doivent être conservés, l’élément de fusion> et la< fonction d’assistance peuvent être utilisés.DestinationPriority

Cas 3 : L’application remplace les paramètres lors de l’installation

Microsoft recommande de migrer les paramètres après l’installation de l’application, mais avant que l’utilisateur n’exécute l’application pour la première fois. Microsoft recommande ce processus, car ce processus garantit qu’il n’existe aucun paramètre sur l’ordinateur de destination lors de la migration des paramètres. En outre, lorsque certaines applications sont installées, elles remplacent tous les paramètres existants qui se trouvent sur l’ordinateur. Dans ce scénario, si les données ont été migrées avant l’installation de l’application, les paramètres personnalisés sont remplacés. Ce scénario est courant pour les applications qui stockent des paramètres à des emplacements situés en dehors du profil utilisateur (en général, ces paramètres sont des paramètres qui s’appliquent à tous les utilisateurs). Ces paramètres universels sont parfois remplacés lorsqu’une application est installée et sont remplacés par des valeurs par défaut. Pour éviter ce problème, ces applications doivent être installées avant de migrer les fichiers et les paramètres vers l’ordinateur de destination. Par défaut, avec l’outil USMT, les données de l’ordinateur source remplacent les données qui existent déjà au même emplacement sur l’ordinateur de destination.

Étape 4 : Créer le composant XML de migration pour l’application

Après avoir effectué les étapes 1 à 3, créez un fichier .xml de migration personnalisé qui migre l’application en fonction des informations mises à jour. Le MigApp.xml fichier peut être utilisé comme modèle, car il contient des exemples de nombreux concepts abordés dans cet article. Consultez également Exemples XML personnalisés pour un autre exemple de fichier.xml .

Remarque

Microsoft recommande de créer un fichier .xml distinct au lieu d’ajouter un script au MigApp.xml fichier. Un fichier .xml distinct est recommandé, car il MigApp.xml s’agit d’un fichier volumineux et difficile à lire et à modifier. En outre, si l’outil USMT est réinstallé, le MigApp.xml fichier est remplacé par la version par défaut du fichier et la version personnalisée est perdue.

Important

Certaines applications stockent des informations dans le profil utilisateur, telles que les chemins d’installation de l’application, le nom de l’ordinateur, etc. Les informations d’application stockées dans le profil utilisateur ne doivent pas être migrées et doivent être exclues de la migration.

Le script doit effectuer les actions suivantes :

  1. Vérifiez si la version correcte de l’application est installée :

    • Recherchez la clé de désinstallation d’installation sous HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall à l’aide de la fonction d’assistance DoesObjectExist .

    • Vérifiez la version correcte du fichier exécutable de l’application à l’aide de la fonction d’assistance DoesFileVersionMatch .

  2. Si la version correcte de l’application est installée, vérifiez que chaque paramètre est migré vers l’emplacement approprié sur l’ordinateur de destination.

    • Si les versions des applications sont identiques sur les ordinateurs source et de destination, migrez chaque paramètre à l’aide des <éléments include> et <exclude> .

    • Si la version de l’application sur l’ordinateur de destination est plus récente que celle de l’ordinateur source et que l’application ne peut pas importer les paramètres, le script doit :

      1. Ajoutez l’ensemble de fichiers qui déclenchent l’importation à l’aide de l’élément <addObjects> .
      2. Créez un mappage qui applique les anciens paramètres à l’emplacement approprié sur l’ordinateur de destination à l’aide de l’élément <locationModify> et des fonctions d’assistance RelativeMove et ExactMove .

    • Si l’application doit être installée avant la migration des paramètres, supprimez tous les paramètres qui se trouvent déjà sur l’ordinateur de destination à l’aide de l’élément <destinationCleanup> .

Pour plus d’informations sur les éléments .xml et les fonctions d’assistance, consultez Bibliothèque d’éléments XML.

Étape 5 : Tester la migration des paramètres d’application

Sur un ordinateur de test, installez le système d’exploitation qui sera installé sur les ordinateurs de destination. Par exemple, si vous envisagez de migrer de Windows 10 vers Windows 11, installez Windows 11, puis installez l’application dans Windows 11. Ensuite, exécutez LoadState sur l’ordinateur de test et vérifiez que tous les paramètres migrent. Apportez des corrections si nécessaire et répétez le processus jusqu’à ce que tous les paramètres nécessaires soient correctement migrés.

Pour accélérer le temps nécessaire à la collecte et à la migration des données, un seul utilisateur peut être migré à la fois. Tous les autres composants peuvent être exclus de la migration, à l’exception de l’application testée. Pour spécifier uniquement User1 dans la migration, entrez :

/ue:*\* /ui:user1

Pour plus d’informations, consultez l’article Exclure des fichiers et des paramètres et la section Options utilisateur dans l’article Syntaxe ScanState . Pour résoudre un problème, case activée le journal de progression, le journal ScanState et le journal LoadState. Les journaux contiennent des avertissements et des erreurs susceptibles de pointer vers des problèmes liés à la migration.