Tags: Benutzerprofile, Windows ADK
Wenn ein PC einer Domäne beitreten soll und darauf bereits lokale Benutzer vorhanden sind, dann ist es meistens erwünscht, ihre Daten und Einstellungen auf die Domänenkonten zu übernehmen. Windows selbst leistet dabei bekanntlich keine Hilfe, weil es die neuen Domänen-Benutzer völlig getrennt von eventuell vorhandenen gleichnamigen lokalen Usern behandelt. Um die lokalen Profile für die Domänenkonten beizubehalten, empfiehlt sich daher der Einsatz von Migrations-Tools wie Easy Transfer oder das User State Migration Tool (USMT).
Betrachtet man die Fülle der Einträge zu diesem Thema in verschiedenen Foren, dann ist die Migration lokaler Profile in eine Domäne wahrlich kein exotisches Anliegen. Die bei dieser Gelegenheit immer wieder präsentierten Lösungsvorschläge wie diverse Registry-Hacks oder das rohe Kopieren von Profilen über das Dateisystem funktionieren aber in der Regel nicht wie versprochen. Dagegen sind die Microsoft-Tools für die Profilmigration genau dafür vorgesehen.
Easy Transfer für die Migration weniger PCs
Wenn lokale Benutzerprofile auf nicht allzu vielen Rechnern in eine Domäne übernommen werden sollen, dann eignet sich dafür Easy Transfer. Das Tool gehört zum Lieferumfang von Windows 7 und ist vor allem für private Anwender gedacht. Mit seiner grafischen Benutzerführung lässt es sich relativ einfach verwenden. Nils Kaczenski hat auf faq-o-matic eine gute und ausführliche Anleitung verfasst, wie man lokale Profile mit Easy Transfer auf Domänen-User übertragen kann.
Steht eine derartige Migration für eine größere Zahl von PCs an, beispielsweise weil die Profile von einer Domäne auf eine andere migriert werden sollen, dann ist das User State Migration Tool dafür besser geeignet. Dieses ist Bestandteil des Windows AIK und besteht aus mehreren Kommandozeilen-Tools, die explizit Optionen für den Transfer von Profilen zwischen Domänen bzw. zwischen lokalen und Domänen-Konten bieten.
Erfassen von Daten und Einstellungen mit scanstate
Für das Einlesen von Profilen, die migriert werden sollen, ist scanstate.exe zuständig. Standardmäßig erfasst es alle auf einem Rechner vorhandenen Benutzerprofile. Wenn das nicht erwünscht ist, etwa weil die Profile der vorhandenen Domänenkonten ausgeschlossen werden sollen, kann man mit dem Schalter /ui explizit angeben, welche Benutzerprofile berücksichtigt werden sollen. Dieser setzt allerdings voraus, dass vorher mit der Option /ue jene ausdrücklich ausgeschlossen werden, die nicht eingelesen werden sollen. Andernfalls wird der /iu-Schalter ignoriert und alle Profile landen im Migrations-Store.
Die Kombination der beiden Optionen könnte etwa so aussehen: /ue:*\* /ui:%computername%\<user>. Sie schließt alle vorhandenen Profile aus und lässt jenes für <user> explizit zu.
Ein Beispiel für den Aufruf von scanstate.exe könnte zum Erfassen eines lokalen Profils folgendermaßen aussehen:
scanstate c:\store /ue:*\* /ui:%computername%\pmeier /i:MigApp.xml /i:MigUser.xml /i:MigDocs.xml /c /o /nocompress
Dieser Befehl schreibt nur das lokale Profil des Benutzer pmeier in den Migrations-Store unter c:\store, wobei die Schalter /c und /o dafür sorgen, dass scanstate beim Auftreten von Fehlern fortfährt bzw. vorhandene Einträge überschreibt. Die Option /nocompress hat für Tests den angenehmen Nebeneffekt, dass die migrierten Dateien in einer Verzeichnisstruktur analog zum ursprünglichen Speicherort abgelegt werden und das Resultat von scanstate leicht erkennbar ist.
Die mit dem Schalter /i angegebenen Konfigurationsdateien sind Teil des USMT und bieten die Möglichkeit, die Migration anzupassen. Wenn beispielsweise besonders große Dateien wie virtuelle Laufwerke (VHD, vmdk) nicht übernommen werden sollen, dann kann man das über einen Eintrag in der Datei MigDocs.xml erreichen. Ein Muster für die gültige Syntax findet sich in diesem Technet-Artikel.
Diese Möglichkeit, Dateien auszuschließen, ist auch dort praktisch, wo scanstate Informationen einsammelt, die man aufgrund des Aufrufs nicht erwartet hätte. So übernimmt das Tool neben den spezifizierten Profilen immer auch eines unter der Bezeichnung "This Computer", das mehrere Verzeichnisse direkt unterhalb des Wurzelverzeichnisses enthält (z.B. ProgramData, Drivers, PerfLogs, etc.). Außerdem fügt es dort die Profile von Public und des Administrators hinzu. Um dieses Verhalten zu unterbinden, kann man in die Datei MigDocs.xml einen Abschnitt nach diesem Muster einfügen:
<unconditionalExclude>
<objectSet>
<pattern type="File">C:\Program Files\* [*]</pattern>
<pattern type="File">C:\Program Files (x86)\* [*]</pattern>
<pattern type="File">C:\Windows\* [*]</pattern>
<pattern type="File">C:\PerfLogs\* [*]</pattern>
<pattern type="File">C:\Drivers\* [*]</pattern>
<pattern type="File">C:\ProgramData\* [*]</pattern>
<pattern type="File">C:\PROFILES\* [*]</pattern>
<pattern type="File">C:\Users\Public\* [*]</pattern>
<pattern type="File">C:\Users\Administrator\* [*]</pattern>
</objectSet>
</unconditionalExclude>
Die korrekte Position dieses Fragments ist unter <rules> innerhalb des Elements <component type="Documents" context="System">.
Profile übertragen mit loadstate
Der Gegenspieler zu scanstate.exe heißt loadstate.exe, er liest die Daten aus dem Migrations-Store und kopiert sie in die passenden Benutzerprofile. Voraussetzung für die Migration von Profilen zwischen lokalen und Domänenkonten ist jedoch, dass die Profile für die Domänenkennungen existieren. Das ist typischerweise dann der Fall, wenn sich der betreffende User schon einmal an diesem Rechner unter diesem Konto angemeldet hat. Außerdem ist es erforderlich, dass eine Verbindung zu einem Domänen-Controller existiert, das Schreiben in die Profile von Domänen-Benutzern funktioniert offline nicht.
Der Aufruf von loadstate orientiert sich an jenem von scanstate. Wenn man etwa beim Scannen der Profile den Schalter /nocompress angegeben hat, dann muss man dies bei loadstate erneut tun, andernfalls findet das Programm die Dateien nicht. Der Ein- oder Ausschluss von bestimmten Profilen mit den Schaltern /ui bzw. /ue muss andererseits nicht dem Muster von scanstate folgen. Hat man ohnehin nur die Profile eingelesen, die man migrieren will, erübrigen sich hier weitere Angaben. Wurden von scanstate jedoch alle Profile erfasst, dann kann man mit den beiden Schaltern die unerwünschten Konten ausfiltern.
Ein Aufruf von laodstate, der die von scanstate eingesammelten Daten in die Profile von Domänenkonten zurückschreibt, könnte mithin so aussehen:
loadstate.exe c:\store /md:%computername%:windowspro /i:MigApp.xml /i:MigUser.xml /i:MigDocs.xml /c /nocompress
Der Befehl enthält zusätzlich den Schalter /md, den es bei scanstate nicht gibt. Er ist dafür zuständig, Profile von lokalen Konten jenen von Domänen-Accounts zuzuordnen. An der ersten Position steht die Ursprungsdomäne bzw. der Name des lokalen Rechners, an der zweiten die Zieldomäne.
Wenn loadstate sein Werk verrichtet hat, sollte man den Desktop und die Benutzerdaten unter der Domänenkennung vorfinden wie zuvor beim lokalen Konto, von dem sie übernommen wurden. Dagegen darf man bei den Einstellungen für Anwendungen keine Wunder erwarten. Das USMT unterstützt per Voreinstellung nur wenige Programme, so dass man die meisten von Hand nachkonfigurieren muss.
Täglich Know-how für IT-Pros mit unserem Newsletter
Verwandte Beiträge
- M.U.S.T.: kostenlose GUI für das User State Migration Tool (USMT)
- User State Migration Tool 4 unterstützt Office 2010
- Standard-Benutzerprofil unter Windows 7 konfigurieren
- Benutzerprofile umziehen mit dem User State Migration Tool (USMT) 4.0
- Microsoft Edge for Business trennt private und geschäftliche Profile
Weitere Links
1 Kommentar
Mit welchen tool kann ich unter Windows 10 Microsoft Konten zu Domäne konnten machen. Es nervt dass er immer nach den Samba Passwort fragt wen ich eine Dateifreigabe öffnen will.