Konflikte und Vorrang

Konflikte und Vorrang

Anzeige für geringe Bandbreite anschalten

Betrifft: Windows Vista

Beim Einschließen, Ausschließen oder Umleiten von Dateien und Einstellungen müssen Sie wissen, wie Konflikte und Vorrang von USMT behandelt werden. Im Folgenden sind die wichtigsten Richtlinien beschrieben, die Sie kennen müssen:

Wenn innerhalb einer Komponente miteinander im Konflikt stehende Regeln existieren, wird die spezifischste Regel angewendet. <unconditionalExclude> ist eine Ausnahme, weil sie Vorrang vor allen anderen Regeln erhält.
Nur Regeln innerhalb der gleichen Komponente können sich auf einander auswirken, abhängig von ihrer Spezifität. Regeln, die sich in verschiedenen Komponenten befinden, wirken sich nicht aufeinander aus (mit Ausnahme von <unconditionalExclude>).
Wenn Regeln im gleichen Maß spezifisch sind (z. B. wenn Sie eine Datei <ausschließen> (exclude) und die gleiche Datei <einschließen> (include)), erhält <ausschließen> Vorrang vor <einschließen>.
Die Reihenfolge von Komponenten spielt keine Rolle. Es spielt keine Rolle, welche Komponenten sich in welchen XML-Dateien befinden, weil jede Komponente unabhängig von allen anderen quer über alle XML-Dateien verarbeitet wird.
Die Reihenfolge von <include> und <exclude> innerhalb einer Komponente spielt keine Rolle.
Sie können das Element <unconditionalExclude> zum globalen Ausschließen von Daten verwenden. Dieses Element schließt Objekte unabhängig von allen anderen <include>-Regeln in den XML-Dateien aus – um beispielsweise alle MP3-Dateien auf dem Computer oder alle Dateien aus dem Verzeichnis C:\UserData auszuschließen.
Verzeichnisnamen erhalten Vorrang vor Dateierweiterungen. Betrachten Sie zum Beispiel Was geschieht bei miteinander im Konflikt stehenden <include>- und <exclude>-Regeln? und das erste Beispiel in Beispiele für den Vorrang bei <include> und <exclude>.

Inhalt dieses Themas

Allgemein

Welche Art von Beziehung besteht zwischen Regeln, die in verschiedenen Komponenten gespeichert sind?
Wie funktioniert Vorrang mit "Config.xml"?
Wie verarbeitet USMT die einzelnen Komponenten in einer XML-Datei mit mehreren Komponenten?
Wie werden Regeln verarbeitet?
Wie kombiniert USMT die in der Befehlszeile angegebenen XML-Dateien?

<include> und <exclude>

Was geschieht bei miteinander im Konflikt stehenden <include>- und <exclude>-Regeln?
Beispiele für den Vorrang bei <include> und <exclude>

Dateikonflikte

Was ist das Standardverhalten bei Dateikonflikten?
Wie funktioniert <merge> bei Dateikonflikten?

Allgemein

Welche Art von Beziehung besteht zwischen Regeln, die in verschiedenen Komponenten gespeichert sind?

Nur Regeln innerhalb der gleichen Komponente können sich auf einander auswirken, abhängig von ihrer Spezifität (mit Ausnahme von <unconditionalExclude>). Regeln, die sich in verschiedenen Komponenten befinden, wirken sich nicht aufeinander aus. Wenn eine Einschlussregel in einer Komponente und eine Ausschlussregel in einer anderen Komponente vorhanden ist, werden die Daten migriert, weil sie voneinander unabhängig sind.

Ein weiteres Beispiel ergibt sich bei einer <include>-Regel in einer Komponente und einer <locationModify>-Regel in einer anderen Komponente für die gleiche Datei. In diesem Fall wird die Datei zu beiden Speicherorten migriert – das heißt, sie wird aufgrund der <include>-Regel eingeschlossen und aufgrund der <locationModify>-Regel migriert. Mit der folgenden XML-Datei werden alle Dateien aus C:\Userdocs migriert, einschließlich MP3-Dateien, weil die Ausschlussregel in einer separaten Komponente angegeben ist.

<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\* [*]</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 Vorrang mit "Config.xml"?

