Funktionsweise von USMT

  • Artikel

USMT enthält zwei Tools zum Migrieren von Einstellungen und Daten: ScanState und LoadState. ScanState sammelt Informationen vom Quell-PC, und LoadState wendet diese Informationen auf dem Ziel-PC an.

  • ScanState-Vorgang

  • LoadState-Vorgang

    Hinweis

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

ScanState-Vorgang

Wenn Sie das Tool ScanState auf dem Quell-PC ausführen, durchläuft es den folgenden Prozess:

  1. Es analysiert und überprüft die Befehlszeilenparameter, erstellt die Datei „ScanState.log“ und beginnt 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 Registrierungswerten. Die Dateien, Registrierungsschlüssel und Registrierungswerte, in denen die Einstellungen von Adobe Acrobat gespeichert sind, werden z. B. zu einer Migrationskomponente zusammengefasst.

    Es gibt drei Arten von Komponenten:

    • Komponenten, die Betriebssystemeinstellungen migrieren

    • Komponenten, die App-Einstellungen migrieren

    • Komponenten, die Dateien des Benutzers migrieren

    ScanState sammelt Informationen zu den App-Einstellungs- und Benutzerdatenkomponenten in den XML-Dateien, die in der Befehlszeile angegeben werden.

    In Windows Vista®, Windows 7 und Windows 8 steuern die Manifestdateien, wie die Betriebssystemeinstellungen migriert werden. Diese Dateien können nicht geändert werden. Falls Sie bestimmte Betriebssystemeinstellungen ausschließen möchten, müssen Sie eine Datei „Config.xml“ erstellen und ändern.

  3. ScanState ermittelt, welche Benutzerprofile migriert werden sollen. Standardmäßig werden alle Benutzerprofile auf dem Quell-PC migriert. Sie können Benutzer aber mit den Benutzeroptionen ein- und ausschließen. Das Systemprofil „Alle Benutzer“ auf einem Quell-PC unter Windows(R) XP oder das Profil „Öffentlich“ auf einem Quell-PC unter Windows Vista, Windows 7 und Windows 8 wird immer migriert und kann nicht von der Migration ausgeschlossen werden.

  4. In der Überprüfungsphase führt ScanState für jedes zur Migration ausgewählte Benutzerprofil die folgenden Schritte aus:

    1. ScanState überprüft den Typ jeder Komponente. Ist das aktuelle Benutzerprofil das Systemprofil und der Komponententyp „System” oder „UserAndSystem“, wird die Komponente für den Benutzer ausgewählt. Andernfalls wird die Komponente ignoriert. Ist das aktuelle Benutzerprofil nicht das Systemprofil und der Komponententyp ist „User” oder „UserAndSystem“, wird die Komponente für den Benutzer ausgewählt. Andernfalls wird die Komponente ignoriert.

      Hinweis

      Ab diesem Punkt des Prozesses unterscheidet ScanState nicht mehr zwischen den Komponenten, die Betriebssystemeinstellungen migrieren, denen, die App-Einstellungen migrieren, und denen, die Dateien des Benutzers migrieren. Alle Komponenten werden von ScanState auf die gleiche Weise verarbeitet.

    2. Jede Komponente, die im vorhergehenden Schritt ausgewählt wurde, wird weiter verarbeitet. Alle profilspezifischen Variablen (z. B. CSIDL_PERSONAL) werden im Kontext des aktuellen Profils ausgewertet. Wenn das verarbeitete Profil z. B. zu „User1“ gehört, wird CSIDL_PERSONAL zu „C:\Users\User1\Documents“ erweitert (sofern Benutzerprofile im Verzeichnis „C:\Users“ gespeichert werden).

    3. ScanState wertet für jede ausgewählte Komponente den <detects>-Abschnitt aus. Wenn die Bedingung im <detects>-Abschnitt zu FALSE ausgewertet wird, wird die Komponente nicht weiter verarbeitet. Andernfalls wird die Verarbeitung der Komponente fortgesetzt.

    4. ScanState wertet für jede ausgewählte Komponente die <rules>-Abschnitte aus. Ist das aktuelle Benutzerprofil das Systemprofil und der Kontext des <rules>-Abschnitts „System“ oder „UserAndSystem“, wird die Regel weiter verarbeitet. Andernfalls wird die Regel ignoriert. Ist das aktuelle Benutzerprofil nicht das Systemprofil und der Kontext des <rules>-Abschnitts ist „User“ oder „UserAndSystem“, wird die Regel weiter verarbeitet. Andernfalls wird die Regel ignoriert.

    5. ScanState verarbeitet die verschiedenen Unterabschnitte des <rules>-Abschnitts, um eine Liste der Migrationseinheiten zu erstellen, die migriert werden müssen. Jede in einem <include>-Unterabschnitt enthaltene Einheit wird gesammelt, sofern keine spezifischere Regel in einem <exclude>-Unterabschnitt desselben <rules>-Abschnitts für die Einheit vorhanden ist. Weitere Informationen zur Rangfolge in den XML-Dateien finden Sie unter Konflikte und Rangfolge.

      Außerdem werden alle Migrationseinheiten (z. B. eine Datei, ein Registrierungsschlüssel oder ein Satz von Registrierungswerten), die in einem <UnconditionalExclude>-Abschnitt enthalten sind, nicht migriert.

      Hinweis

      ScanState ignoriert einige Unterabschnitte wie z. B. <destinationCleanup> und <locationModify>. Diese Abschnitte werden nur auf dem Ziel-PC ausgewertet.

  5. In der Sammlungsphase kombiniert ScanState die für die ausgewählten Benutzerprofile erstellten Listen, um eine Masterliste der Migrationseinheiten zu erstellen.

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

    Hinweis

    ScanState ändert den Quell-PC in keiner Weise.

