Partager via

Fonctionnement de l’outil USMT

L’outil USMT comprend deux outils qui migrent les paramètres et les données : ScanState et LoadState. ScanState collecte des informations à partir de l’ordinateur source, et LoadState applique ces informations à l’ordinateur de destination.

Remarque

Pour plus d’informations sur la façon dont USMT traite les règles et les fichiers XML, consultez Conflits et priorité.

Processus ScanState

Lorsque l’outil ScanState s’exécute sur l’ordinateur source, il passe par le processus suivant :

  1. Il analyse et valide les paramètres de ligne de commande, crée le ScanState.log fichier, puis commence la journalisation.

  2. Il collecte des informations sur tous les composants de migration qui doivent être migrés. Un composant de migration est un groupe logique de fichiers, de clés de Registre et de valeurs. Par exemple, l’ensemble de fichiers, de clés de Registre et de valeurs qui stockent les paramètres d’Adobe Acrobat est regroupé en un seul composant de migration.

    Il existe trois types de composants :

    • Composants qui migrent les paramètres du système d’exploitation.

    • Composants qui migrent les paramètres d’application.

    • Composants qui migrent les fichiers des utilisateurs.

    L’outil ScanState collecte des informations sur les paramètres de l’application et les composants de données utilisateur à partir des fichiers .xml spécifiés sur la ligne de commande.

    Dans les versions de Windows actuellement prises en charge, les fichiers manifestes contrôlent la façon dont les paramètres du système d’exploitation sont migrés. Ces fichiers ne peuvent pas être modifiés. Pour exclure certains paramètres du système d’exploitation, un Config.xml fichier doit être créé et modifié.

  3. ScanState détermine les profils utilisateur à migrer. Par défaut, tous les profils utilisateur sur l’ordinateur source sont migrés. Toutefois, les utilisateurs peuvent être inclus et exclus à l’aide des options Utilisateur. Le profil système et le profil public d’un ordinateur source exécutant des versions de Windows actuellement prises en charge sont toujours migrés, et ces profils ne peuvent pas être exclus de la migration.

  4. Dans la phase Analyse , ScanState effectue les opérations suivantes pour chaque profil utilisateur sélectionné pour la migration :

    1. Pour chaque composant, ScanState vérifie le type du composant. Si le profil utilisateur actuel est le profil système et que le type de composant est System ou UserAndSystem, le composant est sélectionné pour cet utilisateur. Sinon, le composant est ignoré. Sinon, si le profil utilisateur actuel n’est pas le profil système et que le type de composant est User ou UserAndSystem, le composant est sélectionné pour cet utilisateur. Sinon, ce composant est ignoré.

      Remarque

      À partir de ce stade, ScanState ne fait pas de distinction entre les composants qui migrent les paramètres du système d’exploitation, les composants qui migrent les paramètres de l’application et les composants qui migrent les fichiers des utilisateurs. ScanState traite tous les composants de la même façon.

    2. Chaque composant sélectionné à l’étape précédente est traité plus avant. Toutes les variables spécifiques au profil (telles que CSIDL_PERSONAL) sont évaluées dans le contexte du profil actuel. Par exemple, si le profil en cours de traitement appartient à User1, CSIDL_PERSONAL développez en C:\Users\User1\Documents, en supposant que les profils utilisateur sont stockés dans le C:\Users répertoire.

    3. Pour chaque composant sélectionné, ScanState évalue la <section detects> . Si la condition dans la <section détecte prend> la valeur false, le composant n’est plus traité. Sinon, le traitement de ce composant se poursuit.

    4. Pour chaque composant sélectionné, ScanState évalue les sections de <règles> . Pour chaque <section de règles> , si le profil utilisateur actuel est le profil système et que le contexte de la <section règles> est System ou UserAndSystem, la règle est traitée plus avant. Sinon, cette règle est ignorée. Si le profil utilisateur actuel n’est pas le profil système et que le contexte de la <section règles> est Utilisateur ou UserAndSystem, la règle est traitée plus avant. Sinon, cette règle est ignorée.

    5. ScanState crée une liste d’unités de migration qui doivent être migrées en traitant les différentes sous-sections de cette <section de règles> . Chaque unité est collectée si l’unité est mentionnée dans une <sous-section Include>, tant qu’il n’existe pas de règle plus spécifique pour elle dans une sous-section d’exclusion<> dans la même <section règles>. Pour plus d’informations sur la priorité dans les fichiers .xml , consultez Conflits et priorité.

      En outre, toute unité de migration (par exemple, un fichier, une clé de Registre ou un ensemble de valeurs de Registre) qui se trouve dans une <section UnconditionalExclude> n’est pas migrée.

      Remarque

      ScanState ignore certaines sous-sections telles que <destinationCleanup> et <locationModify>. Ces sections sont évaluées uniquement sur l’ordinateur de destination.

  5. Dans la phase collecte , ScanState crée une liste centrale des unités de migration en combinant les listes créées pour chaque profil utilisateur sélectionné.

  6. Dans la phase d’enregistrement , ScanState écrit les unités de migration qui ont été collectées dans l’emplacement du magasin.

    Remarque

    ScanState ne modifie en aucune façon l’ordinateur source.

Processus LoadState