Das Angeben von migrate="no" in Config.xml hat die gleiche Wirkung wie das Löschen der entsprechenden Komponente aus der XML-Migrationsdatei. Wenn Sie jedoch migrate="no" für Eigene Dokumente festlegen und eine Regel ähnlich der unten in einer XML-Migrationsdatei dargestellten (die alle DOC-Dateien aus Eigene Dokumente einschließt) verwenden, 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. Wenn Sie z. B. eine <include>-Regel in einer Komponente und eine <locationModify>-Regel in einer anderen Komponente für die gleiche Datei definiert haben, wird die Datei an beiden Speicherorten migriert. Das heißt, sie wird aufgrund der <include>-Regel eingeschlossen und aufgrund der <locationModify>-Regel migriert.

Wie werden Regeln verarbeitet?

Es bestehen zwei umfassende Kategorien von Regeln:

Regeln, die sich auf das Verhalten von ScanState und LoadState auswirken. Zum Beispiel <include>, <exclude> und <unconditionalExclude>. Diese Regeln werden für jede Komponente in den XML-Dateien verarbeitet. Für jede Komponente erstellt USMT eine Einschluss- und eine Ausschlussliste. Einige der Regeln in der Komponente können aufgrund ihrer Spezifität verworfen werden, alle verbleibenden Regeln werden jedoch verarbeitet. Für jede Einschlussregel arbeitet USMT die Elemente schrittweise ab, um festzustellen, ob einer der Speicherorte ausgeschlossen werden muss. USMT zählt alle Objekte auf und erstellt eine Liste der Objekte, die für jeden Benutzer erfasst werden sollen. Sobald die Liste vollständig ist, werden die einzelnen Objekte auf dem Zielcomputer gespeichert oder auf ihn migriert.
Regeln, die sich nur auf das Verhalten von LoadState auswirken. Zum Beispiel <locationModify>, <contentmodify> und <destinationCleanup>. Diese Regeln betreffen ScanState nicht – sie werden nur von LoadState verarbeitet. Zuerst bestimmt LoadState Inhalt und Speicherort der einzelnen Komponenten basierend auf den <locationModify>- und <contentModify>-Regeln. Anschließend verarbeitet LoadState alle <destinationCleanup>-Regeln und löscht Daten vom Zielcomputer. Anschließend wendet LoadState die Komponenten auf den Computer an.

Weitere Informationen finden Sie unter Interner USMT-Workflow.

Wie kombiniert USMT die in der Befehlszeile angegebenen XML-Dateien?

USMT unterscheidet die XML-Dateien nicht aufgrund von Name oder Inhalt. USMT verarbeitet jede Komponente innerhalb der Dateien separat. Der einzige Grund, aus dem USMT die Verwendung mehrerer XML-Dateien unterstützt, besteht in der einfacheren Wartung und Strukturierung der in ihnen definierten Komponenten. Stellen Sie lediglich sicher, dass jede in der Befehlszeile definierte XML-Datei über eine eindeutige Migrations-URLID verfügt. Dies hat den Grund, dass USMT die URLID zum Unterscheiden der einzelnen Komponenten verwendet.

<include> und <exclude>

Was geschieht bei miteinander im Konflikt stehenden <include>- und <exclude>-Regeln?

Wenn Regeln innerhalb einer Komponente miteinander in Konflikt stehen, wird die spezifischste Regel angewendet (mit Ausnahme von <unconditionalExclude>, die Vorrang vor allen anderen Regeln erhält). Wenn die Regeln in gleichem Maß spezifisch sind (wenn Sie eine Datei ausschließen und die gleiche Datei einschließen), werden die Daten nicht migriert. Wenn Regeln in verschiedenen Komponenten miteinander im Konflikt stehen, wirken sich die Regeln nicht aufeinander aus, da jede Komponente unabhängig verarbeitet wird. Im folgenden Beispiel werden MP3-Dateien nicht von der Migration ausgeschlossen. Der Grund dafür besteht darin, dass Verzeichnisnamen Vorrang von Dateierweiterungen erhalten.

<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 bei <include> und <exclude>

In diesen Beispielen wird das Verhalten bei gleichzeitig vorhandenen <include>- und <exclude>-Regeln erläutert. Wenn sich die Regeln in verschiedenen Komponenten befinden, ist das resultierende Verhalten gleich, unabhängig davon, ob sich die Komponenten in der gleichen oder in verschiedenen XML-Migrationsdatei(en) befinden.

Ein- und Ausschließen von Dateien
Ein- und Ausschließen von Registrierungsobjekten

Ein- und Ausschließen von Dateien

