Windows: ADMT, PES und servergespeicherte Profile

Es kann verschiedene Gründe dafür geben, Benutzer und Computer von einer Domäne in eine Andere zu übernehmen, z.B. wenn mehrere Domänen zu einer Domäne zusammengefasst werden sollen. Microsoft bietet für die Migration von Benutzern und Computer das Active Directory Migration Tool und den Password Export Server an. Beide Tools zusammen ermöglichen es, Benutzerkonten mit den dazugehörigen Kennwörtern von einer Domäne in eine andere Domäne zu migrieren. Werden servergespeicherte Benutzer-Profile verwendet, können Diese ebenfalls übernommen werden.

Voraussetzungen

ADMT 3.0 kann nur unter Windows Server 2003 (inkl. SBS) installiert werden.

ADMT 3.1 und 3.2 2 kann nur unter Windows Server 2008 (R2) (inkl. SBS) installiert werden.

Die Domänenfunktionsebene muss mindestens Windows Server 2003 betragen.

Vorbereitungen

Normalerweise würde man eine Vertrauensstellung zwischen der Quell- und der Ziel-Domäne einrichten. Dies kann aber unter Umständen, z.B. beim Einsatz des Small Business Servers, nicht möglich sein. Stattdessen greift man auf den Befehl „runas“ („Ausführen als“) zurück. Dazu später mehr.

Ist es allerdings möglich eine Vertrauensstellung einzurichten, dann sieht das Vorgehen wie folgt aus. Dieses Beispiel beruht auf Windows Server 2008 R2 mit jeweils einer Domäne in jeweils eigener Gesamtstruktur.

  • Auf einem Domänencontroller der Quell- oder der Ziel-Domäne „Active Directory-Domänen und -Vertrauensstellungen“ öffnen.
  • Die Domäne mit der rechten Maustaste anklicken und „Eigenschaften“ auswählen.
  • Auf die Registerkarte „Vertrauensstellungen“ wechseln.
  • Auf „Neue Vertrauensstellung…“ klicken.
  • Den NetBIOS oder DNS-Namen der Quell-Domäne eingeben.
  • „Gesamtstrukturvertrauensstellung“ auswählen.
  • „Bidirektional“ auswählen.
  • „Für diese Domäne und die angegebene Domäne“ auswählen.
  • Die Anmeldedaten für die Quell- bzw. Ziel-Domäne, je nachdem in welcher Domäne man gerade ist, eingeben.
  • „Gesamtstrukturweite Authentifizierung“ zweimal (einmal für die Quell- und einmal für die Ziel-Domäne) auswählen.
  • Abschließend müssen die ausgehenden Vertrauensstellungen für die Quell- als auch für die Ziel-Domäne noch bestätigt werden.

Troubleshooting

Funktioniert das Erstellen der Vertrauensstellung nicht, so liegt das meist am DNS. Beide Domänen sollten per DNS auflösbar sein. Für die Dauer der Migration kann man z.B. einen Domänencontroller der jeweils anderen Domäne in die Weiterleitungs-Konfiguration des DNS-Servers eintragen.

Bei einem Windows Server 2003-Domänencontroller genügt es, die IP-Adresse des Windows Server 2008 R2-Domänencontrollers bei der DNS-Weiterleitung einzutragen.

Auf einem Windows Server 2008 R2-Domänencontroller zum einen die IP-Adresse eines Windows Server 2003-Domänencontrollers in die Weiterleitungs-Konfiguration des DNS-Servers eintragen und zusätzlich eine „Bedingte Weiterleitung“ einrichten. Andernfalls kann die Domäne nicht aufgelöst werden.

Active Directory Migration Tool

Möchte man ADMT 3.1 oder 3.2 verwenden, so wird zunächst ein SQL Server benötigt.

Zunächst den SQL Server 2005 Express Edition SP3 oder SQL Server 2008 Express Edition SP1 herunterladen und installieren.

Microsoft SQL Server 2008 Express Edition SP1 (Empfohlen)

Microsoft SQL Server 2005 Express Edition SP3

Das ADMT und der SQL Server sollten nicht auf einem Domänencontroller installiert werden. Prinzipiell ist es zwar möglich, erfordert aber mehr Aufwand, da es z.B. Probleme gibt mit MS SQL Server 2008 Express Edition SP1 auf einem Domänencontroller.

Siehe dazu: ADMT 3.2: Common Installation Issues