Le processus LoadState est similaire au processus ScanState . L’outil ScanState collecte des unités de migration telles que des fichiers, des clés de Registre ou des valeurs de Registre à partir de l’ordinateur source et les enregistre dans le magasin. De même, l’outil LoadState collecte les unités de migration du magasin et les applique à l’ordinateur de destination.

  1. ScanState analyse et valide les paramètres de ligne de commande, crée le ScanState.log fichier, puis commence la journalisation.

  2. LoadState collecte des informations sur les composants de migration qui doivent être migrés.

    LoadState obtient des informations pour les composants de paramètres d’application et les composants de données utilisateur à partir des fichiers .xml de migration spécifiés par la LoadState.exe commande .

    Dans les versions de Windows actuellement prises en charge, les fichiers manifestes contrôlent la façon dont les paramètres du système d’exploitation sont migrés. Ces fichiers ne peuvent pas être modifiés. Pour exclure certains paramètres du système d’exploitation, un Config.xml fichier doit être créé et modifié.

  3. LoadState détermine les profils utilisateur à migrer. Par défaut, tous les profils utilisateur présents sur l’ordinateur source sont migrés. Toutefois, les utilisateurs peuvent être inclus et exclus à l’aide des options Utilisateur. Le profil système et le profil public d’un ordinateur source exécutant des versions de Windows actuellement prises en charge sont toujours migrés et ces profils ne peuvent pas être exclus de la migration.

    • Si des comptes d’utilisateur locaux sont en cours de migration et si les comptes n’existent pas déjà sur l’ordinateur de destination, l’option /lac de ligne de commande doit être utilisée. Si l’option /lac n’est pas spécifiée, les comptes d’utilisateur locaux qui ne sont pas déjà présents sur l’ordinateur de destination ne sont pas migrés.

    • Lorsqu’elles sont spécifiées avec la LoadState.exe commande , les /md options et /mu sont traitées pour renommer le profil utilisateur sur l’ordinateur de destination.

    • Pour chaque profil utilisateur sélectionné dans le magasin, LoadState crée un profil utilisateur correspondant sur l’ordinateur de destination. L’ordinateur de destination n’a pas besoin d’être connecté au domaine pour créer des profils utilisateur de domaine. Si l’outil USMT ne peut pas déterminer un domaine, il tente d’appliquer les paramètres à un compte local. Pour plus d’informations, consultez Identifier les utilisateurs.

  4. Dans la phase d’analyse , LoadState effectue les opérations suivantes pour chaque profil utilisateur :

    1. Pour chaque composant, LoadState vérifie le type du composant. Si le profil utilisateur actuel est le profil système et que le type de composant est System ou UserAndSystem, le composant est sélectionné pour cet utilisateur. Sinon, le composant est ignoré. Sinon, si le profil utilisateur actuel n’est pas le profil système et que le type de composant est User ou UserAndSystem, le composant est sélectionné pour cet utilisateur. Sinon, ce composant est ignoré.

      Remarque

      À partir de ce stade, LoadState ne fait pas de distinction entre les composants qui migrent les paramètres du système d’exploitation, les composants qui migrent les paramètres de l’application et les composants qui migrent les fichiers des utilisateurs. LoadState évalue tous les composants de la même façon.

    2. Chaque composant sélectionné est traité plus avant. Toutes les variables spécifiques au profil (telles que CSIDL_PERSONAL) sont évaluées dans le contexte du profil actuel. Par exemple, si le profil en cours de traitement appartient à User1, CSIDL_PERSONAL développez la valeur C:\Users\User1\Documents (en supposant que les profils utilisateur sont stockés dans le C:\Users répertoire).

      Remarque

      LoadState ignore la <section detects> spécifiée dans un composant. À ce stade, tous les composants spécifiés sont considérés comme détectés et sélectionnés pour la migration.

    3. Pour chaque composant sélectionné, LoadState évalue les sections de <règles> . Pour chaque <section de règles> , si le profil utilisateur actuel est le profil système et que le contexte de la <section règles> est System ou UserAndSystem, la règle est traitée plus avant. Sinon, cette règle est ignorée. Si le profil utilisateur actuel n’est pas le profil système et que le contexte de la <section règles> est Utilisateur ou UserAndSystem, la règle est traitée plus avant. Sinon, cette règle est ignorée.

    4. LoadState crée une liste centrale d’unités de migration en traitant les différentes sous-sections sous la <section règles> . Chaque unité de migration qui se trouve dans une <sous-section Include> est migrée tant qu’il n’y a pas de règle plus spécifique pour elle dans une sous-section d’exclusion<> dans la même <section règles>. Pour plus d’informations sur la précédence, consultez Conflits et priorité.

    5. LoadState évalue les sous-sections spécifiques à l’ordinateur de destination, par exemple les <sous-sections destinationCleanup> et <locationModify> .

    6. Si l’ordinateur de destination exécute une version de Windows actuellement prise en charge, les migunits qui ont été collectés par ScanState à l’aide des fichiers manifeste de niveau inférieur sont traités par LoadState à l’aide du manifeste de composant correspondant de la version windows de niveau inférieur. Les fichiers manifeste de niveau inférieur ne sont pas utilisés pendant LoadState.

      Important

      Pour que LoadState utilise les fichiers .xml , il est important de les spécifier avec la LoadState.exe commande . Sinon, toutes les règles spécifiques à la destination, telles que <locationModify>, dans ces fichiers.xml sont ignorées, même si les mêmes fichiers.xml ont été fournis lors de l’exécution de la ScanState.exe commande.

  5. Dans la phase Appliquer , LoadState écrit les unités de migration qui ont été collectées dans les différents emplacements sur l’ordinateur de destination. S’il existe des conflits et qu’il n’existe pas <de règle de fusion> pour l’objet, le comportement par défaut du Registre est que la source remplace la destination. Le comportement par défaut des fichiers consiste à renommer la source de manière incrémentielle, par exemple OriginalFileName(1). OriginalExtension. Certains paramètres, tels que les polices, le papier peint et les paramètres d’économiseur d’écran, ne prennent effet qu’à la prochaine connexion de l’utilisateur. Pour cette raison, déconnectez-vous lorsque les actions de LoadState.exe commande sont terminées.