Konflikte und Rangfolge
Wenn Sie Dateien und Einstellungen einschließen, ausschließen und umleiten, ist es wichtig zu wissen, wie User State Migration Tool (USMT) 5.0 Konflikte und die Rangfolge handhabt. Die folgenden Richtlinien für Konflikte und Rangfolge sind bei der Verwendung von USMT am wichtigsten.
Falls eine Komponente widersprüchliche Regeln enthält, wird die spezifischste Regel angewendet. Eine Ausnahme ist die <unconditionalExclude>-Regel, da sie Vorrang vor allen anderen Regeln hat. Verzeichnisnamen haben Vorrang vor Dateinamenerweiterungen. Beispiele finden Sie unter Was passiert, wenn widersprüchliche <include>- und <exclude>-Regeln vorhanden sind? und im ersten Beispiel unter Beispiele für den Vorrang von <include>- und <exclude>-Regelnweiter unten in diesem Thema.
Nur Regeln innerhalb derselben Komponente können einander je nach Genauigkeit beeinflussen. Regeln in unterschiedlichen Komponenten haben mit Ausnahme der <unconditionalExclude>-Regel keinen Einfluss aufeinander.
Wenn die Regeln gleich spezifisch sind, hat <exclude> Vorrang vor <include>. Wenn Sie z. B. mit der <exclude>-Regel eine Datei ausschließen und die gleiche Datei mit der <include>-Regel einschließen, wird die Datei ausgeschlossen.
Die Reihenfolge von Komponenten spielt keine Rolle. Es spielt keine Rolle, welche Komponenten in welcher XML-Datei aufgeführt sind, da jede Komponente unabhängig von den anderen Komponenten in allen XML-Dateien verarbeitet wird.
Die Reihenfolge der <include>- und <exclude>-Regeln in einer Komponente ist nicht von Bedeutung.
Mit dem <unconditionalExclude>-Element können Daten global ausgeschlossen werden. Dieses Element schließt Objekte unabhängig von anderen <include>-Regeln in den XML-Dateien aus. Sie können mit dem <unconditionalExclude>-Element z. B. alle MP3-Dateien auf dem PC oder alle Dateien in "C:\UserData" ausschließen.
Inhalt dieses Themas
Allgemeines
Welche Beziehung besteht zwischen Regeln in unterschiedlichen Komponenten?
Wie funktioniert die Rangfolge bei der Datei „Config.xml“?
Wie verarbeitet USMT die einzelnen Komponenten in einer XML-Datei mit mehreren Komponenten?
Wie werden Regeln verarbeitet?
Wie kombiniert USMT alle XML-Dateien, die ich in der Befehlszeile angebe?
<include>- und <exclude>-Regeln
Was passiert, wenn widersprüchliche <include>- und <exclude>-Regeln vorhanden sind?
Beispiele für den Vorrang von <include>- und <exclude>-Regeln
Dateikonflikte
Welches Standardverhalten wird bei Dateikonflikten angewendet?
Wie funktioniert die <merge>-Regel, wenn Dateikonflikte vorliegen?
Allgemeines
Welche Beziehung besteht zwischen Regeln in unterschiedlichen Komponenten?
Mit Ausnahme der <unconditionalExclude>-Regel können sich nur Regeln innerhalb derselben Komponente abhängig von ihrer Genauigkeit gegenseitig beeinflussen. Regeln in unterschiedlichen Komponenten haben keinen Einfluss aufeinander. Enthält eine Komponente eine <include>-Regel und eine andere Komponente eine identische <exclude>-Regel, werden die Daten migriert, weil die beiden Regeln unabhängig voneinander sind.
Enthält eine Komponente eine <include>-Regel und eine andere Komponente eine <locationModify>-Regel für die gleiche Datei, wird die Datei an beiden Stellen migriert. Sie wird also basierend auf der <include>-Regel eingeschlossen und basierend auf der <locationModify>-Regel migriert.
Die folgende XML-Datei migriert alle Dateien in „C:\Userdocs“ einschließlich MP3-Dateien, weil die <exclude>-Regel in einer separaten Komponente enthalten ist.
<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>
Wie funktioniert die Rangfolge bei der Datei „Config.xml“?
Das Angeben von migrate="no"
in der Datei "Config.xml" hat die gleiche Wirkung wie das Löschen der entsprechenden Komponente aus der XML-Migrationsdatei. Wenn Sie aber für "Eigene Dateien" migrate="no"
festlegen und in einer XML-Migrationsdatei eine Regel wie im folgenden Beispiel haben (die alle DOC-Dateien in "Eigene Dateien" einschließt), werden nur die DOC-Dateien migriert und alle anderen Dateien ausgeschlossen.
<include>
<objectSet>
<pattern type="File">%CSIDL_PERSONAL%\* [*.doc] </pattern>
</objectSet>
</include>
Wie verarbeitet USMT die einzelnen Komponenten in einer XML-Datei mit mehreren Komponenten?
Die Reihenfolge von Komponenten spielt keine Rolle. Jede Komponente wird unabhängig von anderen Komponenten verarbeitet. Enthält z. B. eine Komponente eine <include>-Regel und eine andere Komponente eine <locationModify>-Regel für die gleiche Datei, wird die Datei an beiden Stellen migriert. Sie wird also basierend auf der <include>-Regel eingeschlossen und basierend auf der <locationModify>-Regel migriert.
Wie werden Regeln verarbeitet?
Es gibt zwei allgemeine Kategorien von Regeln:
Regeln, die das Verhalten der Tools ScanState und LoadState beeinflussen. Die <include>-, <exclude>- und <unconditionalExclude>-Regeln werden z. B. für jede Komponente in den XML-Dateien verarbeitet. Für jede Komponente erstellt USMT eine Include-Liste und eine Exclude-Liste. Einige der Regeln in der Komponente können aufgrund der Genauigkeit verworfen werden, alle übrigen Regeln werden aber verarbeitet. Für jede <include>-Regel durchläuft USMT die Elemente, um zu überprüfen, ob Speicherorte ausgeschlossen werden müssen. USMT listet alle Objekte auf und erstellt eine Liste der Objekte, die für jeden Benutzer gesammelt werden. Sobald die Liste vollständig ist, wird jedes der Objekte zum Ziel-PC migriert oder dort gespeichert.
Regeln, die nur das Verhalten des Tools LoadState beeinflussen. Die <locationModify>-, <contentModify>- und <destinationCleanup>-Regeln haben z. B. keinen Einfluss auf ScanState. Sie werden nur mit LoadState verarbeitet. Als Erstes bestimmt LoadState anhand der <locationModify>- und <contentModify>-Regeln den Inhalt und Speicherort jeder Komponente. Anschließend verarbeitet LoadState alle <destinationCleanup>-Regeln und löscht Daten vom Ziel-PC. Zum Schluss wendet LoadState die Komponenten auf den PC an.
Wie kombiniert USMT alle XML-Dateien, die ich in der Befehlszeile angebe?
USMT unterscheidet nicht anhand des Namens oder Inhalts zwischen den XML-Dateien. Jede Komponente in den Dateien wird separat verarbeitet. USMT unterstützt die Verwendung mehrerer XML-Dateien, um die Verwaltung und Organisation der Komponenten in den Dateien zu erleichtern. Da USMT eine UrlId verwendet, um die Komponenten voneinander zu unterscheiden, müssen Sie sicherstellen, dass jede in der Befehlszeile angegebene XML-Datei eine eindeutige Migrations-UrlId besitzt.
<include>- und <exclude>-Regeln
Was passiert, wenn widersprüchliche <include>- und <exclude>-Regeln vorhanden sind?
Falls eine Komponente widersprüchliche Regeln enthält, wird die spezifischste Regel angewendet. Eine Ausnahme ist die <unconditionalExclude>-Regel, die Vorrang vor allen anderen Regeln hat. Wenn die Regeln gleich spezifisch sind, werden die Daten nicht migriert. Falls Sie z. B. eine Datei ausschließen und einschließen, wird die Datei nicht migriert. Enthalten unterschiedliche Komponenten widersprüchliche Regeln, haben diese keinen Einfluss aufeinander, weil jede Komponente separat verarbeitet wird.
Im folgenden Beispiel werden MP3-Dateien nicht von der Migration ausgeschlossen. Dies liegt daran, dass Verzeichnisnamen Vorrang vor Dateinamenerweiterungen haben.
<include>
<objectSet>
<pattern type="File">C:\Data\* [*]</pattern>
</objectSet>
</include>
<exclude>
<objectSet>
<pattern type="File"> C:\* [*.mp3]</pattern>
</objectSet>
</exclude>
Beispiele für den Vorrang von <include>- und <exclude>-Regeln
Die folgenden Beispiele veranschaulichen, wie USMT <include>- und <exclude>-Regeln handhabt. Wenn sich die Regeln in unterschiedlichen Komponenten befinden, ist das resultierende Verhalten gleich, unabhängig davon, ob die Komponenten in der gleichen oder in unterschiedlichen XML-Dateien enthalten sind.
Ein- und Ausschließen von Dateien
Ein- und Ausschließen von Registrierungsobjekten
Ein- und Ausschließen von Dateien
Wenn der folgende Code in derselben Komponente enthalten ist | Resultierendes Verhalten | Erläuterung |
---|---|---|
|
Migriert alle Dateien und Unterordner in „Dir1“ (einschließlich aller TXT-Dateien in „C:“). |
Die <exclude>-Regel hat keinen Einfluss auf die Migration, weil die <include>-Regel spezifischer ist. |
|
Migriert alle Dateien und Unterordner in „C:\Dir1“ mit Ausnahme der TXT-Dateien in „C:\Dir1\Dir2“ und den zugehörigen Unterordnern. |
Beide Regeln werden wie beabsichtigt verarbeitet. |
|
Migriert alle Dateien und Unterordner in „C:\Dir1“ mit Ausnahme der TXT-Dateien in „C:\Dir1“ und den zugehörigen Unterordnern. |
Beide Regeln werden wie beabsichtigt verarbeitet. |
|
Es werden keine Daten migriert. |
Da die Regeln gleich spezifisch sind, hat die <exclude>-Regel Vorrang vor der <include>-Regel. |
|
Migriert die TXT-Dateien in „Dir1“ und die TXT-Dateien in allen zugehörigen Unterordnern mit Ausnahme von „Dir2“. Es werden keine Dateien aus „Dir2“ oder den zugehörigen Unterordnern migriert. |
Beide Regeln werden wie beabsichtigt verarbeitet. |
|
Migriert alle Dateien und Unterordner in „Dir2“ mit Ausnahme der TXT-Dateien in „Dir1“ und allen Unterordnern von „Dir1“ (einschließlich „Dir2“). |
Beide Regeln werden wie beabsichtigt verarbeitet. |
Wenn der folgende Code in unterschiedlichen Komponenten enthalten ist | Resultierendes Verhalten | Erläuterung |
---|---|---|
Komponente 1:
Komponente 2:
|
Migriert alle Dateien und Unterordner in „C:\Dir1“\ (einschließlich C:\Dir1\Dir2\“). |
Mit Ausnahme der <unconditionalExclude>-Regel haben in unterschiedlichen Komponenten enthaltene Regeln keinen Einfluss aufeinander. Daher wurden in diesem Beispiel einige TXT-Dateien beim Verarbeiten von Komponente 2 eingeschlossen, obwohl sie beim Verarbeiten von Komponente 1 ausgeschlossen wurden. |
Komponente 1:
Komponente 2:
|
Migriert alle Dateien und Unterordner in „Dir2“ mit Ausnahme der TXT-Dateien in „C:\Dir1“ und den zugehörigen Unterordnern. |
Beide Regeln werden wie beabsichtigt verarbeitet. |
Komponente 1:
Komponente 2:
|
Migriert alle TXT-Dateien in „Dir1“ und den zugehörigen Unterordnern. |
Da Komponente 1 keine <include>-Regel enthält, wird die <exclude>-Regel nicht verarbeitet. |
Ein- und Ausschließen von Registrierungsobjekten
Wenn der folgende Code in derselben Komponente enthalten ist | Resultierendes Verhalten | Erläuterung |
---|---|---|
|
Migriert alle Schlüssel in „HKLM\Software\Microsoft\Command Processor“ mit Ausnahme von „DefaultColor“. |
Beide Regeln werden wie beabsichtigt verarbeitet. |
|
Migriert nur „DefaultColor“ in „HKLM\Software\Microsoft\Command Processor“. |
„DefaultColor“ wird migriert, weil die <include>-Regel spezifischer ist als die <exclude>-Regel. |
|
Migriert „DefaultColor“ nicht. |
Da die Regeln gleich spezifisch sind, hat die <exclude>-Regel Vorrang vor der <include>-Regel. |
Wenn der folgende Code in unterschiedlichen Komponenten enthalten ist | Resultierendes Verhalten | Erläuterung |
---|---|---|
Komponente 1:
Komponente 2:
|
Migriert alle Schlüssel/Werte unter „HKLM\Software\Microsoft\Command Processor“. |
Mit Ausnahme der <unconditionalExclude>-Regel haben in unterschiedlichen Komponenten enthaltene Regeln keinen Einfluss aufeinander. Daher wurden in diesem Beispiel die beim Verarbeiten von Komponente 1 ausgeschlossenen Objekte beim Verarbeiten von Komponente 2 eingeschlossen. |
Dateikonflikte
Welches Standardverhalten wird bei Dateikonflikten angewendet?
Wenn keine <merge>-Regel vorhanden ist, wird bei Registrierungswerten standardmäßig das Zielobjekt durch das Quellobjekt überschrieben. Das Standardverhalten für Dateien ist eine inkrementelle Umbenennung der Quelldatei, z. B. „UrsprünglicherDateiname(1).UrsprünglicheErweiterung“, „UrsprünglicherDateiname(2).UrsprünglicheErweiterung“ usw.
Wie funktioniert die <merge>-Regel, wenn Dateikonflikte vorliegen?
Wenn ein Konflikt erkannt wird, wird die spezifischste <merge>-Regel von USMT ausgewählt und zum Beheben des Konflikts angewendet. Wenn Sie z. B. eine <merge>-Regel für "C:\* [*]" auf sourcePriority() und eine weitere <merge>-Regel für "C:\subfolder\* [*]" auf destinationPriority() festgelegt haben, verwendet USMT die destinationPriority()-Regel, weil sie spezifischer ist.
Beispielszenarien
Der Quell-PC enthält die folgenden Dateien:
C:\Data\SampleA.txt
C:\Data\SampleB.txt
C:\Data\Folder\SampleB.txt
Der Ziel-PC enthält die folgenden Dateien:
C:\Data\SampleB.txt
C:\Data\Folder\SampleB.txt
Sie haben eine benutzerdefinierte XML-Datei mit dem folgenden Code:
<include>
<objectSet>
<pattern type="File">c:\data\* [*]</pattern>
</objectSet>
</include>
Die folgende Tabelle zeigt das resultierende Verhalten für dieses Beispiel, wenn Sie den Code in der ersten Spalte Ihrer benutzerdefinierten XML-Datei hinzufügen.
Wenn Sie folgenden Code angeben | Resultierendes Verhalten |
---|---|
|
Während der Ausführung von ScanState werden alle Dateien dem Speicher hinzugefügt. Während der Ausführung von LoadState wird nur „C:\Data\SampleA.txt“ wiederhergestellt. |
|
Während der Ausführung von ScanState werden alle Dateien dem Speicher hinzugefügt. Während der Ausführung von LoadState werden alle Dateien wiederhergestellt und die vorhandenen Dateien auf dem Ziel-PC überschrieben. |
|
Während der Ausführung von ScanState werden alle Dateien dem Speicher hinzugefügt. Während der Ausführung von LoadState passiert Folgendes:
|