Freigeben über

Konflikte und Rangfolge

Beim Einschließen, Ausschließen und Umleiten von Dateien und Einstellungen ist es wichtig zu wissen, wie das Migrationstool für den Benutzerstatus (User State Migration Tool, USMT) mit Konflikten und Rangfolge umgeht. Im Folgenden sind die wichtigsten Konflikte und Rangfolgenrichtlinien aufgeführt, die Sie bei der Arbeit mit USMT beachten sollten.

  • Wenn es in einer Komponente widersprüchliche Regeln gibt, wird die spezifischste Regel angewendet. Die <bedingungsloseExclude-Regel> ist jedoch eine Ausnahme, da sie Vorrang vor allen anderen hat. Verzeichnisnamen haben Vorrang vor Dateierweiterungen. Beispiele finden Sie unter Was geschieht, wenn es widersprüchliche <Ein-> und <Ausschlussregeln> gibt? und das erste Beispiel in <Beispielen für die Rangfolge von Ein-> und <Ausschlussregeln> weiter unten in diesem Artikel.

  • Je nach Spezifität können sich nur Regeln innerhalb derselben Komponente gegenseitig beeinflussen. Regeln, die sich in verschiedenen Komponenten befinden, wirken sich nicht gegenseitig aus, mit Ausnahme der <bedingungslosenExclude-Regel> .

  • Wenn die Regeln gleichermaßen spezifisch sind, <hat exclude> Vorrang vor <include>. Wenn beispielsweise die <Ausschlussregel> verwendet wird, um eine Datei auszuschließen und die <Include-Regel> zum Einschließen derselben Datei zu verwenden, wird die Datei ausgeschlossen.

  • Die Reihenfolge der 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 <Ein-> und <Ausschlussregeln> innerhalb einer Komponente spielt keine Rolle.

  • Das <bedingungsloseExclude-Element> kann verwendet werden, um Daten global auszuschließen. Dieses Element schließt Objekte aus, unabhängig von anderen <Includeregeln> , die sich in den .xml Dateien befinden. Beispielsweise kann das <bedingungsloseExclude-Element> verwendet werden, um alle MP3-Dateien auf dem Computer oder alle Dateien von C:\UserDataauszuschließen.

Allgemein

Welche Beziehung besteht zwischen Regeln, die sich in verschiedenen Komponenten befinden?

Nur Regeln innerhalb derselben Komponente können sich je nach Spezifität gegenseitig beeinflussen, mit Ausnahme der <bedingungslosenExclude-Regel> . Regeln, die sich in verschiedenen Komponenten befinden, wirken sich nicht gegenseitig aus. Wenn es eine <Includeregel> in einer Komponente und eine identische <Ausschlussregel> in einer anderen Komponente gibt, werden die Daten migriert, da die beiden Regeln voneinander unabhängig sind.

Wenn sich eine <Includeregel> in einer Komponente und eine locationModify-Regel> in einer< anderen Komponente für dieselbe Datei befindet, wird die Datei an beiden Stellen migriert. Das heißt, die Datei wird basierend auf der <Include-Regel> eingeschlossen, und die Datei wird basierend auf der <locationModify-Regel> migriert.