Wenn folgender Code in der gleichen Komponente vorliegt:	Resultierendes Verhalten	Erläuterung
Einschlussregel: <pattern type="Datei">C:\Verz1\* []</pattern> Ausschlussregel: <pattern type="Datei">C:\ [*.txt]</pattern>	Migriert alle Dateien und Unterordner in Verz1 (einschließlich aller TXT-Dateien auf C:).	Die Ausschlussregel wirkt sich nicht auf die Migration aus, weil die Einschlussregel spezifischer ist.
Einschlussregel: <pattern type="Datei">C:\Verz1\* []</pattern> Ausschlussregel: <pattern type="Datei">C:\Verz1\Verz2\ [*.txt]</pattern>	Migriert alle Dateien und Unterordner in C:\Verz1 mit Ausnahme der TXT-Dateien in C:\Verz1\Verz2 und deren Unterordner.	Beide Regeln werden wie beabsichtigt verarbeitet.
Einschlussregel: <pattern type="Datei">C:\Verz1\* []</pattern> Ausschlussregel: <pattern type="Datei">C:\Verz1\ [*.txt]</pattern>	Migriert alle Dateien und Unterordner in C:\Verz1 – mit Ausnahme der TXT-Dateien in C:\Verz1 und deren Unterordner.	Beide Regeln werden wie beabsichtigt verarbeitet.
Einschlussregel: <pattern type="Datei">C:\Verz1\Verz2\* [.txt]</pattern> Ausschlussregel: <pattern type="Datei">C:\Verz1\Verz2\ [*.txt]</pattern>	Nichts wird migriert.	Die Regeln sind gleichermaßen spezifisch, daher besitzt <Ausschließen> Vorrang vor <Einschließen>.
Einschlussregel: C:\Verz1\* [.txt] Ausschlussregel: C:\Verz1\Verz2\ [*]	Migriert die TXT-Dateien in Verz1 und die TXT-Dateien aus allen anderen Unterordnern als Verz2. Es werden keine Dateien aus Verz2 oder dessen Unterordnern migriert.	Beide Regeln werden wie beabsichtigt verarbeitet.
Einschlussregel: C:\Verz1\Verz2\* [] Ausschlussregel: C:\Verz1\ [*.txt]	Migriert alle Dateien und Unterordner von Verz2 – mit Ausnahme der TXT-Dateien aus Verz1 und aller Unterordner von Verz1 (einschließlich Verz2).	Beide Regeln werden wie beabsichtigt verarbeitet.

Wenn folgender Code in verschiedenen Komponenten vorliegt:	Resultierendes Verhalten	Erläuterung
Komponente 1: Einschlussregel: <pattern type="Datei">C:\Verz1\* []</pattern> Ausschlussregel: <pattern type="Datei">C:\Verz1\Verz2\ [.txt]</pattern> Komponente 2: Einschlussregel: <pattern type="Datei">C:\Verz1\Verz2\ [.txt]</pattern> Ausschlussregel: <pattern type="Datei">C:\Verz1\ [*]</pattern>	Migriert alle Dateien und Unterordner von C:\Verz1\ (einschließlich C:\Verz1\Verz2\).	Regeln, die sich in verschiedenen Komponenten befinden, wirken sich nicht aufeinander aus (Mit Ausnahme von <unconditionalExclude>). Daher wurden in diesem Beispiel einige TXT-Dateien, die bei der Verarbeitung von Komponente 1 ausgeschlossen wurden, bei der Verarbeitung von Komponente 2 eingeschlossen.
Komponente 1: Einschlussregel: C:\Verz1\Verz2\* [] Komponente 2: Ausschlussregel: C:\Verz1\ [*.txt]	Migriert alle Dateien und Unterordner aus Verz2, mit Ausnahme der TXT-Dateien in C:\Verz1 und dessen Unterordner.	Beide Regeln werden wie beabsichtigt verarbeitet.
Komponente 1: Ausschlussregel: C:\Verz1\Verz2\* [] Komponente 2: Einschlussregel: C:\Verz1\ [*.txt]	Migriert alle TXT-Dateien in Verz1 und allen Unterordnern.	Die Komponente 1 enthält keine <include>-Regel, daher wird die <exclude>-Regel nicht verarbeitet.

Wenn folgender Code in verschiedenen Komponenten vorliegt:

Resultierendes Verhalten

Erläuterung

Komponente 1:

Einschlussregel: <pattern type="Datei">C:\Verz1\* [*]</pattern>
Ausschlussregel: <pattern type="Datei">C:\Verz1\Verz2\* [*.txt]</pattern>

Komponente 2:

Einschlussregel: <pattern type="Datei">C:\Verz1\Verz2\* [*.txt]</pattern>
Ausschlussregel: <pattern type="Datei">C:\Verz1\* [*]</pattern>