MS SQL Server 2008 Express Edition SP1 Instanz installieren

  • Das Setup ausführen.
  • Auf „Installation“ klicken.
  • „Neue eigenständige SQL Server-Installation oder Hinzufügen von Features zu einer vorhandenen Installation“ anklicken.
  • Da es sich um die Express Edition handelt, kann kein Product Key eingegeben werden.
  • Dem Lizenzvertrag zustimmen.
  • Unter „Features“ muss „Datenbankmoduldienste“ ausgewählt sein.
  • Als Dienstkonto kann „NT-Autorität\System“ angegeben werden.
  • Es muss mindestens ein SQL-Administrator festgelegt werden, an dieser Stelle auf „Aktuellen Benutzer hinzufügen“ klicken.
  • Alle anderen Einstellungen können auf den Vorgaben belassen werden.

ADMT herunterladen und installieren

ADMT 3.2 für Windows Server 2008 R2

ADMT 3.1 für Windows Server 2008

ADMT 3.0 für Windows Server 2003

  • Das Setup ausführen.
  • Dem Lizenzvertrag zustimmen.
  • ADMT 3.0 bringt einen SQL-Server mit. Bei ADMT 3.1 und 3.2 die zuvor installierte Datenbank-Instanz („.\SQLEXPRESS“ oder „SERVERNAME\SQLEXPRESS“) angeben.

Das ADMT befindet sich im Startmenü unter Verwaltung.

Als Vorbereitung auf die Verwendung des Password Export Servers folgenden Befehl ausführen:

admt key /option:create /sourcedomain:QUELLDOMÄNE /keyfile:DATEINAME /keypassword:KENNWORT

Die Angabe eines Kennworts („/keypassword:“) ist optional. Die Schlüssel-Datei muss auf den Domänencontroller der Quell-Domäne kopiert werden, auf dem der Passwort Export Server installiert werden soll.

Password Export Server herunterladen und installieren

Der PES ist nur in Verbindung mit ADMT 3.1 und 3.2 verwendbar! Bei ADMT 3.0 müssen neue Kennwörter vergeben werden.

Den PES herunterladen und auf einem Domänencontroller der Quell-Domäne installieren.

PES 3.1 x64 für Windows 2003, Windows Server 2008

PES 3.1 x86 für Windows 2000 Server, Windows Server 2003, Windows Server 2008

  • Das Setup ausführen.
  • Dem Lizenzvertrag zustimmen.
  • Den Pfad zur Schlüssel-Datei angeben.
  • Bei der Abfrage, unter welchem Konto der Dienst ausgeführt werden soll, kann entweder das lokale Systemkonto oder ein Benutzerkonto der Ziel-Domäne angegeben werden. Möchte man das lokale Systemkonto verwenden, so muss die Benutzergruppe „Prä-Windows 2000 kompatibler Zugriff“ die Gruppen „Jeder“ und „ANONYMOUS-ANMELDUNG“ in der Ziel-Domäne enthalten. Besteht keine Vertrauensstellung zwischen den Domänen, so kann man das Administrator-Konto der Quell-Domäne zum Ausführen des PES verwenden. Im Test funktionierte der Weg über das lokale Systemkonto in keiner Konstellation.
  • Anschließend das System neu starten.
  • Nach dem Neustart den Dienst „Password Export Server Service“ starten. Dieser steht nach der Installation auf dem Starttyp „Manuell“.

Benutzer, Computer und Profile migrieren

Besteht eine Vertrauensstellung zwischen den Domänen, so kann das ADMT direkt ausgeführt werden. Vertrauen sich die Domänen allerdings nicht, so muss ADMT mit folgenden Befehl auf einem Domänencontroller in der Quelldomäne aufgerufen werden:

runas /netonly /user:ZIELDOMÄNE\Administrator "mmc C:\Windows\ADMT\migrator.msc"

Dieser Befehl kann allerdings nur bis einschließlich ADMT 3.0 erfolgreich verwendet werden. ADMT ab Version 3.1 setzt eine Vertrauensstellung voraus.

Bevor die eigentliche Migration starten kann, müssen noch ein paar Vorbereitungen im Active Directory getroffen werden:

Auf einem Domänencontroller der Quell-Domäne, die Benutzergruppe „Domänen-Admins“ der Ziel-Domäne der Benutzergruppe „Administratoren“ hinzufügen. Andernfalls können keine Kennwörter migriert werden. Dies geht natürlich nur, wenn eine Vertrauensstellung zwischen den Domänen besteht.

