Conflictos y prioridad
Al incluir, excluir y volver a enrutar archivos y configuraciones, es importante saber cómo la Herramienta de migración de estado de usuario (USMT) se ocupa de los conflictos y la prioridad. A continuación se muestran los conflictos más importantes y las directrices de precedencia que se deben tener en cuenta al trabajar con USMT.
Si hay reglas en conflicto dentro de un componente, se aplica la regla más específica. Sin embargo, la <regla unconditionalExclude> es una excepción porque tiene prioridad sobre todas las demás. Los nombres de directorio tienen prioridad sobre las extensiones de archivo. Para obtener ejemplos, consulte ¿Qué ocurre cuando hay reglas de inclusión> y <exclusión> en conflicto<? y el primer ejemplo de <ejemplos de prioridad de inclusión> y <exclusión> de reglas más adelante en este artículo.
Solo las reglas dentro del mismo componente pueden afectar entre sí, en función de la especificidad. Las reglas que se encuentran en componentes diferentes no se afectan entre sí, excepto para la <regla unconditionalExclude> .
Si las reglas son igualmente específicas, <excluir> tiene prioridad sobre <include>. Por ejemplo, si la <regla de exclusión> se usa para excluir un archivo y usar la <regla de inclusión> para incluir el mismo archivo, se excluye el archivo.
El orden de los componentes no importa. No importa qué componentes se enumeran en qué archivo.xml , porque cada componente se procesa independientemente de los demás componentes en todos los archivos de.xml .
El orden de las <reglas de inclusión> y <exclusión> dentro de un componente no importa.
El <elemento unconditionalExclude> se puede usar para excluir datos globalmente. Este elemento excluye objetos, independientemente de cualquier otra <regla de inclusión> que se encuentren en los archivos.xml. Por ejemplo, el <elemento unconditionalExclude> se puede usar para excluir todos los archivos MP3 del equipo o para excluir todos los archivos de
C:\UserData
.
General
¿Cuál es la relación entre las reglas que se encuentran dentro de distintos componentes?
Solo las reglas dentro del mismo componente pueden afectar entre sí, dependiendo de la especificidad, excepto para la <regla unconditionalExclude> . Las reglas que están en componentes diferentes no se afectan entre sí. Si hay una regla de inclusión<> en un componente y una regla de exclusión> idéntica< en otro componente, los datos se migran porque las dos reglas son independientes entre sí.
Si una <regla de inclusión> está en un componente y una <regla locationModify> está en otro componente para el mismo archivo, el archivo se migra en ambos lugares. Es decir, el archivo se incluye en función de la <regla de inclusión> y el archivo se migra en función de la <regla locationModify> .
El siguiente archivo .xml migra todos los archivos de C:\Userdocs, incluidos los archivos .mp3 , porque la <regla de exclusión> se especifica en un componente independiente.
<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>
¿Cómo funciona la precedencia con el archivo Config.xml?
migrate="no"
Especificar en el Config.xml
archivo es lo mismo que eliminar el componente correspondiente del archivo de migración.xml. Sin embargo, si migrate="no"
se establece para la carpeta Documentos , pero existe una regla similar a la siguiente regla en un archivo de.xml de migración (que incluye todos los archivos .doc de la carpeta Documentos ), solo se migran los archivos .doc y se excluyen todos los demás archivos:
<include>
<objectSet>
<pattern type="File">%CSIDL_PERSONAL%\* [*.doc] </pattern>
</objectSet>
</include>
¿Cómo procesa USMT cada componente en un archivo .xml con varios componentes?
El orden de los componentes no importa. Cada componente se procesa independientemente de otros componentes. Por ejemplo, si una regla de inclusión<> está en un componente y una <regla locationModify> está en otro componente para el mismo archivo, el archivo se migra en ambos lugares. Es decir, el archivo se incluye en función de la <regla de inclusión> y el archivo se migra en función de la <regla locationModify> .
¿Cómo se procesan las reglas?
Hay dos amplias categorías de reglas.
Reglas que afectan al comportamiento de las herramientas ScanState y LoadState. Por ejemplo, las <reglas include>, <exclude> y <unconditionalExclude> se procesan para cada componente de los archivos .xml . Para cada componente, USMT crea una lista de inclusión y una lista de exclusión. Algunas de las reglas del componente pueden descartarse debido a la especificidad, pero se procesan todas las reglas restantes. Para cada <regla de inclusión> , USMT recorre en iteración los elementos para ver si es necesario excluir alguna de las ubicaciones. USMT enumera todos los objetos y crea una lista de objetos que va a recopilar para cada usuario. Una vez completada la lista, cada uno de los objetos se almacena o migra al equipo de destino.
Reglas que afectan al comportamiento de solo la herramienta LoadState. Por ejemplo, las <reglas locationModify>, <contentModify> y <destinationCleanup> no afectan a ScanState. Solo se procesan con LoadState. En primer lugar, la herramienta LoadState determina el contenido y la ubicación de cada componente en función de las <reglas locationModify> y <contentModify> . A continuación, LoadState procesa todas las <reglas destinationCleanup> y elimina los datos del equipo de destino. Por último, LoadState aplica los componentes al equipo.
¿Cómo combina USMT todos los archivos .xml que especifique en la línea de comandos?
USMT no distingue los archivos de.xml en función de su nombre o contenido. Procesa cada componente dentro de los archivos por separado. USMT admite varios archivos de.xml solo para facilitar el mantenimiento y la organización de los componentes dentro de ellos. Dado que USMT usa un urlid para distinguir cada componente de los demás, asegúrese de que cada archivo .xml que se especifica en la línea de comandos tiene un urlid de migración único.
Reglas <de inclusión> y <exclusión>
¿Qué ocurre cuando hay reglas de inclusión> y <exclusión> en <conflicto?
Si hay reglas en conflicto dentro de un componente, se aplica la regla más específica, excepto con la <regla unconditionalExclude> , que tiene prioridad sobre todas las demás reglas. Si las reglas son igualmente específicas, no se migran los datos. Por ejemplo, si el mismo archivo se excluye e incluye, el archivo no se migra. Si hay reglas en conflicto dentro de distintos componentes, las reglas no se afectan entre sí porque cada componente se procesa de forma independiente.
En el ejemplo siguiente, los archivos mp3 no se excluyen de la migración. Los archivos mp3 no se excluyen porque los nombres de directorio tienen prioridad sobre las extensiones de archivo.
<include>
<objectSet>
<pattern type="File">C:\Data\* [*]</pattern>
</objectSet>
</include>
<exclude>
<objectSet>
<pattern type="File"> C:\* [*.mp3]</pattern>
</objectSet>
</exclude>
<ejemplos de precedencia de reglas de inclusión> y <exclusión>
En estos ejemplos se explica cómo USMT trata las <reglas de inclusión> y <exclusión> . Cuando las reglas están en componentes diferentes, el comportamiento resultante es el mismo independientemente de si los componentes están en el mismo o en diferentes archivos de migración.xml .
Inclusión y exclusión de archivos
Si el código siguiente existe en el mismo componente | Comportamiento resultante | Explicación |
---|---|---|
|
Migra todos los archivos y subcarpetas de Dir1 (incluidos todos los archivos .txt en C:). | La <regla de exclusión> no afecta a la migración porque la <regla de inclusión> es más específica. |
|
Migra todos los archivos y subcarpetas de C:\Dir1, excepto los archivos .txt de C:\Dir1\Dir2 y sus subcarpetas. | Ambas reglas se procesan según lo previsto. |
|
Migra todos los archivos y subcarpetas de C:\Dir1, excepto los archivos .txt de C:\Dir1 y sus subcarpetas. | Ambas reglas se procesan según lo previsto. |
|
No se migra nada. | Las reglas son igualmente específicas, por lo que la <regla de exclusión> tiene prioridad sobre la <regla de inclusión> . |
|
Migra los archivos .txt en Dir1 y los archivos .txt de subcarpetas distintas de Dir2. No se migra ningún archivo desde Dir2 o sus subcarpetas. |
Ambas reglas se procesan según lo previsto. |
|
Migra todos los archivos y subcarpetas de Dir2, excepto los archivos .txt de Dir1 y las subcarpetas de Dir1 (incluido Dir2). | Ambas reglas se procesan según lo previsto. |
Si el código siguiente existe en componentes diferentes | Comportamiento resultante | Explicación |
---|---|---|
Componente 1:
Componente 2:
|
Migra todos los archivos y subcarpetas de C:\Dir1\ (incluido C:\Dir1\Dir2). | Las reglas que se encuentran en componentes diferentes no se afectan entre sí, excepto para la <regla unconditionalExclude> . Por lo tanto, en este ejemplo, aunque algunos archivos .txt se excluyeron cuando se procesó el componente 1, se incluyeron cuando se procesó el componente 2. |
Componente 1:
Componente 2:
|
Migra todos los archivos y subcarpetas de Dir2 excepto los archivos .txt de C:\Dir1 y sus subcarpetas. | Ambas reglas se procesan según lo previsto. |
Componente 1:
Componente 2:
|
Migra todos los archivos .txt en Dir1 y cualquier subcarpeta. | El componente 1 no contiene una regla de inclusión<>, por lo que la <regla de exclusión> no se procesa. |
Inclusión y exclusión de objetos del Registro
Si el código siguiente existe en el mismo componente | Comportamiento resultante | Explicación |
---|---|---|
|
Migra todas las claves de HKLM\Software\Microsoft\Command Processor excepto DefaultColor. | Ambas reglas se procesan según lo previsto. |
|
Migra solo DefaultColor en HKLM\Software\Microsoft\Command Processor. | DefaultColor se migra porque la <regla de inclusión> es más específica que la <regla de exclusión> . |
|
No migra DefaultColor. | Las reglas son igualmente específicas, por lo que la <regla de exclusión> tiene prioridad sobre la <regla de inclusión> . |
Si el código siguiente existe en componentes diferentes | Comportamiento resultante | Explicación |
---|---|---|
Componente 1:
Componente 2:
|
Migra todas las claves o valores en HKLM\Software\Microsoft\Command Processor. | Las reglas que se encuentran en componentes diferentes no se afectan entre sí, excepto para la <regla unconditionalExclude> . En este ejemplo, los objetos que se excluyeron cuando se procesó el componente 1 se incluyeron cuando se procesó el componente 2. |
Colisiones de archivos
¿Cuál es el comportamiento predeterminado cuando hay colisiones de archivos?
Si no hay una regla de <combinación> , el comportamiento predeterminado del Registro es que el origen sobrescriba el destino. El comportamiento predeterminado de los archivos es que el origen cambie de nombre de forma incremental: por ejemplo, OriginalFileName(1). OriginalExtension, OriginalFileName(2). OriginalExtension, etc.
¿Cómo funciona la <regla de combinación> cuando hay colisiones de archivos?
Cuando se detecta una colisión, USMT selecciona la regla de combinación> más específica< y la aplica para resolver el conflicto. Por ejemplo, si existe una <regla de combinación> para C:\* [*] establecida en sourcePriority() y otra <regla de combinación> para C:\subcarpeta\* [*] establecida en destinationPriority(), USMT usa la regla destinationPriority() porque es la más específica.
Escenario de ejemplo
El equipo de origen contiene los siguientes archivos:
C:\Data\SampleA.txt
C:\Data\SampleB.txt
C:\Data\Folder\SampleB.txt
El equipo de destino contiene los siguientes archivos:
C:\Data\SampleB.txt
C:\Data\SampleB.txt
Un archivo de.xml personalizado contiene el código siguiente:
<include>
<objectSet>
<pattern type="File">c:\data\* [*]</pattern>
</objectSet>
</include>
En este ejemplo, la siguiente información describe el comportamiento resultante si el código se agrega al archivo de.xml personalizado.
Ejemplo 1
<merge script="MigXmlHelper.DestinationPriority()">
<objectSet>
<pattern type="File">c:\data* []</pattern>
</objectSet>
</merge>
Resultado: durante ScanState, todos los archivos se agregan al almacén. Durante LoadState, solo C:\Data\SampleA.txt
se restaura.
Ejemplo 2
<merge script="MigXmlHelper.SourcePriority()">
<objectSet>
<pattern type="File">c:\data* []</pattern>
</objectSet>
</merge>
Resultado: durante ScanState, todos los archivos se agregan al almacén. Durante LoadState, se restauran todos los archivos, sobrescribiendo los archivos existentes en el equipo de destino.
Ejemplo 3
<merge script="MigXmlHelper.SourcePriority()">
<objectSet>
<pattern type="File">c:\data\ [*]</pattern>
</objectSet>
</merge>
Resultado: durante ScanState, todos los archivos se agregan al almacén. Durante LoadState, se producen las siguientes acciones:
-
C:\Data\SampleA.txt
se restaura. -
C:\Data\SampleB.txt
se restaura, sobrescribiendo el archivo existente en el equipo de destino. -
C:\Data\Folder\SampleB.txt
no se restauran.