Share via

Fonctionnement de l’outil USMT

  • Article

L’outil USMT intègre deux outils permettant de migrer les paramètres et les données : ScanState et LoadState. ScanState recueille les informations de l’ordinateur source et LoadState applique ces informations à l’ordinateur de destination.

  • Processus ScanState

  • Processus LoadState

    Notes

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

Processus ScanState

Lorsque vous exécutez l’outil ScanState sur l’ordinateur source, il exécute la procédure suivante :

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

  2. Il recueille des informations concernant 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 des fichiers, des clés de Registre et des valeurs qui stockent les paramètres d’Adobe Acrobat sont regroupés dans un composant de migration unique.

    Il existe trois types de composant :

    • les composants qui migrent les paramètres du système d’exploitation ;

    • les composants qui migrent les paramètres des applications ;

    • les composants qui migrent les fichiers des utilisateurs.

    L’outil ScanState recueille des informations sur les composants de paramètres d’applications et de données utilisateur à partir des fichiers .xml spécifiés en ligne de commande.

    Dans Windows Vista®, Windows 7 et Windows 8, les fichiers manifestes contrôlent le mode de migration des paramètres du système d’exploitation. Vous ne pouvez pas modifier ces fichiers. Si vous souhaitez exclure certains paramètres du système d’exploitation, vous devez créer et modifier un fichier Config.xml.

  3. ScanState détermine les profils utilisateur qui doivent être migrés. Par défaut, tous les profils utilisateur de l’ordinateur source sont migrés. Toutefois, vous pouvez inclure et exclure des utilisateurs à l’aide des options relatives aux utilisateurs. Le profil système, qui est le profil « Tous les utilisateurs » sur un ordinateur source exécutant Windows® XP, ou le profil Public dans Windows Vista, Windows 7 et Windows 8, est toujours migré ; vous ne pouvez pas exclure ces profils de la migration.

  4. Durant la phase d’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 si le type de composant est « System » ou « UserAndSystem », le composant est sélectionné pour cet utilisateur. Sinon, le composant est ignoré. Par ailleurs, si le profil utilisateur actuel n’est pas le profil système et si le type de composant est « User » ou « UserAndSystem », le composant est sélectionné pour cet utilisateur. Sinon, ce composant est ignoré.

      Notes

      À partir de là, ScanState ne fait pas la distinction entre les composants qui migrent des paramètres du système d’exploitation, ceux qui migrent des paramètres d’applications et ceux qui migrent les fichiers des utilisateurs. ScanState traite tous les composants de la même manière.

    2. Chaque composant sélectionné à l’étape précédente fait l’objet d’un traitement plus poussé. Les variables spécifiques au profil (par exemple CSIDL_PERSONAL) sont évaluées dans le contexte du profil actuel. Par exemple, si le profil traité appartient à « Utilisateur1 », CSIDL_PERSONAL est étendu à C:\Utilisateurs\Utilisateur1\Documents, en supposant que les profils utilisateur sont stockés dans le répertoire C:\Utilisateurs.

    3. Pour chaque composant sélectionné, ScanState évalue la section <detects>. Si la condition mentionnée dans la section <detects> est évaluée à faux, le composant ne fait pas l’objet d’un traitement plus poussé. Autrement, le traitement de ce composant se poursuit.

    4. Pour chaque composant sélectionné, ScanState évalue les sections <rules>. Pour chaque section <rules>, si le profil utilisateur actuel est le profil système et si le contexte de la section <rules> est « System » ou « UserAndSystem », le traitement de la règle se poursuit. Sinon, cette règle est ignorée. Par ailleurs, si le profil utilisateur actuel n’est pas le profil système et si le contexte de la section <rules> est « User » ou « UserAndSystem », le traitement de la règle se poursuit. 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 sous cette section <rules>. Chaque unité est recueillie si elle est mentionnée dans une sous-section <include>, à condition qu’il n’existe pour elle aucune règle plus spécifique dans une sous-section <exclude> de la même section <rules>. Pour plus d’informations sur la priorité dans les fichiers .xml, voir Conflits et priorité.

      En outre, toute unité de migration (telle qu’un fichier, une clé de Registre ou un ensemble de valeurs de Registre) mentionnée dans la section <UnconditionalExclude> n’est pas migrée.

      Notes

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

  5. Durant la phase de collecte, ScanState crée une liste maîtresse d’unités de migration en combinant les listes qui ont été créées pour chaque profil utilisateur sélectionné.

  6. Durant la phase d’enregistrement, ScanState écrit les unités de migration qui ont été recueillies à l’emplacement du magasin.

    Notes

    ScanState ne modifie en aucune manière l’ordinateur source.

Processus LoadState

