Allgemeine Probleme
In den folgenden Abschnitten werden allgemeine Probleme behandelt, die beim Ausführen des Migrationstools für den Benutzerstatus(USMT) 10.0 auftreten können. Von USMT werden Protokolldateien erstellt, in denen während des Migrationsvorgangs aufgetretene Fehler ausführlicher beschrieben werden. Diese Protokolle können zum Behandeln von Migrationsfehlern verwendet werden.
Inhalt dieses Themas
Probleme mit Benutzerkonten
Probleme mit der Befehlszeile
Probleme mit XML-Dateien
Probleme mit der Migration
Probleme mit der Offlinemigration
Probleme mit der Migration mit festem Link
Allgemeine Richtlinien für das Identifizieren von Migrationsproblemen
Wenn während der Migration ein Problem auftritt oder eine Fehlermeldung angezeigt wird, können Sie die Ursache des Problems anhand der folgenden allgemeinen Richtlinien ermitteln:
Analysieren Sie die ScanState-, LoadState- und UsmtUtils-Protokolle, um Aufschluss über die genauen USMT-Fehlermeldungen und Windows® Application programming Interface (API)-Fehlermeldungen zu erlangen. Weitere Informationen zu USMT-Rückgabecodes und -Fehlermeldungen finden Sie unter Rückgabecodes. Geben Sie für weitere Informationen zu Windows-API-Fehlermeldungen in der Befehlszeile nethelpmsg ein.
In den meisten Fällen geben die ScanState- und LoadState-Protokolle Aufschluss darüber, weshalb bei einer USMT-Migration ein Fehler aufgetreten ist. Wir empfehlen für das Testen der Migration die Verwendung der Option /v*:5*. Dieser Ausführlichkeitsgrad kann bei einer Produktionsmigration angepasst werden. Bei einem niedrigeren Ausführlichkeitsgrad kann es allerdings schwieriger sein, Fehler während Produktionsmigrationen zu diagnostizieren. Sie können einen höheren Ausführlichkeitsgrad als 5 verwenden, wenn Sie die Protokolldateien an einen Debugger ausgeben möchten.
Hinweis
Durch das Ausführen der ScanState- und LoadState-Tools mit der Option /v*:5* wird eine detaillierte Protokolldatei erstellt. Diese Option führt zwar zu einer größeren Protokolldatei, die zusätzlichen Details können aber beim Feststellen der Ursache von Migrationsfehlern hilfreich sein.
Verwenden Sie in UsmtUtils die Option /Verify, um zu bestimmen, ob alle Dateien in einem komprimierten Migrationsspeicher beschädigt sind. Weitere Informationen finden Sie unter Überprüfen des Zustands eines komprimierten Migrationsspeichers.
Verwenden Sie in UsmtUtils die Option /Extract, um Dateien aus einem komprimierten Migrationsspeicher zu extrahieren. Weitere Informationen finden Sie unter Extrahieren von Dateien aus einem komprimierten USMT-Migrationsspeicher.
Erstellen Sie mit der Option /Progress ein Statusprotokoll, um die Migration zu überwachen.
Rufen Sie für die Quell- und Zielcomputer Informationen zum Betriebssystem und Versionen von Apps wie Internet Explorer und anderen relevanten Programmen ab. Bestimmen Sie anschließend die genauen Schritte zum Reproduzieren des Problems. Diese Informationen können Aufschluss über die Fehlerursache geben und das Reproduzieren des Problems in der Testumgebung erleichtern.
Melden Sie sich ab, nachdem Sie LoadState ausgeführt haben. Einige Einstellungen (z. B. Schriftarten, Desktophintergrund und Bildschirmschonereinstellungen) werden erst wirksam, wenn sich der Endbenutzer das nächste Mal anmeldet.
Schließen Sie alle Apps, bevor Sie ScanState oder LoadState ausführen. Wenn einige Anwendungen während des ScanState- oder LoadState-Prozesses ausgeführt werden, werden einige Daten möglicherweise nicht vom USMT migriert. Wenn beispielsweise Microsoft Outlook® geöffnet ist, werden die PST-Dateien vom USMT möglicherweise nicht migriert.
Hinweis
Das USMT gibt einen Fehler aus, wenn die Option /c nicht verwendet wurde und eine Datei oder Einstellung nicht migriert werden kann. Bei Angabe der Option /c wird der Fehler vom USMT ignoriert. Es wird aber ein Fehler im Protokoll erfasst, wenn eine verwendete Datei nicht migriert werden kann.
Probleme mit Benutzerkonten
In den folgenden Abschnitten werden häufige Probleme mit Benutzerkonten beschrieben. Erweitern Sie den Abschnitt, um die empfohlenen Lösungen anzuzeigen.
Ich habe Probleme beim Erstellen lokaler Konten auf dem Ziel-PC.
Lösung: Weitere Informationen zum Erstellen von Konten und Migrieren lokaler Konten finden Sie unter Migrieren von Benutzerkonten.
Es werden nicht alle Benutzerkonten zum Zielcomputer migriert.
Ursachen/Lösungen Es gibt zwei mögliche Ursachen für dieses Problem:
ScanState unter Windows Vista oder ScanState- und LoadState unter Windows 7, Windows 8 oder Windows 10 müssen im Administratormodus von einem Konto mit Administratoranmeldeinformationen aus ausgeführt werden, um sicherzustellen, dass alle angegebenen Benutzer migriert werden. Gehen Sie wie folgt vor, um die Tools im Verwaltungsmodus auszuführen:
Klicken Sie auf Start.
Klicken Sie auf Alle Programme.
Klicken Sie auf Zubehör.
Klicken Sie mit der rechten Maustaste auf die Eingabeaufforderung.
Klicken Sie auf Als Administrator ausführen.
Geben Sie anschließend den LoadState- oder ScanState-Befehl an. Wenn Sie das USMT nicht im Administratormodus ausführen, wird nur das Profil des angemeldeten Benutzers in die Migration eingeschlossen.
Alle Benutzerkonten auf dem PC, die nicht verwendet wurden, werden nicht migriert. Wenn Sie beispielsweise User1 zum Computer hinzufügen, User1 sich aber nie anmeldet, wird das Benutzerkonto für User1 nicht vom USMT migriert.
Benutzerkonten, die ich ausgeschlossen habe, wurden zum Zielcomputer migriert.
Ursache: Der angegebene Befehl enthielt möglicherweise widersprüchliche Optionen vom Typ /ui und /ue. Wenn ein Benutzer mit der Option /ui angegeben und zugleich anhand der Optionen vom Typ /ue oder /uel ausgeschlossen wird, wird er in die Migration einbezogen. Wenn Sie beispielsweise /ui:domain1\* /ue:domain1\user1 angeben, wird User1 migriert, da die Option /ui vorrangig behandelt wird.
Lösung: Weitere Informationen zur gemeinsamen Verwendung der Optionen vom Typ /ui und /ue finden Sie in den Beispielen zum Thema ScanState-Syntax.
Ich verwende die Option „/uel“, aber trotzdem werden noch viele Konten in die Migration eingeschlossen.
Ursache Die Option /uel ist vom Datum der letzten Änderung der Datei „NTUser.dat“ des Benutzers abhängig. In manchen Fällen entspricht dieses letzte Änderungsdatum nicht dem letzten Anmeldedatum des Benutzers.
Auflösung Hierbei handelt es sich um eine Beschränkung der Option /uel. Möglicherweise müssen Sie die Benutzer manuell mit der Option /ue ausschließen.
LoadState meldet während eines Migrationstests einen Fehler mit dem Rückgabecode 71 und kann ein Benutzerprofil nicht wiederherstellen.
Ursache: Wenn Sie während des Migrationstests ScanState auf dem Testcomputer ausführen und anschließend Benutzerprofile löschen, um LoadState auf demselben Computer zu testen, ist möglicherweise ein widersprüchlicher Schlüssel in der Registrierung vorhanden. Mit dem Befehl net use zum Entfernen eines Benutzerprofils werden alle dem Profil zugeordneten Ordner und Dateien gelöscht. Der Registrierungsschlüssel jedoch wird nicht entfernt.
Lösung: Verwenden Sie zum Löschen eines Benutzerprofils das Element Benutzerkonten in der Systemsteuerung. Gehen Sie wie folgt vor, um eine unvollständige Löschung eines Benutzerprofils zu korrigieren:
Öffnen Sie den Registrierungs-Editor, indem Sie in einer Eingabeaufforderung mit erhöhten Rechten
regediteingeben.Navigieren Sie zu
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList.Jedes Benutzerprofil ist in einem Systembezeichnerschlüssel unter
ProfileListgespeichert.Löschen Sie den Schlüssel für das Benutzerprofil, das Sie entfernen möchten.
Dateien, die vor der Migration nicht verschlüsselt waren, sind jetzt mit dem zum Ausführen von LoadState verwendeten Konto verschlüsselt.
Ursache: ScanState wurde mit der Option /EFS: copyraw ausgeführt, um verschlüsselte Dateien und Zertifikate für das verschlüsselte Dateisystem (EFS) zu migrieren. Das Verschlüsselungsattribut wurde für einen Ordner festgelegt, der migriert wurde, das Attribut wurde aber vor der Migration aus den Dateiinhalten dieses Ordners entfernt.
Lösung: Bevor Sie ScanState für die Migration verschlüsselter Dateien und EFS-Zertifikate verwenden, können Sie Cipher per Eingabeaufforderung ausführen, um Verschlüsselungseinstellungen für Dateien und Ordner zu überprüfen und zu ändern. Sie müssen das Verschlüsselungsattribut von Ordnern entfernen, die unverschlüsselte Dateien enthalten, oder den Inhalt aller Dateien in einem verschlüsselten Ordner verschlüsseln.
Um die Verschlüsselung von bereits falsch migrierten Dateien aufzuheben, müssen Sie sich am PC mit dem Konto anmelden, das zum Ausführen von LoadState verwendet wurde, und anschließend die Verschlüsselung der betroffenen Dateien entfernen.
LoadState meldet einen Fehler mit dem Rückgabecode 71 und einen Windows-Fehler 2202 in der Protokolldatei.
Ursache: Der Name des Computers wurde während einer Offlinemigration eines lokalen Benutzerprofils geändert.
Lösung: Sie können die Option /mu beim Ausführen von LoadState verwenden, um einen neuen Namen für den Benutzer anzugeben. Beispiel:
loadstate /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore
/progress:prog.log /l:load.log /mu:fareast\user1:farwest\user1
Probleme mit der Befehlszeile
In den folgenden Abschnitten werden häufige Befehlszeilenprobleme beschrieben. Erweitern Sie den Abschnitt, um die empfohlenen Lösungen anzuzeigen.
Die folgende Fehlermeldung wurde angezeigt: „Usage Error: You cannot specify a file path with any of the command-line options that exceeds 256 characters.“
Ursache: Diese Fehlermeldung kann in einigen Fällen auch dann ausgegeben werden, wenn Sie keinen langen Speicher- oder Dateipfad angeben, weil die Pfadlänge basierend auf dem absoluten Pfad berechnet wird. Wenn Sie z. B. unter c:\Programme Files\USMT40 den Befehl scanstate.exe/o store ausführen, wird zur Berechnung der Gesamtlänge jedes Zeichen in „C:\Program Files\USMT40“ der Länge des Speicherpfads hinzugefügt.
Lösung: Stellen Sie sicher, dass die gesamte Pfadlänge – Speicherpfad plus aktuelles Verzeichnis – 256 Zeichen nicht überschreitet.
Die folgende Fehlermeldung wurde angezeigt: „USMT was unable to create the log file(s). Ensure that you have write access to the log directory.“
Ursache: Wenn Sie ScanState oder LoadState von einer freigegebenen Netzwerkressource aus ausführen und /l nicht angeben, erhalten Sie diese Fehlermeldung.
Lösung: Geben Sie zum Beheben dieses Problems in diesem Szenario die Option /l:scan.log oder /l:load.log an.
Probleme mit XML-Dateien
In den folgenden Abschnitten werden häufige Probleme mit XML-Dateien beschrieben. Erweitern Sie den Abschnitt, um die empfohlenen Lösungen anzuzeigen.
Ich habe mit der Option „/genconfig“ eine Config.xml-Datei erstellt, sehe aber nur wenige der in „MigApp.xml“ enthaltenen Anwendungen und Komponenten. Weshalb enthält „Config.xml“ nicht alle gleichen Anwendungen?
Ursache: „Config.xml“ enthält nur Betriebssystemkomponenten, Anwendungen und die Benutzerdokumentabschnitte, die in beiden XML-Dateien enthalten und auf dem Computer installiert sind, wenn Sie die Option /genconfig ausführen. Andernfalls werden die Anwendungen und Komponenten nicht in der Config.xml-Datei angezeigt.
Lösung: Installieren Sie vor dem Ausführen der Option /genconfig alle gewünschten Anwendungen auf dem Computer. Führen Sie anschließend ScanState mit allen XML-Dateien aus. Führen Sie z. B. folgenden Befehl aus:
scanstate /genconfig:config.xml /i:migdocs.xml /i:migapp.xml /v:5 /l:scanstate.log
Ich habe Probleme mit einer benutzerdefinierten XML-Datei, die ich erstellt habe, und kann nicht überprüfen, ob die Syntax korrekt ist.
Lösung: Sie können das im USMT enthaltene XML-Schema (MigXML.xsd) in das XML-Erstellungstool laden. Beispiele finden Sie im Visual Studio Development Center. Laden Sie anschließend Ihre XML-Datei im Erstellungstool, um zu überprüfen, ob ein Syntaxfehler vorliegt. Darüber hinaus finden Sie weitere Informationen zur Verwendung der XML-Elemente in der USMT-XML-Referenz.
Ich verwende eine MigXML-Hilfsfunktion, die Migration funktioniert aber nicht wie erwartet. Wie kann ich dieses Problem beheben?
Ursache: In der Regel wird dieses Problem durch eine falsche Syntax in einer Hilfsfunktion verursacht. Sie erhalten einen Rückgabecode „Erfolgreich“, die Dateien, die Sie migrieren wollten, wurden aber nicht oder nicht wie erwartet gesammelt oder angewendet.
Lösung: Suchen Sie im ScanState- oder LoadState-Protokoll entweder nach dem Komponentennamen, der die MigXML-Hilfsfunktion enthält, oder dem Titel der MigXML-Hilfsfunktion, damit Sie die entsprechende Warnung in der Protokolldatei ausfindig machen können.
Probleme mit der Migration
In den folgenden Abschnitten werden häufige Migrationsprobleme beschrieben. Erweitern Sie den Abschnitt, um die empfohlenen Lösungen anzuzeigen.
Dateien, die ich zum Ausschließen angegeben habe, werden trotzdem migriert.
Ursache: Möglicherweise besteht eine weitere Regel, die die Dateien einbezieht. Falls eine spezifischere oder widersprüchliche Regel vorhanden ist, werden die Dateien in die Migration einbezogen.
Lösung: Weitere Informationen finden Sie unter Konflikte und Rangfolge und im Abschnitt „Diagnoseprotokoll“ in den Protokolldateien.
Ich habe Regeln angegeben, um einen Ordner an einen bestimmten Speicherort auf dem Zielcomputer zu verschieben, er wurde aber nicht korrekt migriert.
Ursache: Möglicherweise liegt ein Fehler in der XML-Syntax vor.
Lösung: Sie können das USMT-XML-Schema (MigXML.xsd) zum Schreiben und Überprüfen von XML-Dateien für die Migration verwenden. In den folgenden Themen finden Sie außerdem hilfreiche XML-Beispiele:
Ausschließen von Dateien und Einstellungen
Umleiten von Dateien und Einstellungen
Einbeziehen von Dateien und Einstellungen
Beispiele für benutzerdefinierte XML-Dateien
Nach der Ausführung von LoadState wird der neue Desktophintergrund nicht auf dem Ziel-PC angezeigt.
Für dieses Problem kommen in der Regel drei Ursachen in Frage.
Ursache Nr. 1:: Einige Einstellungen, z. B. Schriftarten, Desktophintergründe oder Bildschirmschonereinstellungen, werden von LoadState erst angewendet, nachdem der Zielcomputer neugestartet wurde.
Lösung: Um dieses Problem zu beheben, melden Sie sich ab und anschließend erneut an, um den migrierten Desktophintergrund anzuzeigen.
Ursache Nr. 2: Wenn auf dem Quellcomputer Windows® XP ausgeführt wurde und der Desktophintergrund im Ordner „Drive:\WINDOWS\Web\Wallpaper“ – dem Standardspeicherort für Desktophintergründe in Windows XP – gespeichert wurde, wird der Desktophintergrund nicht migriert. Stattdessen wird auf dem Zielcomputer der standardmäßige Windows®-Desktophintergrund verwendet. Dies ist auch dann der Fall, wenn der Desktophintergrund ein benutzerdefiniertes Bild war, das dem Ordner „\WINDOWS\Web\Wallpaper“ hinzugefügt wurde. Legt der Endbenutzer aber ein Bild von einem anderen Speicherort (z. B. „Eigene Bilder“) als Desktophintergrund fest, wird der Desktophintergrund migriert.
Lösung: Stellen Sie sicher, dass die zu migrierenden Desktophintergrundbilder sich nicht im Ordner „\WINDOWS\Web\Wallpaper“ auf dem Quellcomputer befinden.
Ursache Nr. 3: Wenn ScanState nicht unter Windows XP in einem Konto mit Administratoranmeldeinformationen ausgeführt wurde, werden einige Betriebssystemeinstellungen nicht migriert. Hintergrundbildeinstellungen, Bildschirmschonerauswahl, Modemoptionen, Media Player-Einstellungen sowie Dateien (PBK) und Einstellungen für das RAS-Verbindungstelefonbuch werden nicht migriert.
Lösung: Führen Sie ScanState und LoadState in einem Konto mit Administratoranmeldeinformationen aus.
Ich habe „MigApp.xml“ in die Migration einbezogen, einige PST-Dateien werden aber nicht migriert.
Ursache: Mit der Datei „MigApp.xml“ werden nur die PST-Dateien migriert, die mit Outlook-Profilen verknüpft sind.
Lösung: Um PST-Dateien zu migrieren, die nicht mit Outlook-Profilen verknüpft sind, müssen Sie eine separate Migrationsregel zum Erfassen dieser Dateien erstellen.
Probleme mit der Offlinemigration
In den folgenden Abschnitten werden häufige Probleme bei Offlinemigrationen beschrieben. Erweitern Sie den Abschnitt, um die empfohlenen Lösungen anzuzeigen.
Einige meiner Systemeinstellungen werden bei einer Offlinemigration nicht migriert.
Ursache: Einige Systemeinstellungen, z. B. Desktophintergründe und Netzwerkdrucker, werden bei Offlinemigrationen nicht unterstützt. Weitere Informationen dazu finden Sie unter Was wird von USMT migriert?
Lösung: Bei einer Offlinemigration müssen diese Systemeinstellungen manuell wiederhergestellt werden.
ScanState gibt einen Fehler und Rückgabecode 26 aus.
Ursache: Eine häufige Ursache für Rückgabecode 26 ist ein aktiviertes temporäres Profil auf dem Quellcomputer. Dieses Profil ist „c:\users\temp“ zugeordnet. Im ScanState-Protokoll wird eine Ausnahme vom Typ „MigStartupOfflineCaught“ mit der Meldung „User profile duplicate SID error“ angezeigt.
Lösung: Sie können einen Neustart des Computers durchführen, um das temporäre Profil zu entfernen, oder Sie können „MIG_FAIL_ON_PROFILE_ERROR=0“ festlegen, um den Fehler zu überspringen und das temporäre Profil auszuschließen.
Include- und Exclude-Regeln zum Migrieren von Benutzerprofilen funktionieren offline anders als online.
Ursache: Im Offlinezustand kann der DNS-Server nicht abgefragt werden, um Benutzername und SID-Zuordnung aufzulösen.
Lösung: Verwenden Sie eine Sicherheits-ID (SID), um einen Benutzer beim Ausführen von ScanState einzubeziehen. Beispiel:
Scanstate /ui:S1-5-21-124525095-708259637-1543119021*
Durch den Platzhalter (*) am Ende der SID wird ebenfalls der SID_Classes-Schlüssel migriert.
Sie können auch Muster für SIDs verwenden, die generische Benutzer oder Gruppen angeben. Sie können z. B. die Option /ue:*-500 verwenden, um die lokalen Administratorkonten auszuschließen. Weitere Informationen zu Windows-SIDs finden Sie auf dieser Microsoft-Website.
Bei meinem Skript zum Bereinigen des Datenträgers tritt nach dem Ausführen von ScanState auf einem 64-Bit-System ein Fehler auf.
Ursache: Die HKLM-Registrierungsstruktur wird nicht entladen, nachdem die Ausführung von ScanState beendet wurde.
Lösung: Starten Sie nach der Ausführung von ScanState den Computer neu, oder entladen Sie die Registrierungsstruktur in der Eingabeaufforderung. Geben Sie in der Eingabeaufforderung z. B. Folgendes ein:
reg.exe unload hklm\$dest$software
Probleme mit der Migration mit festem Link
In den folgenden Abschnitten werden häufige Probleme bei Migrationen mit festem Link beschrieben. Erweitern Sie den Abschnitt, um die empfohlenen Lösungen anzuzeigen.
EFS-Dateien werden nicht auf der neuen Partition wiederhergestellt.
Ursache: EFS-Dateien können nicht mit festem Link in eine neue Partition verschoben werden. Die Befehlszeilenoption /efs:hardlink gilt nur für zur gleichen Partition migrierte Dateien.
Lösung: Verwenden Sie anstatt der Erstellung fester Links die Befehlszeilenoption /efs:copyraw zum Kopieren von EFS-Dateien während der Migration, oder kopieren Sie die EFS-Dateien manuell aus dem Speicher mit festem Link.
ScanState kann einen vorherigen Migrationsspeicher mit festem Link nicht löschen.
Ursache: Der Migrationsspeicher enthält feste Links zu gesperrten Dateien.
Lösung: Löschen Sie mithilfe von UsmtUtils den Speicher, oder ändern Sie den Namen des Speichers. Geben Sie in der Eingabeaufforderung z. B. Folgendes ein:
USMTutils /rd <storedir>
Sie sollten den PC außerdem neu starten.