Migriert alle Dateien und Unterordner von C:\Verz1\ (einschließlich C:\Verz1\Verz2\).

Regeln, die sich in verschiedenen Komponenten befinden, wirken sich nicht aufeinander aus (Mit Ausnahme von <unconditionalExclude>). Daher wurden in diesem Beispiel einige TXT-Dateien, die bei der Verarbeitung von Komponente 1 ausgeschlossen wurden, bei der Verarbeitung von Komponente 2 eingeschlossen.

Komponente 1:

Einschlussregel: C:\Verz1\Verz2\* [*]

Komponente 2:

Ausschlussregel: C:\Verz1\* [*.txt]

Migriert alle Dateien und Unterordner aus Verz2, mit Ausnahme der TXT-Dateien in C:\Verz1 und dessen Unterordner.

Beide Regeln werden wie beabsichtigt verarbeitet.

Komponente 1:

Ausschlussregel: C:\Verz1\Verz2\* [*]

Komponente 2:

Einschlussregel: C:\Verz1\* [*.txt]

Migriert alle TXT-Dateien in Verz1 und allen Unterordnern.

Die Komponente 1 enthält keine <include>-Regel, daher wird die <exclude>-Regel nicht verarbeitet.

Ein- und Ausschließen von Registrierungsobjekten

Wenn folgender Code in der gleichen Komponente vorliegt:	Resultierendes Verhalten	Erläuterung
Einschlussregel: HKLM\Software\Microsoft\Command Processor\* [*] Ausschlussregel: HKLM\Software\Microsoft\Command Processor [DefaultColor]	Migriert alle Schlüssel in HKLM\Software\Microsoft\Command Processor, mit Ausnahme von DefaultColor.	Beide Regeln werden wie beabsichtigt verarbeitet.
Einschlussregel: HKLM\Software\Microsoft\Command Processor [DefaultColor] Ausschlussregel: HKLM\Software\Microsoft\Command Processor\* [*]	Migriert nur DefaultColor in HKLM\Software\Microsoft\Command Processor.	DefaultColor wird migriert, weil die Einschlussregel spezifischer als die Ausschlussregel ist.
Einschlussregel: HKLM\Software\Microsoft\Command Processor [DefaultColor] Ausschlussregel: HKLM\Software\Microsoft\Command Processor [DefaultColor]	Default Color wird nicht migriert.	Die Regeln sind gleichermaßen spezifisch, daher besitzt <Ausschließen> Vorrang vor <Einschließen>.

Wenn folgender Code in verschiedenen Komponenten vorliegt:	Resultierendes Verhalten	Erläuterung
Komponente 1: Einschlussregel: HKLM\Software\Microsoft\Command Processor [DefaultColor] Ausschlussregel: HKLM\Software\Microsoft\Command Processor\* [] Komponente 2: Einschlussregel: HKLM\Software\Microsoft\Command Processor\ [*] Ausschlussregel: HKLM\Software\Microsoft\Command Processor [DefaultColor]	Migriert alle Schlüssel/Werte unter HKLM\Software\Microsoft\Command Processor.	Regeln, die sich in verschiedenen Komponenten befinden, wirken sich nicht aufeinander aus (Mit Ausnahme von <unconditionalExclude>). Daher wurden in diesem Beispiel die bei der Verarbeitung von Komponente 1 ausgeschlossenen Objekte bei der Verarbeitung von Komponente 2 eingeschlossen.

Wenn folgender Code in verschiedenen Komponenten vorliegt:

Resultierendes Verhalten

Erläuterung

Komponente 1:

Einschlussregel: HKLM\Software\Microsoft\Command Processor [DefaultColor]
Ausschlussregel: HKLM\Software\Microsoft\Command Processor\* [*]

Komponente 2:

Einschlussregel: HKLM\Software\Microsoft\Command Processor\* [*]
Ausschlussregel: HKLM\Software\Microsoft\Command Processor [DefaultColor]

Migriert alle Schlüssel/Werte unter HKLM\Software\Microsoft\Command Processor.

Regeln, die sich in verschiedenen Komponenten befinden, wirken sich nicht aufeinander aus (Mit Ausnahme von <unconditionalExclude>). Daher wurden in diesem Beispiel die bei der Verarbeitung von Komponente 1 ausgeschlossenen Objekte bei der Verarbeitung von Komponente 2 eingeschlossen.

Dateikonflikte

Was ist das Standardverhalten bei Dateikonflikten?

