Funktionsweise von USMT

USMT umfasst zwei Tools zum Migrieren von Einstellungen und Daten: ScanState und LoadState. ScanState sammelt Informationen vom Quellcomputer, und LoadState wendet diese Informationen auf den Zielcomputer an.

Hinweis

Weitere Informationen dazu, wie USMT die Regeln und die XML-Dateien verarbeitet, finden Sie unter Konflikte und Rangfolge.

Der ScanState-Prozess

Wenn das ScanState-Tool auf dem Quellcomputer ausgeführt wird, durchläuft es den folgenden Prozess:

  1. Es analysiert und überprüft die Befehlszeilenparameter, erstellt die ScanState.log Datei und beginnt dann mit der Protokollierung.

  2. Es sammelt Informationen zu allen Migrationskomponenten, die migriert werden müssen. Eine Migrationskomponente ist eine logische Gruppe von Dateien, Registrierungsschlüsseln und Werten. Beispielsweise wird der Satz von Dateien, Registrierungsschlüsseln und Werten, die die Einstellungen von Adobe Acrobat speichern, in einer einzelnen Migrationskomponente gruppiert.

    Es gibt drei Arten von Komponenten:

    • Komponenten, die die Betriebssystemeinstellungen migrieren.

    • Komponenten, die Anwendungseinstellungen migrieren.

    • Komponenten, die Benutzerdateien migrieren.

    Das ScanState-Tool sammelt Informationen zu den Anwendungseinstellungen und Benutzerdatenkomponenten aus den .xml Dateien, die in der Befehlszeile angegeben sind.

    In derzeit unterstützten Versionen von Windows steuern die Manifestdateien, wie die Betriebssystemeinstellungen migriert werden. Diese Dateien können nicht geändert werden. Um bestimmte Betriebssystemeinstellungen auszuschließen, muss eine Config.xml Datei erstellt und geändert werden.

  3. ScanState bestimmt, welche Benutzerprofile migriert werden sollen. Standardmäßig werden alle Benutzerprofile auf dem Quellcomputer migriert. Benutzer können jedoch mithilfe der Benutzeroptionen eingeschlossen und ausgeschlossen werden. Das Profil System und das öffentliche Profil auf einem Quellcomputer, auf dem derzeit unterstützte Versionen von Windows ausgeführt werden, werden immer migriert, und diese Profile können nicht von der Migration ausgeschlossen werden.

  4. In der Überprüfungsphase führt ScanState für jedes Benutzerprofil, das für die Migration ausgewählt wurde, Folgendes aus:

    1. ScanState überprüft für jede Komponente den Typ der Komponente. Wenn das aktuelle Benutzerprofil das Systemprofil ist und der Komponententyp System oder UserAndSystem lautet, wird die Komponente für diesen Benutzer ausgewählt. Andernfalls wird die Komponente ignoriert. Wenn das aktuelle Benutzerprofil nicht das Systemprofil ist und der Komponententyp User oder UserAndSystem lautet, wird die Komponente für diesen Benutzer ausgewählt. Andernfalls wird diese Komponente ignoriert.

      Hinweis

      Ab diesem Zeitpunkt unterscheidet ScanState nicht mehr zwischen Komponenten, die Betriebssystemeinstellungen migrieren, Komponenten, die Anwendungseinstellungen migrieren, und Komponenten, die Benutzerdateien migrieren. ScanState verarbeitet alle Komponenten auf die gleiche Weise.

    2. Jede Komponente, die im vorherigen Schritt ausgewählt wurde, wird weiter verarbeitet. Profilspezifische Variablen (z . B. CSIDL_PERSONAL) werden im Kontext des aktuellen Profils ausgewertet. Wenn das zu verarbeitende Profil beispielsweise zu User1 gehört, würde CSIDL_PERSONAL auf C:\Users\User1\Documentserweitert, vorausgesetzt, dass die Benutzerprofile im C:\Users Verzeichnis gespeichert sind.

    3. ScanState wertet für jede ausgewählte Komponente den <Abschnitt detects> aus. Wenn die Bedingung im <Abschnitt "detects> " als false ausgewertet wird, wird die Komponente nicht weiter verarbeitet. Andernfalls wird die Verarbeitung dieser Komponente fortgesetzt.

    4. ScanState wertet für jede ausgewählte Komponente die <Regelabschnitte> aus. Wenn das aktuelle Benutzerprofil für jeden <Regelabschnitt> das Systemprofil und der Kontext des <Regelabschnitts>System oder UserAndSystem ist, wird die Regel weiter verarbeitet. Andernfalls wird diese Regel ignoriert. Wenn das aktuelle Benutzerprofil nicht das Systemprofil ist und der Kontext des <Regelabschnitts>"User " oder " UserAndSystem" lautet, wird die Regel weiter verarbeitet. Andernfalls wird diese Regel ignoriert.

    5. ScanState erstellt eine Liste der Migrationseinheiten, die migriert werden müssen, indem die verschiedenen Unterabschnitte in diesem <Regelabschnitt> verarbeitet werden. Jede Einheit wird erfasst, wenn die Einheit in einem <Include-Unterabschnitt> erwähnt wird, solange es keine spezifischere Regel für sie in einem <Ausschlussunterabschnitt> im selben <Regelabschnitt> gibt. Weitere Informationen zur Rangfolge in den .xml-Dateien finden Sie unter Konflikte und Rangfolge.

      Darüber hinaus wird jede Migrationseinheit (z. B. eine Datei, ein Registrierungsschlüssel oder eine Gruppe von Registrierungswerten), die sich in einem <Bedingungsexclude-Abschnitt> befindet, nicht migriert.

      Hinweis

      ScanState ignoriert einige Unterabschnitte wie <destinationCleanup> und <locationModify>. Diese Abschnitte werden nur auf dem Zielcomputer ausgewertet.

  5. In der Sammlungsphase erstellt ScanState eine zentrale Liste der Migrationseinheiten, indem die Listen kombiniert werden, die für jedes ausgewählte Benutzerprofil erstellt wurden.

  6. In der Speicherphase schreibt ScanState die gesammelten Migrationseinheiten in den Speicherort.

    Hinweis

    ScanState ändert den Quellcomputer in keiner Weise.

