Conflits et priorité
Lors de l’inclusion, de l’exclusion et du réacheminement de fichiers et de paramètres, il est important de savoir comment l’outil de migration de l’état utilisateur (USMT) traite les conflits et la priorité. Voici les règles de conflit et de précédence les plus importantes à garder à l’esprit lors de l’utilisation de l’outil USMT.
S’il existe des règles en conflit au sein d’un composant, la règle la plus spécifique est appliquée. Toutefois, la <règle unconditionalExclude> est une exception, car elle est prioritaire sur toutes les autres. Les noms de répertoires sont prioritaires sur les extensions de fichier. Pour obtenir des exemples, consultez Que se passe-t-il en cas de <conflit de règles d’inclusion> et <d’exclusion> ? et le premier exemple des <exemples de priorité des règles d’inclusion> et <d’exclusion> plus loin dans cet article.
Seules les règles à l’intérieur du même composant peuvent s’affecter mutuellement, en fonction de la spécificité. Les règles qui se trouvent dans des composants différents ne s’affectent pas les unes les autres, à l’exception de la <règle unconditionalExclude> .
Si les règles sont également spécifiques, <exclure> est prioritaire sur <include>. Par exemple, si la <règle d’exclusion> est utilisée pour exclure un fichier et utiliser la <règle include> pour inclure le même fichier, le fichier est exclu.
L’ordre des composants n’a pas d’importance. Les composants répertoriés dans .xml fichier n’ont pas d’importance, car chaque composant est traité indépendamment des autres composants dans tous les fichiers .xml .
L’ordre des règles d’inclusion <> et <d’exclusion> au sein d’un composant n’a pas d’importance.
L’élément <unconditionalExclude> peut être utilisé pour exclure globalement des données. Cet élément exclut les objets, quelles que soient les autres <règles include> qui se trouvent dans les fichiers .xml . Par exemple, l’élément <unconditionalExclude> peut être utilisé pour exclure tous les fichiers MP3 sur l’ordinateur ou pour exclure tous les fichiers de
C:\UserData.
Général
Quelle est la relation entre les règles qui se trouvent dans différents composants ?
Seules les règles à l’intérieur du même composant peuvent s’affecter les unes les autres, en fonction de leur spécificité, à l’exception de la <règle conditionnalitéexclude> . Les règles qui se trouvent dans des composants différents ne s’affectent pas les unes les autres. S’il existe une règle include<> dans un composant et une règle d’exclusion> identique< dans un autre composant, les données sont migrées, car les deux règles sont indépendantes l’une de l’autre.
Si une règle include<> se trouve dans un composant et qu’une <règle locationModify> se trouve dans un autre composant pour le même fichier, le fichier est migré aux deux emplacements. Autrement dit, le fichier est inclus en fonction de la <règle include> et le fichier est migré en fonction de la <règle locationModify> .
Le fichier .xml suivant migre tous les fichiers de C :\Userdocs, y compris les fichiers .mp3 , car la <règle d’exclusion> est spécifiée dans un composant distinct.
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/UserDocs">
<component type="Documents" context="System">
<displayName>User Documents</displayName>
<role role="Data">
<rules>
<exclude>
<objectSet>
<pattern type="File">C:\Userdocs\* [*.mp3]</pattern>
</objectSet>
</exclude>
</rules>
</role>
</component>
<component type="Documents" context="System">
<displayName> User documents to include </displayName>
<role role="Data">
<rules>
<include>
<objectSet>
<pattern type="File"> C:\Userdocs\ [*]</pattern>
</objectSet>
</include>
</rules>
</role>
</component>
</migration>
Comment fonctionne la priorité avec le fichier Config.xml ?
migrate="no" La spécification dans le Config.xml fichier revient à supprimer le composant correspondant du fichier de.xml de migration. Toutefois, si migrate="no" est défini pour le dossier Documents , mais qu’une règle similaire à la règle suivante existe dans un fichier de.xml de migration (qui inclut tous les fichiers .doc du dossier Documents ), seuls les fichiers .doc sont migrés et tous les autres fichiers sont exclus :
<include>
<objectSet>
<pattern type="File">%CSIDL_PERSONAL%\* [*.doc] </pattern>
</objectSet>
</include>
Comment l’outil USMT traite-t-il chaque composant d’un fichier .xml avec plusieurs composants ?
L’ordre des composants n’a pas d’importance. Chaque composant est traité indépendamment des autres composants. Par exemple, si une règle include<> se trouve dans un composant et qu’une <règle locationModify> se trouve dans un autre composant pour le même fichier, le fichier est migré aux deux emplacements. Autrement dit, le fichier est inclus en fonction de la <règle include> et le fichier est migré en fonction de la <règle locationModify> .
Comment les règles sont-elles traitées ?
Il existe deux grandes catégories de règles.
Règles qui affectent le comportement des outils ScanState et LoadState. Par exemple, les <règles include>, <exclude> et <unconditionalExclude> sont traitées pour chaque composant des fichiers .xml . Pour chaque composant, l’outil USMT crée une liste d’inclusion et une liste d’exclusion. Certaines règles du composant peuvent être ignorées en raison de leur spécificité, mais toutes les règles restantes sont traitées. Pour chaque <règle include> , USMT effectue une itération au sein des éléments pour voir si l’un des emplacements doit être exclu. L’outil USMT énumère tous les objets et crée une liste d’objets qu’il va collecter pour chaque utilisateur. Une fois la liste terminée, chacun des objets est stocké ou migré vers l’ordinateur de destination.
Règles qui affectent uniquement le comportement de l’outil LoadState. Par exemple, les <règles locationModify>, <contentModify> et <destinationCleanup> n’affectent pas ScanState. Ils sont traités uniquement avec LoadState. Tout d’abord, l’outil LoadState détermine le contenu et l’emplacement de chaque composant en fonction des <règles locationModify> et <contentModify> . Ensuite, LoadState traite toutes les <règles destinationCleanup> et supprime les données de l’ordinateur de destination. Enfin, LoadState applique les composants à l’ordinateur.
Comment l’outil USMT combine-t-il tous les fichiers .xml que je spécifie sur la ligne de commande ?
L’outil USMT ne distingue pas les fichiers.xml en fonction de leur nom ou de leur contenu. Il traite chaque composant dans les fichiers séparément. USMT prend en charge plusieurs fichiers .xml uniquement pour faciliter la gestion et l’organisation des composants qu’ils contiennent. Étant donné que l’outil USMT utilise un urlid pour distinguer chaque composant des autres, assurez-vous que chaque fichier .xml spécifié sur la ligne de commande a un URLid de migration unique.
Règles d’inclusion <> et <d’exclusion>
Que se passe-t-il en cas de conflit de règles d’inclusion> et d’exclusion ?<><
S’il existe des règles en conflit au sein d’un composant, la règle la plus spécifique est appliquée, à l’exception de la <règle unconditionalExclude> , qui est prioritaire sur toutes les autres règles. Si les règles sont également spécifiques, les données ne sont pas migrées. Par exemple, si le même fichier est à la fois exclu et inclus, le fichier n’est pas migré. S’il existe des règles en conflit au sein de différents composants, les règles ne s’affectent pas les unes les autres, car chaque composant est traité indépendamment.
Dans l’exemple suivant, les fichiers mp3 ne sont pas exclus de la migration. Les fichiers mp3 ne sont pas exclus, car les noms de répertoires sont prioritaires sur les extensions de fichier.
<include>
<objectSet>
<pattern type="File">C:\Data\* [*]</pattern>
</objectSet>
</include>
<exclude>
<objectSet>
<pattern type="File"> C:\* [*.mp3]</pattern>
</objectSet>
</exclude>
<inclure> et <exclure> des exemples de précédence des règles
Ces exemples expliquent comment l’outil USMT traite les <règles d’inclusion> et <d’exclusion> . Lorsque les règles se trouvent dans des composants différents, le comportement résultant est le même, que les composants se trouvent dans le même fichier ou dans des fichiers .xml de migration différents.
Inclusion et exclusion de fichiers
| Si le code suivant existe dans le même composant | Comportement résultant | Explication |
|---|---|---|
|
Migre tous les fichiers et sous-dossiers dans Dir1 (y compris tous les fichiers .txt en C :). | La <règle d’exclusion> n’affecte pas la migration, car la <règle include> est plus spécifique. |
|
Migre tous les fichiers et sous-dossiers dans C :\Dir1, à l’exception des fichiers .txt dans C :\Dir1\Dir2 et de ses sous-dossiers. | Les deux règles sont traitées comme prévu. |
|
Migre tous les fichiers et sous-dossiers dans C :\Dir1, à l’exception des fichiers .txt dans C :\Dir1 et de ses sous-dossiers. | Les deux règles sont traitées comme prévu. |
|
Rien n’est migré. | Les règles étant tout aussi spécifiques, la règle d’exclusion<> est prioritaire sur la <règle include>. |
|
Migre les fichiers .txt dans Dir1 et les fichiers.txt à partir de sous-dossiers autres que Dir2. Aucun fichier n’est migré à partir de Dir2 ou de ses sous-dossiers. |
Les deux règles sont traitées comme prévu. |
|
Migre tous les fichiers et sous-dossiers de Dir2, à l’exception des fichiers.txt de Dir1 et des sous-dossiers de Dir1 (y compris Dir2). | Les deux règles sont traitées comme prévu. |
| Si le code suivant existe dans différents composants | Comportement résultant | Explication |
|---|---|---|
Composant 1 :
Composant 2 :
|
Migre tous les fichiers et sous-dossiers de C :\Dir1\ (y compris C :\Dir1\Dir2). | Les règles qui se trouvent dans des composants différents ne s’affectent pas les unes les autres, à l’exception de la <règle unconditionalExclude> . Par conséquent, dans cet exemple, bien que certains fichiers .txt aient été exclus lors du traitement du composant 1, ils ont été inclus lors du traitement du composant 2. |
Composant 1 :
Composant 2 :
|
Migre tous les fichiers et sous-dossiers de Dir2, à l’exception des fichiers .txt dans C :\Dir1 et de ses sous-dossiers. | Les deux règles sont traitées comme prévu. |
Composant 1 :
Composant 2 :
|
Migre tous les fichiers .txt dans Dir1 et tous les sous-dossiers. | Le composant 1 ne contient pas de <règle include> , donc la <règle d’exclusion> n’est pas traitée. |
Inclusion et exclusion d’objets de Registre
| Si le code suivant existe dans le même composant | Comportement résultant | Explication |
|---|---|---|
|
Migre toutes les clés dans HKLM\Software\Microsoft\Command Processor, à l’exception de DefaultColor. | Les deux règles sont traitées comme prévu. |
|
Migre uniquement DefaultColor dans HKLM\Software\Microsoft\Command Processor. | DefaultColor est migré, car la <règle include> est plus spécifique que la règle d’exclusion<>. |
|
Ne migre pas DefaultColor. | Les règles étant tout aussi spécifiques, la règle d’exclusion<> est prioritaire sur la <règle include>. |
| Si le code suivant existe dans différents composants | Comportement résultant | Explication |
|---|---|---|
Composant 1 :
Composant 2 :
|
Migre toutes les clés/valeurs sous HKLM\Software\Microsoft\Command Processor. | Les règles qui se trouvent dans des composants différents ne s’affectent pas les unes les autres, à l’exception de la <règle unconditionalExclude> . Dans cet exemple, les objets exclus lors du traitement du composant 1 ont été inclus lors du traitement du composant 2. |
Collisions de fichiers
Quel est le comportement par défaut en cas de collisions de fichiers ?
S’il n’existe pas <de règle de fusion> , le comportement par défaut du Registre est que la source remplace la destination. Le comportement par défaut pour les fichiers consiste à renommer la source de manière incrémentielle : par exemple, OriginalFileName(1). OriginalExtension, OriginalFileName(2). OriginalExtension, etc.
Comment fonctionne la règle de <fusion> en cas de collisions de fichiers ?
Lorsqu’une collision est détectée, USMT sélectionne la règle de fusion> la plus spécifique< et l’applique pour résoudre le conflit. Par exemple, s’il existe une <règle de fusion> pour C :\* [*] définie sur sourcePriority() et une autre <règle de fusion> pour C :\subfolder\* [*] définie sur destinationPriority(), USMT utilise la règle destinationPriority(), car elle est la plus spécifique.
Exemple de scénario
L’ordinateur source contient les fichiers suivants :
C:\Data\SampleA.txtC:\Data\SampleB.txtC:\Data\Folder\SampleB.txt
L’ordinateur de destination contient les fichiers suivants :
C:\Data\SampleB.txtC:\Data\SampleB.txt
Un fichier .xml personnalisé contient le code suivant :
<include>
<objectSet>
<pattern type="File">c:\data\* [*]</pattern>
</objectSet>
</include>
Pour cet exemple, les informations suivantes décrivent le comportement résultant si le code est ajouté au fichier .xml personnalisé.
Exemple 1
<merge script="MigXmlHelper.DestinationPriority()">
<objectSet>
<pattern type="File">c:\data* []</pattern>
</objectSet>
</merge>
Résultat : pendant ScanState, tous les fichiers sont ajoutés au magasin. Pendant LoadState, seul C:\Data\SampleA.txt est restauré.
Exemple 2
<merge script="MigXmlHelper.SourcePriority()">
<objectSet>
<pattern type="File">c:\data* []</pattern>
</objectSet>
</merge>
Résultat : pendant ScanState, tous les fichiers sont ajoutés au magasin. Pendant LoadState, tous les fichiers sont restaurés, en remplaçant les fichiers existants sur l’ordinateur de destination.
Exemple 3
<merge script="MigXmlHelper.SourcePriority()">
<objectSet>
<pattern type="File">c:\data\ [*]</pattern>
</objectSet>
</merge>
Résultat : pendant ScanState, tous les fichiers sont ajoutés au magasin. Pendant LoadState, les actions suivantes se produisent :
-
C:\Data\SampleA.txtest restauré. -
C:\Data\SampleB.txtest restauré, en remplaçant le fichier existant sur l’ordinateur de destination. -
C:\Data\Folder\SampleB.txtne sont pas restaurés.