Wenn keine <merge>-Regel vorhanden ist, besteht das Standardverhalten für die Registrierung darin, dass die Quelle das Ziel überschreibt. Das Standardverhalten für Dateien besteht in der inkrementellen Umbenennung der Quelle — beispielsweise Originaldateiname(1).Originalerweiterung.

Wie funktioniert <merge> bei Dateikonflikten?

Wenn ein Dateikonflikt erkannt wird, sucht USMT die spezifischste Zusammenführungsregel aus und wendet sie an, um den Konflikt zu beheben. Wenn beispielsweise eine Zusammenführungsregel für C:\* [*] besteht, die auf to sourcePriority() festgelegt ist, und eine weitere Zusammenführungsregel für C:\subfolder\* [*], die auf destinationPriority() festgelegt ist verwendet USMT die Regel destinationPriority(), weil sie spezifischer ist.

Beispielszenario

Der Quellcomputer enthält folgende Dateien:

C:\Daten\MusterA.txt
C:\Daten\MusterB.txt
C:\Daten\Ordner\MusterB.txt

Der Zielcomputer enthält folgende Dateien:

C:\Daten\MusterB.txt
C:\Daten\Ordner\MusterB.txt

Sie verfügen über eine benutzerdefinierte XML-Datei, die folgenden Code enthält:

<include> 
   <objectSet> 
      <pattern type="file">c:\data\* [*]<pattern> 
   </objectSet> 
</include>

Beispielsweise wird in der folgenden Tabelle das resultierende Verhalten beschrieben, wenn der Code in der ersten Spalte der benutzerdefinierten XML-Datei hinzugefügt wird.

Wenn Sie den folgenden Code angeben:	Resultierendes Verhalten
<merge script>="MigXmlHelper.DestinationPriority()"> <objectSet> <pattern type="file">c:\data\* [*]<pattern> </objectSet> </merge>	Während der Ausführung von ScanState werden dem Informationsspeicher alle Dateien hinzugefügt. Während der Ausführung von LoadState wird nur C:\Daten\MusterA.txt wiederhergestellt.
<merge script>="MigXmlHelper.SourcePriority()"> <objectSet> <pattern type="file">c:\data\* [*]<pattern> </objectSet> </merge>	Während der Ausführung von ScanState werden dem Informationsspeicher alle Dateien hinzugefügt. Während der Ausführung von LoadState werden alle Dateien wiederhergestellt (wobei die vorhandenen Dateien auf dem Zielcomputer überschrieben werden).
<merge script>="MigXmlHelper.SourcePriority()"> <objectSet> <pattern type="file">c:\data\ [*]<pattern> </objectSet> </merge>	Während der Ausführung von ScanState werden dem Informationsspeicher alle Dateien hinzugefügt. Während der Ausführung von LoadState tritt Folgendes ein: C:\Daten\MusterA.txt wird wiederhergestellt. C:\Daten\MusterB.txt wird wiederhergestellt (wobei die vorhandene Datei auf dem Zielcomputer überschrieben wird). C:\Daten\Ordner\MusterB.txt wird nicht wiederhergestellt.

Wenn Sie den folgenden Code angeben:

Resultierendes Verhalten

<merge script>="MigXmlHelper.DestinationPriority()"> 
   <objectSet> 
      <pattern type="file">c:\data\* [*]<pattern> 
   </objectSet> 
</merge>

Während der Ausführung von ScanState werden dem Informationsspeicher alle Dateien hinzugefügt.

Während der Ausführung von LoadState wird nur C:\Daten\MusterA.txt wiederhergestellt.

<merge script>="MigXmlHelper.SourcePriority()"> 
   <objectSet> 
      <pattern type="file">c:\data\* [*]<pattern> 
   </objectSet> 
</merge>

Während der Ausführung von ScanState werden dem Informationsspeicher alle Dateien hinzugefügt.

Während der Ausführung von LoadState werden alle Dateien wiederhergestellt (wobei die vorhandenen Dateien auf dem Zielcomputer überschrieben werden).

<merge script>="MigXmlHelper.SourcePriority()"> 
   <objectSet> 
      <pattern type="file">c:\data\ [*]<pattern> 
   </objectSet> 
</merge>

Während der Ausführung von ScanState werden dem Informationsspeicher alle Dateien hinzugefügt.

Während der Ausführung von LoadState tritt Folgendes ein:

C:\Daten\MusterA.txt wird wiederhergestellt.
C:\Daten\MusterB.txt wird wiederhergestellt (wobei die vorhandene Datei auf dem Zielcomputer überschrieben wird).
C:\Daten\Ordner\MusterB.txt wird nicht wiederhergestellt.