Le processus LoadState est très semblable au processus ScanState. L’outil ScanState recueille les unités de migration telles que les fichiers, clés de Registre ou valeurs de Registre à partir de l’ordinateur source et les enregistre dans le magasin. De la même façon, l’outil LoadState recueille les unités de migration à partir du magasin et les applique à l’ordinateur de destination.

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

  2. LoadState recueille des informations concernant tous les composants de migration qui doivent être migrés.

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

    Dans Windows Vista, Windows 7 et Windows 8, les fichiers manifestes contrôlent le mode de migration des paramètres du système d’exploitation. Vous ne pouvez pas modifier ces fichiers. Si vous souhaitez exclure certains paramètres du système d’exploitation, vous devez créer et modifier un fichier Config.xml.

  3. LoadState détermine les profils utilisateur qui doivent être migrés. Par défaut, tous les profils utilisateur présents sur l’ordinateur source sont migrés. Toutefois, vous pouvez inclure et exclure des utilisateurs à l’aide des options relatives aux utilisateurs. Le profil système, qui est le profil « Tous les utilisateurs » sur un ordinateur source exécutant Windows XP ou le profil Public dans Windows Vista, Windows 7et Windows 8, est toujours migré ; vous ne pouvez pas exclure ces profils de la migration.

    • Si vous migrez des comptes d’utilisateurs locaux qui n’existent pas encore sur l’ordinateur de destination, vous devez utiliser l’option de ligne de commande /lac. Si vous ne spécifiez pas l’option /lac, les comptes d’utilisateurs locaux qui ne sont pas déjà présents sur l’ordinateur de destination ne sont pas migrés.

    • Les options /md et /mu sont traitées afin de renommer le profil utilisateur sur l’ordinateur de destination, dans la mesure où elles ont été incluses au moment de spécifier la commande LoadState

    • 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 que les profils utilisateur de domaine soient créés. Si USMT ne peut pas déterminer un domaine, il tente d’appliquer les paramètres à un local. Pour plus d’informations, voir Identifier les utilisateurs.

  4. Durant 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 si le type de composant est « System » ou « UserAndSystem », le composant est sélectionné pour cet utilisateur. Sinon, le composant est ignoré. Par ailleurs, si le profil utilisateur actuel n’est pas le profil système et si le type de composant est « User » ou « UserAndSystem », le composant est sélectionné pour cet utilisateur. Sinon, ce composant est ignoré.

      Notes

      À partir de là, LoadState ne fait pas la distinction entre les composants qui migrent des paramètres du système d’exploitation, ceux qui migrent des paramètres d’applications et ceux qui migrent les fichiers des utilisateurs. LoadState évalue tous les composants de la même manière.

    2. Chaque composant sélectionné fait l’objet d’un traitement plus poussé. Les variables spécifiques au profil (par exemple CSIDL_PERSONAL) sont évaluées dans le contexte du profil actuel. Par exemple, si le profil traité appartient à « Utilisateur1 », CSIDL_PERSONAL est étendu à C:\Utilisateurs\Utilisateur1\Documents (en supposant que les profils utilisateur sont stockés dans le répertoire C:\Utilisateurs).

      Notes

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

    3. Pour chaque composant sélectionné, LoadState évalue les sections <rules>. Pour chaque section <rules>, si le profil utilisateur actuel est le profil système et si le contexte de la section <rules> est « System » ou « UserAndSystem », le traitement de la règle se poursuit. Sinon, cette règle est ignorée. Par ailleurs, si le profil utilisateur actuel n’est pas le profil système et si le contexte de la section <rules> est « User » ou « UserAndSystem », le traitement de la règle se poursuit. Sinon, cette règle est ignorée.

    4. LoadState crée une liste maîtresse d’unités de migration en traitant les différentes sous-sections sous la section <rules>. Chaque unité de migration mentionnée dans une sous-section <include> est migrée, à condition qu’il n’existe pour elle aucune règle plus spécifique dans une sous-section <exclude> de la même section <rules>. Pour plus d’informations sur la priorité, voir 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 Windows Vista ou Windows 7, les unités de migration recueillies par ScanState à l’aide des fichiers manifestes de niveau inférieur sont traitées par LoadState à l’aide du manifeste de composant correspondant pour Windows 7. Les fichiers manifestes de niveau inférieur ne sont pas utilisés pendant l’exécution de LoadState.

      Important

      Il est important de spécifier les fichiers .xml avec la commande LoadState si vous souhaitez que LoadState les utilise. Autrement, toute règle spécifique à l’ordinateur de destination mentionnée dans ces fichiers .xml, telle que <locationModify>, est ignorée, même si les mêmes fichiers .xml ont été fournis lors de l’exécution de la commande ScanState.

  5. Durant la phase d’application, LoadState écrit les unités de migration qui ont été recueillies aux différents emplacements sur l’ordinateur de destination. S’il existe des conflits mais aucune règle <merge> pour l’objet, le comportement par défaut pour le Registre consiste à remplacer la destination par la source. Le comportement par défaut pour les fichiers consiste à renommer la source de manière incrémentielle, par exemple NomFichierOrigine(1).ExtensionOrigine. Certains paramètres, tels que ceux des polices, du papier-peint et de l’écran de veille, ne prennent effet que lors de la prochaine connexion de l’utilisateur. Pour cette raison, vous devez fermer votre session une fois les actions de la commande LoadState terminées.

Voir aussi

Autres ressources

Syntaxe de la ligne de commande de l’Outil de migration utilisateur (USMT)