Conflitti e precedenza
Quando si includono, si escludono e si reindirizzano file e impostazioni, è importante sapere in che modo user state migration tool (USMT) gestisce i conflitti e la precedenza. Di seguito sono riportati i conflitti e le linee guida di precedenza più importanti da tenere presenti quando si usa USMT.
Se sono presenti regole in conflitto all'interno di un componente, viene applicata la regola più specifica. Tuttavia, la <regola unconditionalExclude> è un'eccezione perché ha la precedenza su tutte le altre. I nomi di directory hanno la precedenza sulle estensioni di file. Per esempi, vedere Cosa accade quando sono presenti regole di inclusione> ed <esclusione> in conflitto<? e il primo esempio in <esempi di precedenza delle regole di inclusione> ed <esclusione> più avanti in questo articolo.
Solo le regole all'interno dello stesso componente possono influire l'una sull'altra, a seconda della specificità. Le regole che si trovano in componenti diversi non influiscono l'una sull'altra, ad eccezione della <regola unconditionalExclude> .
Se le regole sono ugualmente specifiche, <exclude> ha la precedenza su <include>. Ad esempio, se la <regola di esclusione> viene usata per escludere un file e usare la <regola di inclusione> per includere lo stesso file, il file viene escluso.
L'ordinamento dei componenti non è importante. Non importa quali componenti sono elencati in cui .xml file, perché ogni componente viene elaborato indipendentemente dagli altri componenti in tutti i file .xml .
L'ordinamento delle <regole di inclusione> ed <esclusione> all'interno di un componente non è importante.
L'elemento <unconditionalExclude> può essere usato per escludere a livello globale i dati. Questo elemento esclude gli oggetti, indipendentemente dalle altre <regole di inclusione> presenti nei file .xml . Ad esempio, l'elemento <unconditionalExclude> può essere usato per escludere tutti i file MP3 nel computer o per escludere tutti i file da
C:\UserData.
Generale
Qual è la relazione tra regole che si trovano all'interno di componenti diversi?
Solo le regole all'interno dello stesso componente possono influire l'una sull'altra, a seconda della specificità, ad eccezione della <regola unconditionalExclude> . Le regole che si trovano in componenti diversi non influiscono l'una sull'altra. Se è presente una <regola di inclusione> in un componente e una regola di esclusione> identica< in un altro componente, viene eseguita la migrazione dei dati perché le due regole sono indipendenti l'una dall'altra.
Se una <regola di inclusione> si trova in un componente e una <regola locationModify> si trova in un altro componente per lo stesso file, viene eseguita la migrazione del file in entrambe le posizioni. Ovvero, il file viene incluso in base alla <regola di inclusione> e viene eseguita la migrazione del file in base alla <regola locationModify> .
Il file di.xml seguente esegue la migrazione di tutti i file da C:\Userdocs, inclusi i file.mp3 , perché la <regola di esclusione> è specificata in un componente separato.
<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>
Come funziona la precedenza con il file Config.xml?
Specificare migrate="no" nel Config.xml file equivale all'eliminazione del componente corrispondente dal file .xml di migrazione. Tuttavia, se migrate="no" è impostato per la cartella Documenti , ma esiste una regola simile alla regola seguente in un file .xml di migrazione (che include tutti i file .doc dalla cartella Documenti ), viene eseguita la migrazione solo dei file .doc e vengono esclusi tutti gli altri file:
<include>
<objectSet>
<pattern type="File">%CSIDL_PERSONAL%\* [*.doc] </pattern>
</objectSet>
</include>
In che modo USMT elabora ogni componente in un file .xml con più componenti?
L'ordinamento dei componenti non è importante. Ogni componente viene elaborato indipendentemente da altri componenti. Ad esempio, se una <regola di inclusione> si trova in un componente e una <regola locationModify> si trova in un altro componente per lo stesso file, viene eseguita la migrazione del file in entrambe le posizioni. Ovvero, il file viene incluso in base alla <regola di inclusione> e viene eseguita la migrazione del file in base alla <regola locationModify> .
Come vengono elaborate le regole?
Esistono due categorie generali di regole.
Regole che influiscono sul comportamento degli strumenti ScanState e LoadState. Ad esempio, le <regole include>, <exclude> e <unconditionalExclude> vengono elaborate per ogni componente nei file .xml . Per ogni componente, USMT crea un elenco di inclusione e un elenco di esclusione. Alcune delle regole nel componente potrebbero essere eliminate a causa della specificità, ma tutte le regole rimanenti vengono elaborate. Per ogni <regola di inclusione> , USMT scorre gli elementi per verificare se una delle posizioni deve essere esclusa. USMT enumera tutti gli oggetti e crea un elenco di oggetti che raccoglierà per ogni utente. Al termine dell'elenco, ogni oggetto viene archiviato o migrato nel computer di destinazione.
Regole che influiscono sul comportamento solo dello strumento LoadState. Ad esempio, le <regole locationModify>, <contentModify> e <destinationCleanup> non influiscono su ScanState. Vengono elaborati solo con LoadState. Innanzitutto, lo strumento LoadState determina il contenuto e la posizione di ogni componente in base alle <regole locationModify> e <contentModify> . LoadState elabora quindi tutte le <regole destinationCleanup> ed elimina i dati dal computer di destinazione. Infine, LoadState applica i componenti al computer.
In che modo USMT combina tutti i file .xml specificati nella riga di comando?
USMT non distingue i file.xml in base al nome o al contenuto. Elabora ogni componente all'interno dei file separatamente. USMT supporta più file .xml solo per semplificare la gestione e l'organizzazione dei componenti al loro interno. Poiché USMT usa un urlid per distinguere ogni componente dagli altri, assicurarsi che ogni .xml file specificato nella riga di comando disponga di un URL di migrazione univoco.
Regole <di inclusione> ed <esclusione>
Cosa accade quando sono presenti regole di inclusione> ed <esclusione> in <conflitto?
Se sono presenti regole in conflitto all'interno di un componente, viene applicata la regola più specifica, ad eccezione della <regola unconditionalExclude> , che ha la precedenza su tutte le altre regole. Se le regole sono ugualmente specifiche, non viene eseguita la migrazione dei dati. Ad esempio, se lo stesso file è sia escluso che incluso, la migrazione del file non viene eseguita. Se sono presenti regole in conflitto all'interno di componenti diversi, le regole non influiscono l'una sull'altra perché ogni componente viene elaborato in modo indipendente.
Nell'esempio seguente i file mp3 non vengono esclusi dalla migrazione. I file mp3 non vengono esclusi perché i nomi di directory hanno la precedenza sulle estensioni di file.
<include>
<objectSet>
<pattern type="File">C:\Data\* [*]</pattern>
</objectSet>
</include>
<exclude>
<objectSet>
<pattern type="File"> C:\* [*.mp3]</pattern>
</objectSet>
</exclude>
<esempi di precedenza delle regole di inclusione> ed <esclusione>
Questi esempi illustrano come USMT gestisce <le regole di inclusione> ed <esclusione> . Quando le regole si trovano in componenti diversi, il comportamento risultante è lo stesso indipendentemente dal fatto che i componenti siano nello stesso o in file di migrazione diversi.xml.
Inclusione ed esclusione di file
| Se il codice seguente esiste nello stesso componente | Comportamento risultante | Spiegazione |
|---|---|---|
|
Esegue la migrazione di tutti i file e le sottocartelle in Dir1 (inclusi tutti i file .txt in C:). | La <regola di esclusione> non influisce sulla migrazione perché la <regola di inclusione> è più specifica. |
|
Esegue la migrazione di tutti i file e le sottocartelle in C:\Dir1, ad eccezione dei file.txt in C:\Dir1\Dir2 e nelle relative sottocartelle. | Entrambe le regole vengono elaborate come previsto. |
|
Esegue la migrazione di tutti i file e le sottocartelle in C:\Dir1, ad eccezione dei file .txt in C:\Dir1 e nelle relative sottocartelle. | Entrambe le regole vengono elaborate come previsto. |
|
Non viene eseguita la migrazione di nulla. | Le regole sono ugualmente specifiche, quindi la <regola di esclusione> ha la precedenza sulla regola di< inclusione>. |
|
Esegue la migrazione dei file .txt in Dir1 e dei file .txt da sottocartelle diverse da Dir2. Non viene eseguita la migrazione di file da Dir2 o dalle relative sottocartelle. |
Entrambe le regole vengono elaborate come previsto. |
|
Esegue la migrazione di tutti i file e le sottocartelle di Dir2, ad eccezione dei file.txt da Dir1 e da tutte le sottocartelle di Dir1 (incluso Dir2). | Entrambe le regole vengono elaborate come previsto. |
| Se il codice seguente esiste in componenti diversi | Comportamento risultante | Spiegazione |
|---|---|---|
Componente 1:
Componente 2:
|
Esegue la migrazione di tutti i file e le sottocartelle di C:\Dir1\ (incluso C:\Dir1\Dir2). | Le regole che si trovano in componenti diversi non influiscono l'una sull'altra, ad eccezione della <regola unconditionalExclude> . Pertanto, in questo esempio, anche se alcuni file.txt sono stati esclusi durante l'elaborazione del componente 1, sono stati inclusi durante l'elaborazione del componente 2. |
Componente 1:
Componente 2:
|
Esegue la migrazione di tutti i file e le sottocartelle da Dir2, ad eccezione dei file .txt in C:\Dir1 e delle relative sottocartelle. | Entrambe le regole vengono elaborate come previsto. |
Componente 1:
Componente 2:
|
Esegue la migrazione di tutti i file .txt in Dir1 e in tutte le sottocartelle. | Il componente 1 non contiene una <regola di inclusione> , quindi la <regola di esclusione> non viene elaborata. |
Inclusione ed esclusione di oggetti del Registro di sistema
| Se il codice seguente esiste nello stesso componente | Comportamento risultante | Spiegazione |
|---|---|---|
|
Esegue la migrazione di tutte le chiavi in HKLM\Software\Microsoft\Command Processor tranne DefaultColor. | Entrambe le regole vengono elaborate come previsto. |
|
Esegue la migrazione solo di DefaultColor in HKLM\Software\Microsoft\Command Processor. | Viene eseguita la migrazione di DefaultColor perché la <regola di inclusione> è più specifica della <regola di esclusione> . |
|
Non esegue la migrazione di DefaultColor. | Le regole sono ugualmente specifiche, quindi la <regola di esclusione> ha la precedenza sulla regola di <inclusione> . |
| Se il codice seguente esiste in componenti diversi | Comportamento risultante | Spiegazione |
|---|---|---|
Componente 1:
Componente 2:
|
Esegue la migrazione di tutte le chiavi/valori in HKLM\Software\Microsoft\Command Processor. | Le regole che si trovano in componenti diversi non influiscono l'una sull'altra, ad eccezione della <regola unconditionalExclude> . In questo esempio, gli oggetti esclusi durante l'elaborazione del componente 1 sono stati inclusi durante l'elaborazione del componente 2. |
Conflitti di file
Qual è il comportamento predefinito in caso di conflitti di file?
Se non è presente una regola di <unione> , il comportamento predefinito per il Registro di sistema è che l'origine sovrascriva la destinazione. Il comportamento predefinito per i file è che l'origine venga rinominata in modo incrementale, ad esempio OriginalFileName(1). OriginalExtension, OriginalFileName(2). OriginalExtension e così via.
Come funziona la <regola di unione> quando si verificano conflitti di file?
Quando viene rilevata una collisione, USMT seleziona la regola di merge> più specifica< e la applica per risolvere il conflitto. Ad esempio, se esiste una <regola di merge> per C:\* [*] impostata su sourcePriority() e un'altra <regola di merge> per C:\sottocartella\* [*] impostata su destinationPriority() , USMT usa la regola destinationPriority() perché è la più specifica.
Scenario di esempio
Il computer di origine contiene i file seguenti:
C:\Data\SampleA.txtC:\Data\SampleB.txtC:\Data\Folder\SampleB.txt
Il computer di destinazione contiene i file seguenti:
C:\Data\SampleB.txtC:\Data\SampleB.txt
Un file .xml personalizzato contiene il codice seguente:
<include>
<objectSet>
<pattern type="File">c:\data\* [*]</pattern>
</objectSet>
</include>
Per questo esempio, le informazioni seguenti descrivono il comportamento risultante se il codice viene aggiunto al file di.xml personalizzato.
Esempio 1
<merge script="MigXmlHelper.DestinationPriority()">
<objectSet>
<pattern type="File">c:\data* []</pattern>
</objectSet>
</merge>
Risultato: durante ScanState, tutti i file vengono aggiunti all'archivio. Durante LoadState, viene ripristinato solo C:\Data\SampleA.txt .
Esempio 2
<merge script="MigXmlHelper.SourcePriority()">
<objectSet>
<pattern type="File">c:\data* []</pattern>
</objectSet>
</merge>
Risultato: durante ScanState, tutti i file vengono aggiunti all'archivio. Durante LoadState, tutti i file vengono ripristinati sovrascrivendo i file esistenti nel computer di destinazione.
Esempio 3
<merge script="MigXmlHelper.SourcePriority()">
<objectSet>
<pattern type="File">c:\data\ [*]</pattern>
</objectSet>
</merge>
Risultato: durante ScanState, tutti i file vengono aggiunti all'archivio. Durante LoadState, si verificano le azioni seguenti:
-
C:\Data\SampleA.txtviene ripristinato. -
C:\Data\SampleB.txtviene ripristinato sovrascrivendo il file esistente nel computer di destinazione. -
C:\Data\Folder\SampleB.txtnon vengono ripristinati.