Die folgende .xml Datei migriert alle Dateien aus C:\Userdocs, einschließlich .mp3 Dateien, da 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\* [*.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 mit der Config.xml-Datei?

Die Angabe migrate="no" in der Config.xml Datei entspricht dem Löschen der entsprechenden Komponente aus der Migrationsdatei.xml Datei. Wenn migrate="no" jedoch für den Ordner Dokumente festgelegt ist, eine Regel ähnlich der folgenden Regel in einer Migration .xml Datei vorhanden ist (die alle .doc Dateien aus dem Ordner Dokumente enthält), werden nur die .doc Dateien migriert, und alle anderen Dateien werden ausgeschlossen:

<include>
   <objectSet>
      <pattern type="File">%CSIDL_PERSONAL%\* [*.doc] </pattern>
   </objectSet>
</include>

Wie verarbeitet USMT jede Komponente in einer .xml-Datei mit mehreren Komponenten?

Die Reihenfolge der Komponenten spielt keine Rolle. Jede Komponente wird unabhängig von anderen Komponenten verarbeitet. Wenn sich beispielsweise eine <Includeregel> in einer Komponente und eine locationModify-Regel> in einer< anderen Komponente für dieselbe Datei befindet, wird die Datei an beiden Stellen migriert. Das heißt, die Datei wird basierend auf der <Include-Regel> eingeschlossen, und die Datei wird basierend auf der <locationModify-Regel> migriert.

Wie werden Regeln verarbeitet?

Es gibt zwei allgemeine Kategorien von Regeln.

  • Regeln, die sich auf das Verhalten der Tools ScanState und LoadState auswirken. Beispielsweise werden die <Regeln include><, exclude> und <unconditionalExclude> für jede Komponente in den .xml-Dateien verarbeitet. Für jede Komponente erstellt USMT eine Includeliste und eine Ausschlussliste. Einige der Regeln in der Komponente werden möglicherweise aufgrund der Spezifität verworfen, aber alle verbleibenden Regeln werden verarbeitet. Für jede <Includeregel> durchläuft USMT die Elemente, um festzustellen, ob einer der Standorte ausgeschlossen werden muss. USMT listet alle Objekte auf und erstellt eine Liste der Objekte, die für jeden Benutzer gesammelt werden sollen. Sobald die Liste abgeschlossen ist, wird jedes der Objekte gespeichert oder auf den Zielcomputer migriert.

  • Regeln, die sich nur auf das Verhalten des LoadState-Tools auswirken. Beispielsweise wirken sich die <Regeln locationModify>, <contentModify> und <destinationCleanup> nicht auf ScanState aus. Sie werden nur mit LoadState verarbeitet. Zunächst bestimmt das LoadState-Tool den Inhalt und den Speicherort jeder Komponente basierend auf den <Regeln locationModify> und <contentModify> . Anschließend verarbeitet LoadState alle <destinationCleanup-Regeln> und löscht Daten vom Zielcomputer. Schließlich wendet LoadState die Komponenten auf den Computer an.

Wie kombiniert USMT alle .xml Dateien, die ich in der Befehlszeile angibt?

USMT unterscheidet die .xml Dateien nicht anhand ihres Namens oder Inhalts. Jede Komponente in den Dateien wird separat verarbeitet. USMT unterstützt mehrere .xml-Dateien nur, um die Verwaltung und Organisation der darin enthaltenen Komponenten zu vereinfachen. Da USMT eine urlid verwendet, um jede Komponente von den anderen zu unterscheiden, stellen Sie sicher, dass jede .xml Datei, die in der Befehlszeile angegeben ist, über eine eindeutige Migrations-URLID verfügt.

Die <Ein-> und <Ausschlussregeln>

Was geschieht, wenn es widersprüchliche <Ein-> und <Ausschlussregeln> gibt?

Wenn innerhalb einer Komponente widersprüchliche Regeln vorhanden sind, wird die spezifischste Regel angewendet, mit Ausnahme der <bedingungslosenExclude-Regel> , die Vorrang vor allen anderen Regeln hat. Wenn die Regeln gleichermaßen spezifisch sind, werden die Daten nicht migriert. Wenn beispielsweise dieselbe Datei sowohl ausgeschlossen als auch eingeschlossen ist, wird die Datei nicht migriert. Wenn in verschiedenen Komponenten widersprüchliche Regeln vorhanden sind, wirken sich die Regeln nicht gegenseitig aus, da jede Komponente unabhängig voneinander verarbeitet wird.

Im folgenden Beispiel werden MP3-Dateien nicht von der Migration ausgeschlossen. Die MP3-Dateien werden nicht ausgeschlossen, da Verzeichnisnamen Vorrang vor den Dateierweiterungen haben.

<include>
     <objectSet>
          <pattern type="File">C:\Data\* [*]</pattern>
     </objectSet>
</include>
<exclude>
     <objectSet>
          <pattern type="File"> C:\* [*.mp3]</pattern>
     </objectSet>
</exclude>

<Beispiele für die Rangfolge von Include-> und <Exclude-Regeln>

In diesen Beispielen wird erläutert, wie USMT mit <Ein-> und <Ausschlussregeln> umgeht. Wenn sich die Regeln in verschiedenen Komponenten befinden, ist das resultierende Verhalten gleich, unabhängig davon, ob sich die Komponenten in demselben oder in unterschiedlichen Migrationsdateien.xml Befinden.

Einschließen und Ausschließen von Dateien

Wenn der folgende Code in derselben Komponente vorhanden ist Resultierendes Verhalten Erläuterung
  • Include-Regel: <pattern type="File">C:\Dir1* []</pattern>
  • Ausschlussregel: <pattern type="File">C:* [.txt]</pattern>
 Migriert alle Dateien und Unterordner in Dir1 (einschließlich aller .txt Dateien in C:). Die <Ausschlussregel> wirkt sich nicht auf die Migration aus, da die <Include-Regel> spezifischer ist.
  • Include-Regel: <pattern type="File">C:\Dir1* []</pattern>
  • Ausschlussregel: <pattern type="File">C:\Dir1\Dir2* [.txt]</pattern>
 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.
  • Include-Regel: <pattern type="File">C:\Dir1* []</pattern>
  • Ausschlussregel: <pattern type="File">C:\Dir1\ * [.txt]</pattern>
 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.
  • Include rule: <pattern type="File">C:\Dir1\Dir2* [.txt]</pattern>
  • Ausschlussregel: <pattern type="File">C:\Dir1\Dir2* [.txt]</pattern>
 Es wird nichts migriert. Die Regeln sind ebenso spezifisch, sodass die <Ausschlussregel> Vorrang vor der <Include-Regel> hat.
  • Include-Regel: C:\Dir1* [.txt]
  • Ausschlussregel: C:\Dir1\Dir2* []
 Migriert die .txt-Dateien in Dir1 und die .txt Dateien aus anderen Unterordnern als Dir2.
Es werden keine Dateien aus Dir2 oder den zugehörigen Unterordnern migriert.		 Beide Regeln werden wie beabsichtigt verarbeitet.
  • Regel einschließen: C:\Dir1\Dir2* []
  • Ausschlussregel: C:\Dir1* [.txt]
 Migriert alle Dateien und Unterordner von Dir2 mit Ausnahme der .txt Dateien aus Dir1 und allen Unterordnern von Dir1 (einschließlich Dir2). Beide Regeln werden wie beabsichtigt verarbeitet.
Wenn der folgende Code in verschiedenen Komponenten vorhanden ist Resultierendes Verhalten Erläuterung
Komponente 1:
  • Include-Regel: <pattern type="File">C:\Dir1* []</pattern>
  • Ausschlussregel: <pattern type="File">C:\Dir1\Dir2* [.txt]</pattern>

Komponente 2:
  • Include rule: <pattern type="File">C:\Dir1\Dir2* [.txt]</pattern>
  • Ausschlussregel: <pattern type="File">C:\Dir1* []</pattern>
 Migriert alle Dateien und Unterordner von C:\Dir1\ (einschließlich C:\Dir1\Dir2). Regeln, die sich in verschiedenen Komponenten befinden, wirken sich nicht gegenseitig aus, mit Ausnahme der <bedingungslosenExclude-Regel> . Daher wurden in diesem Beispiel einige .txt Dateien bei der Verarbeitung von Komponente 1 ausgeschlossen, sie wurden jedoch bei der Verarbeitung von Komponente 2 eingeschlossen.
Komponente 1:
  • Regel einschließen: C:\Dir1\Dir2* []

Komponente 2:
  • Ausschlussregel: C:\Dir1* [.txt]
 Migriert alle Dateien und Unterordner aus Dir2 mit Ausnahme der .txt Dateien in C:\Dir1 und den zugehörigen Unterordnern. Beide Regeln werden wie beabsichtigt verarbeitet.
Komponente 1:
  • Ausschlussregel: C:\Dir1\Dir2* []

Komponente 2:
  • Include-Regel: C:\Dir1* [.txt]
 Migriert alle .txt Dateien in Dir1 und alle Unterordner. Komponente 1 enthält <keine Includeregel> , sodass die <Ausschlussregel> nicht verarbeitet wird.

Ein- und Ausschließen von Registrierungsobjekten

Wenn der folgende Code in derselben Komponente vorhanden ist Resultierendes Verhalten Erläuterung
  • Regel einschließen:
    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.
  • Regel einschließen:
    HKLM\Software\Microsoft\Command Processor [DefaultColor]
  • Ausschlussregel:
    HKLM\Software\Microsoft\Command Processor* []
 Migriert nur DefaultColor in HKLM\Software\Microsoft\Command Processor. DefaultColor wird migriert, da die <Include-Regel> spezifischer ist als die <Ausschlussregel> .
  • Regel einschließen:
    HKLM\Software\Microsoft\Command Processor [DefaultColor]
  • Ausschlussregel:
    HKLM\Software\Microsoft\Command Processor [DefaultColor]
 Migriert DefaultColor nicht. Die Regeln sind ebenso spezifisch, sodass die <Ausschlussregel> Vorrang vor der <Include-Regel> hat.
Wenn der folgende Code in verschiedenen Komponenten vorhanden ist Resultierendes Verhalten Erläuterung
Komponente 1:
  • Regel einschließen:
    HKLM\Software\Microsoft\Command Processor [DefaultColor]
  • Ausschlussregel:
    HKLM\Software\Microsoft\Command Processor* []

Komponente 2:
  • Regel einschließen:
    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 gegenseitig aus, mit Ausnahme der <bedingungslosenExclude-Regel> . In diesem Beispiel wurden die Objekte, die bei der Verarbeitung von Komponente 1 ausgeschlossen wurden, bei der Verarbeitung von Komponente 2 eingeschlossen.

Dateikonflikte

Was ist das Standardverhalten bei Dateikonflikten?

Wenn keine <Mergeregel> vorhanden ist, besteht das Standardverhalten für die Registrierung darin, dass die Quelle das Ziel überschreibt. Das Standardverhalten für Dateien besteht darin, dass die Quelle inkrementell umbenannt wird, z. B. OriginalFileName(1). OriginalExtension, OriginalFileName(2). OriginalExtension usw.

Wie funktioniert die <Mergeregel> bei Dateikonflikten?

Wenn ein Konflikt erkannt wird, wählt USMT die spezifischste <Mergeregel> aus und wendet sie an, um den Konflikt zu lösen. Wenn beispielsweise eine <Mergeregel> für C:\* [*] vorhanden ist, die auf sourcePriority() festgelegt ist, und eine andere <Mergeregel> für C:\unterordner\* [*] auf destinationPriority() festgelegt ist, verwendet USMT die destinationPriority() -Regel, da sie die spezifischste ist.

Beispielszenarien

Der Quellcomputer enthält die folgenden Dateien:

  • C:\Data\SampleA.txt

  • C:\Data\SampleB.txt

  • C:\Data\Folder\SampleB.txt

Der Zielcomputer enthält die folgenden Dateien:

  • C:\Data\SampleB.txt

  • C:\Data\SampleB.txt

Eine benutzerdefinierte .xml-Datei enthält den folgenden Code:

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

In diesem Beispiel beschreiben die folgenden Informationen das resultierende Verhalten, wenn der Code der benutzerdefinierten .xml-Datei hinzugefügt wird.

Beispiel 1

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

Ergebnis: Während ScanState werden alle Dateien dem Speicher hinzugefügt. Während LoadState wird nur C:\Data\SampleA.txt wiederhergestellt.

Beispiel 2

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

Ergebnis: Während ScanState werden alle Dateien dem Speicher hinzugefügt. Während LoadState werden alle Dateien wiederhergestellt, wobei die vorhandenen Dateien auf dem Zielcomputer überschrieben werden.

Beispiel 3

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

Ergebnis: Während ScanState werden alle Dateien dem Speicher hinzugefügt. Während LoadState treten die folgenden Aktionen auf:

  • C:\Data\SampleA.txt wird wiederhergestellt.
  • C:\Data\SampleB.txt wird wiederhergestellt, wobei die vorhandene Datei auf dem Zielcomputer überschrieben wird.
  • C:\Data\Folder\SampleB.txt werden nicht wiederhergestellt.

USMT-XML-Referenz.