Der LoadState-Prozess

Der LoadState-Prozess ähnelt dem ScanState-Prozess . Das ScanState-Tool sammelt Migrationseinheiten wie Datei, Registrierungsschlüssel oder Registrierungswerte vom Quellcomputer und speichert sie im Speicher. Ebenso sammelt das LoadState-Tool Migrationseinheiten aus dem Speicher und wendet sie auf den Zielcomputer an.

  1. ScanState analysiert und überprüft die Befehlszeilenparameter, erstellt die ScanState.log Datei und beginnt dann mit der Protokollierung.

  2. LoadState sammelt Informationen zu den Migrationskomponenten, die migriert werden müssen.

    LoadState ruft Informationen für die Anwendungseinstellungen-Komponenten und Benutzerdatenkomponenten aus der Migration .xml Dateien ab, die durch den LoadState.exe Befehl angegeben werden.

    In derzeit unterstützten Versionen von Windows steuern die Manifestdateien, wie die Betriebssystemeinstellungen migriert werden. Diese Dateien können nicht geändert werden. Um bestimmte Betriebssystemeinstellungen auszuschließen, muss eine Config.xml Datei erstellt und geändert werden.

  3. LoadState bestimmt, welche Benutzerprofile migriert werden sollen. Standardmäßig werden alle auf dem Quellcomputer vorhandenen Benutzerprofile migriert. Benutzer können jedoch mithilfe der Benutzeroptionen eingeschlossen und ausgeschlossen werden. Das Profil System und das Öffentliche Profil auf einem Quellcomputer, auf dem derzeit unterstützte Versionen von Windows ausgeführt werden, werden immer migriert, und diese Profile können nicht von der Migration ausgeschlossen werden.

    • Wenn lokale Benutzerkonten migriert werden und die Konten noch nicht auf dem Zielcomputer vorhanden sind, muss die /lac Befehlszeilenoption verwendet werden. Wenn die /lac Option nicht angegeben ist, werden alle lokalen Benutzerkonten, die noch nicht auf dem Zielcomputer vorhanden sind, nicht migriert.

    • Bei Angabe mit dem LoadState.exe Befehl werden die /md Optionen und /mu verarbeitet, um das Benutzerprofil auf dem Zielcomputer umzubenennen.

    • Für jedes aus dem Speicher ausgewählte Benutzerprofil erstellt LoadState ein entsprechendes Benutzerprofil auf dem Zielcomputer. Der Zielcomputer muss nicht mit der Domäne verbunden sein, damit Domänenbenutzerprofile erstellt werden können. Wenn USMT eine Domäne nicht ermitteln kann, wird versucht, die Einstellungen auf ein lokales Konto anzuwenden. Weitere Informationen finden Sie unter Identifizieren von Benutzern.

  4. In der Überprüfungsphase führt LoadState für jedes Benutzerprofil Folgendes aus:

    1. Für jede Komponente überprüft LoadState den Typ der Komponente. Wenn das aktuelle Benutzerprofil das Systemprofil ist und der Komponententyp System oder UserAndSystem lautet, wird die Komponente für diesen Benutzer ausgewählt. Andernfalls wird die Komponente ignoriert. Wenn das aktuelle Benutzerprofil nicht das Systemprofil ist und der Komponententyp User oder UserAndSystem lautet, wird die Komponente für diesen Benutzer ausgewählt. Andernfalls wird diese Komponente ignoriert.

      Hinweis

      Ab diesem Zeitpunkt unterscheidet LoadState nicht mehr zwischen Komponenten, die Betriebssystemeinstellungen migrieren, Komponenten, die Anwendungseinstellungen migrieren, und Komponenten, die Benutzerdateien migrieren. LoadState wertet alle Komponenten auf die gleiche Weise aus.

    2. Jede ausgewählte Komponente wird weiter verarbeitet. Profilspezifische Variablen (z . B. CSIDL_PERSONAL) werden im Kontext des aktuellen Profils ausgewertet. Wenn das zu verarbeitende Profil z. B. zu User1 gehört, würde CSIDL_PERSONAL auf C:\Users\User1\Documents erweitert (vorausgesetzt, dass die Benutzerprofile im C:\Users Verzeichnis gespeichert sind).

      Hinweis

      LoadState ignoriert den abschnitt detects>, der< in einer Komponente angegeben ist. An diesem Punkt gelten alle angegebenen Komponenten als erkannt und werden für die Migration ausgewählt.

    3. Für jede ausgewählte Komponente wertet LoadState die <Regelabschnitte> aus. Wenn das aktuelle Benutzerprofil für jeden <Regelabschnitt> das Systemprofil und der Kontext des <Regelabschnitts>System oder UserAndSystem ist, wird die Regel weiter verarbeitet. Andernfalls wird diese Regel ignoriert. Wenn das aktuelle Benutzerprofil nicht das Systemprofil ist und der Kontext des <Regelabschnitts>"User " oder " UserAndSystem" lautet, wird die Regel weiter verarbeitet. Andernfalls wird diese Regel ignoriert.

    4. LoadState erstellt eine zentrale Liste von Migrationseinheiten, indem die verschiedenen Unterabschnitte im <Abschnitt "Rules> " verarbeitet werden. Jede Migrationseinheit, die sich in einem <Include-Unterabschnitt> befindet, wird so lange migriert, da es keine spezifischere Regel für sie in einem <Ausschlussunterabschnitt> im selben <Regelabschnitt> gibt. Weitere Informationen zur Rangfolge finden Sie unter Konflikte und Rangfolge.

    5. LoadState wertet die zielcomputerspezifischen Unterabschnitte aus, z. B. die <Unterabschnitte destinationCleanup> und <locationModify> .

    6. Wenn auf dem Zielcomputer eine derzeit unterstützte Version von Windows ausgeführt wird, werden die migunits, die von ScanState mithilfe von Manifestdateien auf downer Ebene gesammelt wurden, von LoadState mithilfe des entsprechenden Komponentenmanifests aus der windows-Version verarbeitet. Die downlevel-Manifestdateien werden während LoadState nicht verwendet.

      Wichtig

      Damit LoadState die .xml Dateien verwenden kann, ist es wichtig, sie mit dem LoadState.exe Befehl anzugeben. Andernfalls werden alle zielspezifischen Regeln, z <. B. locationModify>, in diesen.xmlDateien ignoriert, auch wenn bei ausführung des ScanState.exe Befehls die gleichen.xmlDateien bereitgestellt wurden.

  5. In der Phase Anwenden schreibt LoadState die Migrationseinheiten, die gesammelt wurden, an die verschiedenen Speicherorte auf dem Zielcomputer. Wenn Konflikte auftreten und keine <Mergeregel> für das Objekt 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. Einige Einstellungen, z. B. Schriftarten, Hintergrundbilder und Bildschirmschonereinstellungen, werden erst wirksam, wenn sich der Benutzer das nächste Mal anmeldet. Melden Sie sich aus diesem Grund ab, wenn die LoadState.exe Befehlsaktionen abgeschlossen sind.