LoadState-Vorgang

Der LoadState-Vorgang ähnelt dem ScanState-Vorgang weitgehend. ScanState sammelt Migrationseinheiten wie Dateien Registrierungsschlüssel oder Registrierungswerte vom Quell-PC und speichert sie im Speicher. LoadState sammelt in ähnlicher Weise Migrationseinheiten aus dem Speicher und wendet sie auf den Ziel-PC an.

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

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

    LoadState ruft Informationen für die App-Einstellungs- und Benutzerdatenkomponenten aus den XML-Migrationsdateien ab, die mit LoadState angegeben wurden.

    In Windows Vista, Windows 7 und Windows 8 steuern die Manifestdateien, wie die Betriebssystemeinstellungen migriert werden. Diese Dateien können nicht geändert werden. Falls Sie bestimmte Betriebssystemeinstellungen ausschließen möchten, müssen Sie eine Datei „Config.xml“ erstellen und ändern.

  3. LoadState ermittelt, welche Benutzerprofile migriert werden sollen. Standardmäßig werden alle Benutzerprofile migriert, die auf dem Quell-PC vorhanden sind. Sie können Benutzer aber mit den Benutzeroptionen ein- und ausschließen. Das Systemprofil „Alle Benutzer“ auf einem Quell-PC unter Windows XP oder das Profil „Öffentlich“ auf einem Quell-PC unter Windows Vista, Windows 7 und Windows 8 wird immer migriert und kann nicht von der Migration ausgeschlossen werden.

    • Wenn Sie lokale Benutzerkonten migrieren und die Konten noch nicht auf dem Ziel-PC vorhanden sind, müssen Sie die Befehlszeilenoption /lac verwenden. Wird die Option /lac nicht angegeben, werden Benutzerkonten, die nicht bereits auf dem Ziel-PC vorhanden sind, nicht migriert.

    • Die Optionen /md und /mu werden verarbeitet, um das Benutzerprofil auf dem Ziel-PC umzubenennen, wenn sie mit LoadState angegeben wurden.

    • LoadState erstellt für jedes ausgewählte Benutzerprofil im Speicher ein entsprechendes Benutzerprofil auf dem Ziel-PC. Der Ziel-PC muss zum Erstellen von Domänenbenutzerprofilen nicht mit der Domäne verbunden sein. Falls USMT eine Domäne nicht ermitteln kann, versucht es, 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 die folgenden Schritte aus:

    1. LoadState überprüft den Typ jeder Komponente. Ist das aktuelle Benutzerprofil das Systemprofil und der Komponententyp „System” oder „UserAndSystem“, wird die Komponente für den Benutzer ausgewählt. Andernfalls wird die Komponente ignoriert. Ist das aktuelle Benutzerprofil nicht das Systemprofil und der Komponententyp ist „User” oder „UserAndSystem“, wird die Komponente für den Benutzer ausgewählt. Andernfalls wird die Komponente ignoriert.

      Hinweis

      Ab diesem Punkt des Prozesses unterscheidet LoadState nicht mehr zwischen den Komponenten, die Betriebssystemeinstellungen migrieren, denen, die App-Einstellungen migrieren, und denen, die Dateien des Benutzers migrieren. Alle Komponenten werden von LoadState auf die gleiche Weise verarbeitet.

    2. Jede ausgewählte Komponente wird weiter verarbeitet. Alle profilspezifischen Variablen (z. B. CSIDL_PERSONAL) werden im Kontext des aktuellen Profils ausgewertet. Wenn das verarbeitete Profil z. B. zu „User1“ gehört, wird CSIDL_PERSONAL zu „C:\Users\User1\Documents“ erweitert (sofern Benutzerprofile im Verzeichnis „C:\Users“ gespeichert werden).

      Hinweis

      LoadState ignoriert den in einer Komponente angegebenen <detects>-Abschnitt. Ab diesem Punkt gelten alle angegebenen Komponenten als erkannt und werden zur Migration ausgewählt.

    3. LoadState wertet für jede ausgewählte Komponente die <rules>-Abschnitte aus. Ist das aktuelle Benutzerprofil das Systemprofil und der Kontext des <rules>-Abschnitts „System“ oder „UserAndSystem“, wird die Regel weiter verarbeitet. Andernfalls wird die Regel ignoriert. Ist das aktuelle Benutzerprofil nicht das Systemprofil und der Kontext des <rules>-Abschnitts ist „User“ oder „UserAndSystem“, wird die Regel weiter verarbeitet. Andernfalls wird die Regel ignoriert.

    4. LoadState verarbeitet die verschiedenen Unterabschnitte im <rules>-Abschnitt, um eine Masterliste der Migrationseinheiten zu erstellen. Jede in einem <include>-Unterabschnitt enthaltene Migrationseinheit wird migriert, sofern keine spezifischere Regel in einem <exclude>-Unterabschnitt desselben <rules>-Abschnitts für die Einheit vorhanden ist. Weitere Informationen zur Rangsfolge finden Sie unter Konflikte und Rangfolge.

    5. LoadState wertet die speziell für den Ziel-PC geltenden Unterabschnitte aus, z. B. <destinationCleanup> und <locationModify>.

    6. Bei einem Ziel-PC unter Windows Vista oder Windows 7 werden die Migrationseinheiten, die von ScanState mit Manifestdateien der Vorgängerversion gesammelt wurden, von LoadState mit dem entsprechenden Komponentenmanifest für Windows 7 verarbeitet. Die Manifestdateien der Vorgängerversion werden während LoadState nicht verwendet.

      Wichtig

      Wenn die XML-Dateien von LoadState verwendet werden sollen, müssen Sie sie mit dem Befehl „LoadState“ angeben. Andernfalls werden alle zielspezifischen Regeln (z. B. <locationModify>) in den XML-Dateien ignoriert – auch dann, wenn sie beim Ausführen des Befehls „ScanState“ angegeben wurden.

  5. In der Anwendungsphase schreibt LoadState die gesammelten Migrationseinheiten an die verschiedenen Speicherorte auf dem Ziel-PC. Falls Konflikte vorliegen und keine <merge>-Regel für das Objekt 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“. Einige Einstellungen (z. B. Schriftarten, Hintergrundbild und Bildschirmschonereinstellungen) werden erst wirksam, wenn sich der Benutzer das nächste Mal anmeldet. Aus diesem Grund sollten Sie sich nach dem Ausführen von LoadState abmelden.

Siehe auch

Weitere Ressourcen

USMT-Befehlszeilensyntax