In der Quell-Domäne muss eine domänenlokale Gruppe mit Namen „NETBIOSDOMÄNENNAME$$$“, z.B. „test$$$“, angelegt werden. Diese Gruppe wird für die Migration des SID-Verlaufs benötigt, was wiederum wichtig ist für die Migration der servergespeicherten Benutzerprofile.

Benutzer mit Gruppen und Profilen migrieren

Damit eine Migration der servergespeicherten Benutzerprofile erfolgen kann, müssen die Berechtigungen unter Umständen geändert werden. Per Standard und sofern die Gruppenrichtlinien-Einstellung „Sicherheitsgruppe Administratoren zu servergespeicherten Profile hinzufügen“ nicht aktiviert ist, besitzen nur das lokale System und der Benutzer Vollzugriff auf das Profil. Folglich müssen der Administratoren-Gruppe volle NTFS-Rechte auf den bzw. die Profile erteilt werden, damit ADMT eine erfolgreiche Migration der Benutzerprofile durchführen kann. Während der Migration dürfen die Benutzer nicht an der Domäne angemeldet sein.

  • ADMT ausführen.
  • Auf „Aktion – Assistent zum Migrieren von Benutzerkonten“ klicken.
  • Quell- und Ziel-Domäne samt Domänencontroller angeben.
  • Die Voreinstellung „Benutzer aus Domäne auswählen“ belassen.
  • Die Benutzer auswählen.
  • Die Ziel-OU angeben.
  • „Kennwörter migrieren“ auswählen. An dieser Stelle kommt der PES ins Spiel.
  • „Benutzer-SIDs zur Zieldomäne migrieren“ auswählen.
  • Im weiteren Verlauf können verschiedene Einstellungen vorgenommen werden. Sinnvoll ist z.B. das deaktivieren von Konten in der Quell-Domäne („Quellkonten deaktivieren“), sobald die Migration erfolgreich abgeschlossen wurde.
  • Im Dialog „Benutzeroptionen“ kann angegeben werden, ob servergespeicherte Profile und Benutzergruppen, in denen die ausgewählten Benutzer Mitglied sind, ebenfalls migriert werden sollen.
  • Wurden die servergespeicherten Profile ebenfalls migriert, so müssen Diese auf einen Server in der Ziel-Domäne kopiert werden und der Pfad in den Benutzerkonten muss aktualisiert werden.

Achtung: Die NTFS-Berechtigungen auf dem Ziel-Server überprüfen. Kopiert man die Benutzerprofile mit dem Windows-Explorer, gehen Berechtigungen zwischen den Domänen verloren bzw. es werden die Berechtigungen des übergeordneten Ordners vererbt.

Tipp: Die Benutzerprofile mit robocopy kopieren:

robocopy \\QUELLE\PROFILFREIGABE \\ZIEL\PROFILFREIGABE /mir /sec /xj

Die Option „/sec“ bewirkt, das die Sicherheitsinformationen, d.h. die NTFS-Berechtigungen mit kopiert werden. Dennoch sollte man prüfen, ob die Berechtigungen richtig sind, d.h. das System, die Administratoren und der jeweilige Benutzer sollten Vollzugriff auf das Profil haben.

Leider fehlt im ADMT die Möglichkeit servergespeicherte Terminalserver- bzw. Remotedesktopdienste-Profile zu migrieren. Lokale Profile, also Benutzerprofile die auf dem Terminal- bzw. Remotedesktopdienste-Server gespeichert sind, sollten hingegen konvertierbar und damit migrierbar sein.

Hinweis: ADMT entfernt, sofern gesetzt, das Flag „Kennwort läuft nie ab“ aus den migrierten Benutzerkonten.

Computer migrieren

Bevor erfolgreich Computer in die Ziel-Domäne migriert werden können, müssen die Administratoren die notwendigen Zugriffsberechtigungen erhalten.

Besteht eine Vertrauensstellung zwischen den Domänen, so kann das über die Gruppenrichtlinien erreicht werden. Dazu in der Quell-Domäne eine neue Gruppenrichtlinie mit folgender Einstellung anlegen:

Computerkonfiguration - Richtlinien - Windows-Einstellungen - Sicherheitseinstellungen - Eingeschränkte Gruppen
  • Mit der rechten Maustaste auf eine leere Fläche im rechten Teil des Fensters klicken und „Neue Gruppe…“ auswählen.
  • Den Namen „Administratoren“ vergeben.
  • Im Abschnitt „Mitglieder dieser Gruppe“ den Administrator der Ziel-Domäne hinzufügen. Achtung: Alle zuvor in dieser Gruppe vorhandenen Mitglieder, mit Ausnahme des lokalen Administrators, werden entfernt! Per Standard sind der lokale Administrator und die Domänen-Admins, als auch der Benutzer, der bei der Installation angelegt wurde, Mitglied dieser Gruppe.

Besteht keine Vertrauensstellung zwischen den Domänen oder als Alternative zum Ändern der lokalen Administratoren-Gruppe auf den zu migrierenden Computer, kann der runas-Befehl verwendet werden:

runas /netonly /user:ZIELDOMÄNE\Administrator "mmc C:\Windows\ADMT\migrator.msc"

Ferner muss die Firewall so konfiguriert sein, das die Remoteverwaltung zugelassen ist. Dazu kann in den Gruppenrichtlinien der vordefinierte Regelsatz „Remoteverwaltung“ verwendet werden.

  • ADMT ausführen.
  • Auf „Aktion“ und „Assistent zum Migrieren von Computerkonten“ anklicken.
  • Quell- und Ziel-Domäne samt Domänencontroller angeben.
  • Die Voreinstellung „Computer aus Domäne auswählen“ belassen.
  • Die Computer auswählen.
  • Die Ziel-OU angeben.
  • Die zu konvertierenden Objekte auswählen.
  • Bei „Optionen für die Sicherheitskonvertierung“ „Hinzufügen“ auswählen.
  • Die Wartezeit angeben, nach der die Computer automatisch neu gestartet werden, sobald die Migration abgeschlossen ist.
  • Im „Active Directory-Migrationprogramm – Agent“ „Vorüberprüfung und Agent“ auswählen und „Starten“ anklicken.

Der Agent wird auf den zu migrierenden Computern installiert und ausgeführt, anschließend werden die lokalen Objekte konvertiert und die Domänen-Mitgliedschaft des Computers geändert. Zuletzt wird der Computer automatisch neu gestartet. Der gesamte Vorgang kann durchaus pro Computer ein paar Minuten in Anspruch nehmen.

Vorsicht Falle: Je nachdem wie die Computer ihre IP-Konfiguration erhalten (statisch/DHCP), muss darauf geachtet werden, das Sie nach der Migration den richtigen Eintrag für den DNS-Server erhalten.

Nun können sich die Benutzer an ihren Computern und mit ihrem Profil in der Ziel-Domäne anmelden.

Persönliche Anmerkung

Das ADMT ist eine feine Sache. Zugegeben, ich habe es zuletzt vor gut 10 Jahren benötigt, von daher war die Überraschung groß, das mittlerweile ein SQL Server 200x Express Edition notwendig ist, um Dieses auszuführen und auf einem Domänencontroller das Ganze nicht mehr so „schnell und einfach“ funktioniert. Die Empfehlung lautet daher ganz klar, ADMT und den SQL Server auf einem Mitgliedsserver zu installieren. Das erhöht den Aufwand leider um einiges. Schade, mir tut sich dabei der Gedanke auf, das Microsoft das Tool „verschlimmbessert“ hat. Für große Migrationen ist das sicherlich kein Thema, aber im KMU-Bereich schon. Aber auch das ist Lösbar, wenn für die Dauer der Migration entweder mal ein PC oder eine VM zusätzlich herhalten muss.

Update 15.01.2013

Die letzten Tage habe ich immer wieder ein paar Aktualisierungen in diesem Beitrag vorgenommen. Primär soll dieser Beitrag als Informationsquelle dienen. Vor einer Live-Migration sollte man das Vorgehen je nach Ausgangssituation auf jeden Fall testen!

Links

Handbuch zum Active Directory-Migrationsprogramm (Active Directory Migration Tool): Migrieren und Neustrukturieren von Active Directory-Domänen
Aktivieren der Kennwortmigration
Migration / Zusammenführung von zwei Domänen
Zentrale Steuerung und Vergabe von lokalen Sicherheitseinstellungen der Clients
SBS 2003 to SBS 2008 Migration to a Different Domain Name

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.