Conflits et priorité
Lorsque vous incluez, excluez et réacheminez des fichiers et des paramètres, il est important de savoir comment l’Outil de migration utilisateur (USMT) 5.0 gère les conflits et les priorités. Quel que soit le travail que vous effectuez avec l’USMT, les consignes suivantes sont les éléments essentiels à retenir en matière de conflits et de priorité.
S’il existe des conflits de règles au sein d’un composant, la règle la plus spécifique est appliquée. La règle <unconditionalExclude> constitue néanmoins une exception puisqu’elle est prioritaire sur toutes les autres. Les noms des répertoires sont prioritaires sur les extensions de fichier. Pour obtenir des exemples, consultez la section Que se passe-t-il en cas de conflits entre les règles <include> et <exclude> ? et le premier exemple de la section Exemples de priorité des règles <include> et <exclude> plus loin dans cette rubrique.
Seules les règles situées dans un même composant peuvent avoir une incidence les unes sur les autres, en fonction de leur spécificité. Les règles faisant partie de différents composants n’ont aucune incidence les unes sur les autres (à l’exception de la règle <unconditionalExclude>).
Si les règles ont la même spécificité, alors <exclude> a priorité sur la règle <include>. Par exemple, si vous utilisez la règle <exclude> pour exclure un fichier et la règle <include> pour inclure le même fichier, ce dernier sera exclus.
Le classement des composants n’a pas d’importance. Il est inutile de savoir quels composants se trouvent dans tel ou tel fichier XML puisque chaque composant est traité indépendamment des autres dans tous les fichiers XML.
Le classement des règles <include> et <exclude> au sein d’un composant n’a pas d’importance
Vous pouvez utiliser l’élément <unconditionalExclude> pour exclure les données de manière globale. Cet élément exclut les objets sans tenir compte de toutes les autres règles <include> présentes dans les fichiers XML. Par exemple, avec l’élément <unconditionalExclude>, vous pouvez exclure tous les fichiers MP3 stockés sur l’ordinateur ou bien exclure tous les fichiers situés dans C:\UserData.
Dans cette rubrique
Général
Quel est le rapport entre des règles figurant dans différents composants ?
Comment la priorité fonctionne-t-elle avec le fichier Config.xml ?
Comment l’Outil de migration utilisateur (USMT) traite-t-il chaque composant d’un fichier XML comptant plusieurs composants ?
Comment les règles sont-elles traitées ?
Comment l’Outil de migration utilisateur (USMT) combine-t-il tous les fichiers XML spécifiés sur la ligne de commande ?
Règles <include> et <exclude>
Que se passe-t-il en cas de conflits entre les règles <include> et <exclude> ?
Exemples de priorité des règles <include> et <exclude>
Conflits de fichiers
Quel est le comportement par défaut en cas de conflits de fichiers ?
Comment la règle <merge> fonctionne-t-elle en cas de conflits de fichiers ?
Général
Quel est le rapport entre des règles figurant dans différents composants ?
Seules les règles situées dans un même composant peuvent avoir une incidence les unes sur les autres, en fonction de leur spécificité (à l’exception de <unconditionalExclude>). Les règles faisant partie de différents composants n’ont aucune incidence les unes sur les autres. Si un composant contient une règle <include> et un autre composant une règle <exclude> identique, les données sont migrées puisque ces deux règles sont indépendantes l’une de l’autre.
Si une règle <include> figure dans un composant et une règle <locationModify> dans un autre composant associé au même fichier, le fichier est alors migré dans les deux emplacements. Cela signifie qu’il est inclus conformément à la règle <include> et migré conformément à la règle <locationModify>.
Le fichier XML suivant permet de migrer tous les fichiers depuis C:\Userdocs, fichiers MP3 compris, car la règle <exclude> est spécifiée dans un composant distinct.
<migration urlid="https://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 la priorité fonctionne-t-elle avec le fichier Config.xml ?
Le fait de préciser migrate="no"
dans le fichier Config.xml équivaut à supprimer le composant correspondant du fichier XML de migration. En revanche, si vous définissez migrate="no"
pour le dossier Mes documents mais disposez d’une règle similaire à celle présentée ci-dessous dans un fichier XML de migration (règle incluant tous les fichiers DOC présents dans Mes 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 de migration utilisateur (USMT) traite-t-il chaque composant d’un fichier XML comptant plusieurs composants ?
L’ordre des composants n’a aucune importance. Chaque composant est traité indépendamment des autres. Par exemple, si une règle <include> figure dans un composant et une règle <locationModify> dans un autre composant associé au même fichier, le fichier est alors migré dans les deux emplacements. Cela signifie qu’il est inclus conformément à la règle <include> et migré conformément à la règle <locationModify>.
Comment les règles sont-elles traitées ?
Il existe deux grandes catégories de règles :
Règles ayant une incidence sur le comportement des outils ScanState et LoadState. Par exemple, les règles <include>, <exclude> et <unconditionalExclude> sont traitées pour chaque composant présent dans les fichiers XML. Pour chacun des composants, 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>, l’USMT passe en boucle dans les éléments pour voir s’il existe des emplacements à exclure. L’USMT énumère tous les objets et crée une liste de ceux qu’il va collecter pour chaque utilisateur. Une fois la liste complète, chacun des objets est stocké ou migré vers l’ordinateur de destination.
Règles ayant une incidence sur le comportement de l’outil LoadState uniquement. Par exemple, les règles <locationModify>, <contentModify> et <destinationCleanup> n’affectent pas l’outil ScanState. Elles sont traitées uniquement avec l’outil LoadState. Tout d’abord, LoadState détermine le contenu et l’emplacement de chaque composant en fonction des règles <locationModify> et <contentModify>. Il traite ensuite toutes les règles <destinationCleanup> et supprime les données de l’ordinateur de destination. Et pour finir, il applique les composants à l’ordinateur.
Comment l’Outil de migration utilisateur (USMT) combine-t-il tous les fichiers XML spécifiés sur la ligne de commande ?
L’USMT ne fait aucune distinction entre les fichiers XML en fonction de leur nom ou de leur contenu. Il traite séparément chacun des composants présents dans les fichiers. La seule raison qui justifie la prise en charge de plusieurs fichiers XML par l’USMT est que cela facilite la gestion et l’organisation des composants au sein de ces fichiers. L’USMT utilise un ID d’URL pour distinguer chaque composant des autres. Vous devez donc simplement vous assurer que chaque fichier XML spécifié sur la ligne de commande possède un ID d’URL de migration unique.
Règles <include> et <exclude>
Que se passe-t-il en cas de conflits entre les règles <include> et <exclude> ?
S’il existe des conflits de règles au sein d’un composant, la règle la plus spécifique est appliquée, exception faite de la règle <unconditionalExclude> qui a priorité sur toutes les autres. Si les règles ont la même spécificité, les données ne sont alors pas migrées. Par exemple, si vous excluez un fichier, puis incluez ce même fichier, il ne sera pas migré. S’il existe des règles en conflit au sein de différents composants, les règles n’ont pas d’incidence les unes sur les autres, puisque chaque composant est traité indépendamment.
Dans l’exemple qui suit, les fichiers MP3 ne sont pas exclus de la migration, ceci parce que les noms des 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>
Exemples de priorité des règles <include> et <exclude>
Les exemples ci-après expliquent la manière dont l’USMT gère à la fois les règles <include> et <exclude>. Quand les règles concernent des composants différents, le comportement obtenu est le même, que les composants se trouvent dans les mêmes fichiers XML de migration ou dans des fichiers distincts.
Inclusion et exclusion de fichiers
Inclusion et exclusion d’objets de Registre
Inclusion et exclusion de fichiers
Si le code suivant figure dans le même composant | Comportement obtenu | Explication |
---|---|---|
|
Migre tous les fichiers et sous-dossiers de Dir1 (y compris tous les fichiers TXT présents sur C:). |
La règle <exclude> n’affecte pas la migration car la règle <include> est plus spécifique. |
|
Migre tous les fichiers et sous-dossiers de C:\Dir1, à l’exception des fichiers TXT présents dans C:\Dir1\Dir2 et ses sous-dossiers. |
Les deux règles sont traitées comme prévu. |
|
Migre tous les fichiers et sous-dossiers de C:\Dir1, à l’exception des fichiers TXT présents dans C:\Dir1 et ses sous-dossiers. |
Les deux règles sont traitées comme prévu. |
|
Aucun élément n’est migré. |
Les règles ont la même spécificité, donc la règle <exclude> est prioritaire sur la règle <include>. |
|
Migre les fichiers TXT de Dir1 et les fichiers TXT des sous-dossiers autres que Dir2. Aucun fichier n’est migré depuis Dir2 ou depuis 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 de tous les sous-dossiers de Dir1 (y compris Dir2). |
Les deux règles sont traitées comme prévu. |
Si le code suivant figure dans des composants différents | Comportement obtenu | Explication |
---|---|---|
Composant 1 :
Composant 2 :
|
Migre tous les fichiers et sous-dossiers de C:\Dir1\ (y compris C:\Dir1\Dir2\). |
Les règles faisant partie de composants différents ne s’affectent pas les unes les autres, à l’exception de la règle <unconditionalExclude>. C’est pourquoi dans cet exemple, même si certains fichiers TXT ont été exclus lors du traitement du composant 1, ils ont été à nouveau 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 présents dans C:\Dir1 et 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 ses sous-dossiers. |
Le composant 1 ne comporte aucune règle <include> ; la règle <exclude> n’est donc pas traitée. |
Inclusion et exclusion d’objets de Registre
Si le code suivant figure dans le même composant | Comportement obtenu | Explication |
---|---|---|
|
Migre toutes les clés présentes dans HKLM\Software\Microsoft\Command Processor, à l’exception de DefaultColor. |
Les deux règles sont traitées comme prévu. |
|
Migre uniquement la clé DefaultColor présente dans HKLM\Software\Microsoft\Command Processor. |
La clé DefaultColor est migrée parce que la règle <include> est plus spécifique que la règle <exclude>. |
|
La clé DefaultColor n’est pas migrée. |
Les règles ayant la même spécificité, la règle <exclude> a priorité sur la règle <include>. |
Si le code suivant figure dans des composants différents | Comportement obtenu | Explication |
---|---|---|
Composant 1 :
Composant 2 :
|
Migre toutes les clés/valeurs présentes dans HKLM\Software\Microsoft\Command Processor. |
Les règles faisant partie de composants différents ne s’affectent pas les unes les autres, à l’exception de la règle <unconditionalExclude>. C’est pourquoi dans cet exemple, les objets exclus lors du traitement du composant 1 ont été à nouveau inclus lors du traitement du composant 2. |
Conflits de fichiers
Quel est le comportement par défaut en cas de conflits de fichiers ?
S’il n’existe pas de règle <merge>, le comportement par défaut pour le Registre se traduit par un remplacement de la destination par la source. Le comportement par défaut pour les fichiers consiste à renommer la source de façon incrémentielle (par exemple, nom_fichier_original(1).extension_originale, nom_fichier_original(2).extension_originale, et ainsi de suite).
Comment la règle <merge> fonctionne-t-elle en cas de conflits de fichiers ?
Quand un conflit est détecté, l’USMT sélectionne la règle <merge> la plus spécifique et l’applique pour résoudre le conflit. Par exemple, si vous avez une règle <merge> pour C:\* [*] définie sur sourcePriority() et une autre pour C:\subfolder\* [*] définie sur destinationPriority(), l’USMT utilise la règle destinationPriority() parce qu’elle est plus spécifique.
Exemple de scénario
L’ordinateur source contient les fichiers suivants :
C:\Data\ExempleA.txt
C:\Data\ExempleB.txt
C:\Data\Folder\ExempleB.txt
Le fichier de destination contient les fichiers suivants :
C:\Data\ExempleB.txt
C:\Data\Folder\ExempleB.txt
Vous possédez un fichier XML personnalisé contenant le code suivant :
<include>
<objectSet>
<pattern type="File">c:\data\* [*]</pattern>
</objectSet>
</include>
Pour cet exemple, le tableau ci-dessous décrit le comportement obtenu si vous ajoutez le code dans la première colonne de votre fichier XML personnalisé.
Si vous spécifiez le code suivant | Comportement obtenu |
---|---|
|
Pendant l’opération ScanState, tous les fichiers sont ajoutés dans le magasin. Pendant l’opération, seul le fichier C:\Data\ExempleA.txt est restauré. |
|
Pendant l’opération ScanState, tous les fichiers sont ajoutés dans le magasin. Pendant l’opération LoadState, tous les fichiers sont restaurés, ce qui a pour effet de remplacer les fichiers existants sur l’ordinateur de destination. |
|
Pendant l’opération ScanState, tous les fichiers sont ajoutés au magasin. Pendant l’opération LoadState, les événements suivants se produisent :
|