LDAP://Yusufs.Directory.Blog/ - Active Directory|Migration

Die verschiedenen ADMT Versionen

Yusuf Dikmenoglu — Wed, 23 Jun 2010 11:58:31 GMT

Anlässlich des Erscheinens der aktuellen ADMT Version 3.2 findet ihr hier eine Übersicht die aufzeigt:

Welche ADMT Version sich auf welchem Serverbetriebssystem installieren lässt.
Mit welcher ADMT Version man von welcher Quell-Domäne zu welcher Ziel-Domäne migrieren kann.
Auf welchen Systemen sich der ADMT Agent installieren lässt.

*ADMT Version*	OS	*Kann installliert werden auf*	*Quell-Domäne*	*Ziel-Domäne*	*ADMT Agent kann installiert werden auf*
ADMT 3.2	Windows Server 2008 R2	ü (nicht auf RODC und Server Core)	ü	ü	ü
	Windows Server 2008	X	ü	ü	ü
	Windows Server 2003	X	ü	ü	ü
	Windows 2000 Server	X	X	X	X
	Windows NT Server 4.0	X	X	X	X
	Windows 7	X	X	X	ü
	Windows Vista	X	X	X	ü
	Windows XP	X	X	X	ü
	Windows 2000 Professional	X	X	X	X

*ADMT Version*	OS	*Kann installliert werden auf*	*Quell-Domäne*	*Ziel-Domäne*	*ADMT Agent kann installiert werden auf*
ADMT 3.1	Windows Server 2008 R2	X	X	ü	ü
	Windows Server 2008	ü (nicht auf RODC und Server Core)	ü	ü	ü
	Windows Server 2003	X	ü	ü	ü
	Windows 2000 Server	X	ü	ü	ü
	Windows NT Server 4.0	X	X	X	X
	Windows 7	X	X	X	ü
	Windows Vista	X	X	X	ü
	Windows XP	X	X	X	ü
	Windows 2000 Professional	X	X	X	ü

*ADMT Version*	OS	*Kann installliert werden auf*	*Quell-Domäne*	*Ziel-Domäne*	*ADMT Agent kann installiert werden auf*
ADMT 3.0	Windows Server 2008 R2	X	X	X	X
	Windows Server 2008	X	X	X	X
	Windows Server 2003	ü	ü	ü	ü
	Windows 2000 Server	X	ü	ü	ü
	Windows NT Server 4.0	X	ü	X	ü
	Windows 7	X	X	X	X
	Windows Vista	X	X	X	X
	Windows XP	X	X	X	ü
	Windows 2000 Professional	X	X	X	ü

*ADMT Version*	OS	*Kann installliert werden auf*	*Quell-Domäne*	*Ziel-Domäne*	*ADMT Agent kann installiert werden auf*
ADMT 2.0	Windows Server 2008 R2	X	X	X	X
	Windows Server 2008	X	X	X	X
	Windows Server 2003	ü	ü	ü	ü
	Windows 2000 Server	ü	ü	ü	ü
	Windows NT Server 4.0	X	ü	X	ü
	Windows 7	X	X	X	X
	Windows Vista	X	X	X	X
	Windows XP	X	X	X	ü
	Windows 2000 Professional	X	X		X

Weitere Informationen:
Eine Domänenmigration durchführen
Einen Domänensplitt durchführen
ADMT Version 3.1
Benutzermigration mit ADMT v3: How-To
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
Active Directory Migration Tool v.2.0
Password Export Server version 3.1 (x86)
Password Export Server version 3.1 (x64)

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

ADMT 3.2 ist da!

Yusuf Dikmenoglu — Sat, 19 Jun 2010 08:16:22 GMT

Seit der Veröffentlichung von Windows Server 2008 R2 konnte die bis dahin aktuelle ADMT Version 3.1 nicht auf einem Windows Server 2008 R2 installiert werden. Möchte man die bestehende Windows 2000, Windows Server 2003 oder Windows Server 2008 Umgebung mit ADMT in eine Windows Server 2008 R2 Domäne migrieren, muss dazu die ADMT Version 3.1 auf einem Windows Server 2008 installiert werden.

Nun hat aber Redmond die ADMT Version 3.2 veröffentlicht. Diese Version lässt sich ausschließlich auf einem Windows Server 2008 R2 installieren.

Active Directory Migration Tool version 3.2

Das aktualisierte ADMT-Handbuch findet man hier:

Active Directory Migration Tool (ADMT) Guide: Migrating and Restructuring Active Directory Domains

Mit ADMT 3.2 können Migrationen von folgenden Quell-Domänen durchgeführt werden:>>>>

- Windows Server 2003
- Windows Server 2008
- Windows Server 2008 R2

Als Ziel-Domänen werden ebenfalls diese unterstützt:

- Windows Server 2003
- Windows Server 2008
- Windows Server 2008 R2 >

Wie unschwer zu erkennen ist, kann man ADMT 3.2 nicht für eine Migration von Windows 2000 verwenden!
Wer eine Windows 2000 Domäne migrieren möchte, der muss ADMT 3.1 verwenden.

ADMT 3.2 lässt sich wie schon ADMT 3.1 nicht auf einem Server Core oder RODC installieren!

Wer eine Migration mit diesem Werkzeug durchgeführt hat, weiß es zu schätzen! Vor allem da es kostenlos von Microsoft zur Verfügung gestellt wird.

Viel Erfolg bei euren Migrationen! :-)

Weitere Informationen:
Eine Domänenmigration durchführen
ADMT Version 3.1
Einen Domänensplitt durchführen

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Hinweise zu ADPREP

Yusuf Dikmenoglu — Sun, 21 Feb 2010 13:21:44 GMT

Bevor der erste Server, der mit einem neueren Serverbetriebssystem installiert ist als die bereits bestehenden Domänencontroller (DCs) einer Gesamtstruktur, als DC zur Gesamtstruktur hinzugefügt werden kann, muss vorher zwingend mit dem Active Directory Preparation Tool (ADPREP) das Active Directory-Schema aktualisiert werden. Erst nachdem ADPREP ausgeführt wurde, kann der neue Server als DC zur Gesamtstruktur hinzugefügt werden. Dabei muss ADPREP stets von der CD/DVD ausgeführt werden, mit dem der neue Server installiert wurde. Möchte man also einen Windows Server 2008 oder Windows Server 2008 R2 in eine Windows 2000 bzw. Windows Server 2003 Gesamtstruktur hinzufügen, so muss das ADPREP von der Windows Server 2008 bzw. Windows Server 2008 R2 DVD ausgeführt werden.

ADPREP muss aber nur dann ausgeführt werden, wenn der Server mit dem neueren Serverbetriebssystem zum DC gestuft werden soll! Wird der neue Server lediglich als Mitgliedsserver zur Domäne hinzugefügt, so muss das ADPREP nicht ausgeführt werden.

Soll der Server, der mit einem neuerem OS (Operating System = Betriebssystem) installiert ist als die existierenden DCs, zu einer bestehenden Domäne als zusätzlicher DC hinzugefügt werden, muss zuerst ADPREP /FORESTPREP auf dem Schemamaster und anschließend ADPREP /DOMAINPREP /GPPREP auf dem Infrastrukturmaster in der Domäne ausgeführt werden, zu der der neue Server als DC hinzugefügt werden soll.

Wird jedoch mit dem neuen Server eine neue Subdomäne in einer bestehenden Gesamtstruktur erstellt, muss lediglich das ADPREP /FORESTPREP ausgeführt werden. Das ADPREP /DOMAINPREP /GPPREP muss und kann in diesem Szenario nicht ausgeführt werden, da es keine zu aktualisierende Domäne gibt. Schließlich wird mit dem neuen DC erst eine (weitere) Subdomäne erstellt.

Weitere Details beschreibt der folgende Artikel: >

Das Active Directory Preparation Tool - ADPREP

Fehler die beim Ausführen von ADPREP auftreten können

Wenn das Ausführen von ADPREP aus welchen Gründen auch immer fehl schlagen sollte, ist es empfehlenswert als erstes immer ins ADPREP-Protokoll zu schauen. Das ADPREP-Log wird im Verzeichnis %windir%\System32\Debug\Adprep\Logs erstellt und enthält einen detaillierten Bericht zur Domänen- und Gesamtstrukturvorbereitung.
Bevor der erste Server mit neuerem OS als die bereits existierenden DCs, als DC zur Gesamtstruktur hinzugefügt werden kann, muss zuerst das ADPREP /FORESTPREP in der Kommandozeile auf dem Schemamaster ausgeführt werden. Das Benutzerkonto mit dem dieser Befehl ausgeführt wird, muss Mitglied in den Gruppen Schema-Admins, Organisations-Admins und Domänen-Admins in der Domäne sein, in der sich der Schemamaster befindet.
Wenn ADPREP /FORESTPREP auf dem Schemamaster mit den notwendigen Rechten ausgeführt wurde und es trotzdem zu einem Fehler führt, weil ADPREP keinen Kontakt zum Schemamaster herstellen konnte (in seltenen Fällen), sollte der Schemamaster zuerst auf einen anderen DC und erneut zurück verschoben werden. Anschließend ist der Befehl ADPREP /FORESTPREP nochmals auszuführen.
Befindet sich das Benutzerkonto beim ausführen von ADPREP hingegen nicht in den entsprechenden Gruppen, kommt es zu diesem Fehler:

Adprep encountered a Win32 error.
Error code: 0x5 Error message: Access is denied

Das Benutzerkonto muss zum ausführen von ADPREP /FORESTPREP Mitglied in den folgenden Gruppen sein:

- Schema-Admins
- Organisations-Admins
- Domänen-Admin in der Domäne, in der sich der Schemamaster befindet.
Zum ausführen von ADPREP /DOMAINPREP /GPPREP muss das Benutzerkonto Mitglied in der Gruppe Domänen-Admins in der Domäne sein, in der dieser Befehl auf dem Infrastrukturmaster ausgeführt wird.
Kommt es beim ausführen von ADPREP /FORESTPREP zu diesem Fehler:

Es war Adprep nicht möglich, das Schema zu erweitern.

[Status/Folgen]

Der Schemamaster schloss einen Replikationszyklus nach dem letzten Neu-Start nicht ab. Der Schemamaster muss mindestens einen Replikationszyklus, bevor das Schema erweitert werden kann, abschließen.

[Benutzeraktion]

Überprüfen Sie, dass der Schemamaster mit dem Netzwerk verbunden ist, und mit anderen Domäne-Controllern kommunizieren kann…

liegt ein AD-Replikationsproblem vor. Es ist zwingend, dass zuerst das Replikationsproblem behoben wird, bevor das Ausführen von ADPREP erfolgreich durchgeführt werden kann. Einen ersten Ansatz zur Fehlersuche bei der AD-Replikation sollte neben dem Eventlog, auch das Schweizer Messer der AD-Replikation REPADMIN zum Vorschein bringen. Mit ausführen von Repadmin /Showreps bzw. Repadmin /Showrepl auf dem Schemamaster sieht man recht schnell, mit welchen DCs der Schemamaster nicht replizieren kann.

Wenn die DCs identifiziert wurden mit denen der Schemamaster nicht replizieren kann, sollte man versuchen sich per UNC auf die DCs zu verbinden. Bekommt man auf dem Schemamaster mit \\DC-Computername und \\FQDNdesDCs keine Verbindung zu den betroffenen DCs hin, liegt entweder ein Netzwerkproblem, ein DNS Problem, ein gebrochener sicherer Kanal (secure channel) oder ein Zeitunterschied von mindestens fünf Minuten zwischen den DCs vor. Gerade das DNS ist für eine AD-Umgebung von großer Bedeutung! Ein Ping sowohl auf die IP-Adresse als auch auf den Computernamen sollte von und zu den betroffenen DCs erfolgreich sein. Funktioniert ein Ping auf die IP-Adresse nicht, liegt höchstwahrscheinlich ein Netzwerkproblem vor. Es sollte der Weg vom Schemamaster zum betroffenen DC untersucht werden.

Funktioniert hingegen ein Ping auf den Computernamen oder FQDN des DCs nicht, liegt höchstwahrscheinlich ein DNS-Problem vor. In den TCP/IP-Einstellungen des DCs sollte ein zentraler DNS-Server als primärer DNS-Server eingetragen werden. Des Weiteren sollte in der Forward Lookup Zone überprüft werden, ob die SRV-Einträge existieren.
Mit Repadmin /KCC <DC> sollte anschließend die eingehende Replikationstopologie auf den DCs neu berechnet werden.
Auch durch Schemakonflikte kann ADPREP Fehler verursachen. Wurden benutzerdefinierte Schemaänderungen vorgenommen oder Schemaänderungen durch Drittanbieterlösungen durchgeführt die mit einer Schemaaktualisierung durch ADPREP in Konflikt stehen, kann es ebenfalls zu Fehlern kommen. Die Fehler die angezeigt werden können darauf hindeuten, dass der Object Identifier (OID) nicht geändert wurde und somit keine neuen Klassen dem AD-Schema hinzugefügt werden können. Das Konfliktobjekt wird im ADPREP-Protokoll protokolliert. Wenn das Objekt das den Konflikt verursacht hat durch eine Drittanbieterlösung ins AD-Schema hinzugefügt wurde, sollte man sich für eine Lösung des Problems an den Hersteller wenden. Andernfalls sollte man sich an den (kostenpflichtigen) Microsoft Produkt Support Service (MS PSS) wenden.
Ein weiterer Schemakonflikt könnte entstehen, wenn eine Verknüpfungskennung (Link Identifier) für ein Attribut durch eine Drittanbieterlösung bereits vergeben ist und ADPREP beim aktualisieren von bestehenden Attributen oder beim hinzufügen von neuen, dieselbe Verknüpfungskennung ebenfalls vergeben möchte. In diesem Fall sollte der MS PSS kontaktiert werden.
Wenn beim ausführen von ADPREP /FORESTPREP der Fehler Adprep konnte wegen eines Fehlers der Rückruffunktion nicht abgeschlossen werden erscheint, ist der Schuldige der Virenscanner. Der Echtzeitscanner (On-Access) agiert im Hintergrund als Systemdienst und scannt unsichtbar alle Dateien, Programme und den Arbeitsspeicher. Hat der Echtzeitscanner eine Datei oder ein Verzeichnis im Zugriff worauf ebenfalls beim ausführen von ADPREP /FORESTPREP der Zugriff auf dieselben Dateien oder Verzeichnisse benötigt wird, erscheint diese Fehlermeldung. Wenn dieser Fehler erscheint, muss der Virenscanner deaktiviert und anschließend erneut ADPREP /FORESTPREP ausgeführt werden. Danach kann der Virenscanner aktiviert werden.
Die Fehlermeldung Adprep konnte wegen eines Fehlers der Rückruffunktion nicht abgeschlossen werden kann auch erscheinen, wenn ADPREP /DOMAINPREP /GPPREP ausgeführt wurde. Dann muss der Virenscanner zuerst deaktiviert und anschließend ADPREP /DOMAINPREP /GPPREP erneut ausgeführt werden. Oder wenn im ADPREP-Protokoll der Fehler Error 0x80070020 (Error_sharing_Violation) protokolliert wird, liegt das ebenso am Virenscanner. Das Deaktivieren des Virenscanners sollte auch in diesem Fall zum Erfolg führen.

Führt das deaktivieren des Virenscanners nicht zum Ziel, könnte es noch an den folgenden Ursachen liegen:

1. Der Registry-Eintrag HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SYSVOL ist nicht vorhanden oder zeigt nicht auf das echte SYSVOL Verzeichnis %windir%\SYSVOL\sysvol. Wenn der Eintrag fehlt, muss ein REG_SZ Eintrag mit dem Pfad zum SYSVOL-Verzeichnis erstellt werden.

2. Die Default Domain Policy (die GUID ist {31B2F340-016D-11D2-945F-00C04FB984F9} ) und Default Domain Controllers Policy (die GUID ist {6AC1786C-016F-11D2-945F-00C04fB984F9} ) fehlen im SYSVOL Verzeichnis.

3. Im SYSVOL Verzeichnis fehlt das SCRIPTS Verzeichnis.
4. Der NTFS-Bereitstellungspunkt und/oder die Bereitstellungspunkte zwischen %windir%\SYSVOL\sysvol\domain und %windir%\SYSVOL existieren nicht (mehr). Sollten die Bereitstellungspunkte fehlen, so können diese mit dem Tool LINKD erneut gesetzt werden.

Die Befehle lauten:

LINKD %windir%\SYSVOL\SYSVOL\<DNS-Domänenname> %windir%\sysvol\domain
LINKD %windir%\SYSVOL\staging areas\<DNS-Domänenname> %windir%\SYSVOL\staging\domain
LINKD %windir%\SYSVOL\sysvol\<FQDN>
Wenn ADPREP /FORESTPREP ausgeführt wurde, müssen die Änderungen zuerst auf den Infrastrukturmaster in der Domäne repliziert werden, in der der neue Server als zusätzlicher DC hinzugefügt werden soll. Erst dann kann mit Domänen-Admin Rechten der Befehl ADPREP /DOMAINPREP /GPPREP auf dem Infrastrukturmaster ausgeführt werden. Wurden die Änderungen noch nicht auf den Infrastrukturmaster repliziert oder wenn ADPREP /FORESTPREP nicht ausgeführt wurde, meldet das ADPREP /DOMAINPREP /GPPREP einen Fehler der darauf hinweist, dass die Gesamtstrukturweiten Informationen zuerst aktualisiert werden müssen.
Der Domänenfunktionsmodus muss sich im einheitlichen Modus (Windows 2000 pur, Windows Server 2003 oder Windows Server 2008) befinden. Ansonsten schlägt das Ausführen von ADPREP /DOMAINPREP /GPPREP fehl!

Domänen- und Gesamtstrukturfunktionsmodus
Wenn ADPREP /RODCPREP mit Organisations- und Domänen-Admin Rechten auf einem Infrastrukturmaster ausgeführt wird, kann es zu folgendem Fehler kommen:

Adprep konnte kein Replikat für Partition DC=ForestDnsZones,DC=Root-Domäne erreichen.
ADPREP hat einen LDAP-Fehler festgestellt.
Fehlercode: 0x0. Erweiterter Server-Fehlercode: 0x0, Server-Fehlermeldung:(null).

und

Adprep konnte kein Replikat für Partition DC=DomainDnsZones,DC=Domäne,DC=de erreichen.
ADPREP hat einen LDAP-Fehler festgestellt.
Fehlercode: 0x0. Erweiterter Server-Fehlercode: 0x0, Server-Fehlermeldung:(null).
Dann muss der Infrastrukturmaster den entsprechenden DNS-Anwendungsverzeichnispartition idealerweise auf den aktuellen Infrastrukturmaster der Domäne verschoben werden. Wie das vonstattengeht, beschreibt der folgende Artikel:

Die Infrastrukturmaster der Anwendungsverzeichnispartitionen

Weitere Informationen:
Die FSMO-Rollen verschieben

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen

Yusuf Dikmenoglu — Sun, 18 Jan 2009 11:07:24 GMT

Microsoft veröffentlicht im Herbst 2009 sein nächstes Serverbetriebssystem namens Windows Server 2008 R2. Das Minor Release wird ausschließlich in der x64-Bit Version und nicht mehr wie bisher in der 32-Bit Version erscheinen.

Ein Highlight-Feature im neuen Serverbetriebssystem stellt der Active Directory-Papierkorb dar, mit dem gelöschte Objekte samt allen Informationen (inklusive der Backlinks, wie z.B. die Gruppenmitgliedschaften eines Benutzers) wiederhergestellt werden können. Somit hat ein versehentliches löschen von Active Directory-Objekten in den Active Directory Domain Services (AD DS) und Active Directory Lightweight Directory Services (AD LDS, ehemals Active Directory Application Mode, kurz ADAM) keine weiteren Folgen. Weder entsteht bei der Wiederherstellung ein Verlust von Informationen, noch muss dafür der DC im Modus Verzeichnisdienstwiederherstellung gestartet werden.

Die Voraussetzung um dieses Feature nutzen zu können, ist der Gesamtstrukturfunktionsmodus Windows Server 2008 R2. Das bedeutet, alle Domänencontroller (DC) in allen Domänen einer Gesamtstruktur müssen unter Windows Server 2008 R2 betrieben werden.

>>>

Was ist möglich

Ein Windows Server 2008 R2 DC kann als zusätzlicher Domänencontroller zu einer Windows 2000 32bit Domäne hinzugefügt werden. >
Ein Windows Server 2008 R2 DC kann als zusätzlicher Domänencontroller einer Windows Server 2003 bzw. Windows Server 2003 R2 Domäne hinzugefügt werden. Dabei können die bestehenden DCs sowohl unter einem 32bit, 64bit als auch iA64 Serverbetriebssystem betrieben werden.
Ein Windows Server 2008 R2 DC kann als zusätzlicher Domänencontroller einer Windows Server 2008 Domäne hinzugefügt werden. Die bereits existierenden DCs können ebenfalls unter 32bit, 64bit oder iA64 laufen.
Ein Windows Server 2003 ab SP2 64bit DC oder Windows Server 2003 R2 mit SP2 64bit DC kann per Inplace-Update auf Windows Server 2008 R2 aktualisiert werden.
Ein 64bit Windows Server 2008 DC kann per Inplace-Update auf Windows Server 2008 R2 aktualisiert werden.
Ein 64bit Windows Server 2008 Core DC kann per Inplace-Update auf einen Windows Server 2008 R2 Core aktualisiert werden.

Hinweis 1: Auch wenn die Mindestvoraussetzung für ein Inplace-Update ein Windows Server 2003 SP2 ist, sollte das System natürlich vor dem Update auf dem aktuellen Service Pack- sowie Patch-Stand sein. Wobei es ohnehin ratsam wäre, die Domänenaktualisierung durch einen zusätzlichen DC durchzuführen.

Hinweis 2: Vor einem Inplace-Update muss überprüft werden, ob auf dem DC die installierten Applikationen auch weiterhin unter Windows Server 2008 R2 noch funktionieren. Ein Telefonat mit dem Hersteller der Applikation sollte das schnell klären.

>>>>>>>>

Was ist nicht möglich

>>>>>>>>

Ein Inplace-Update von Windows NT auf Windows Server 2008 R2 wird nicht unterstützt. Es müsste zuerst ein Inplace-Update des NT-PDCs auf Windows Server 2003 SP1/SP2/2003 R2 und anschließend auf Windows Server 2008 R2 durchgeführt werden. Oder man migriert mit ADMT in eine Windows Server 2008 R2 Domäne.

Durch die Änderung des Secure Channel (die Option "Secure channel: Require strong (Windows 2000 or later) session key" wurde nun mit Windwos Server 2008 R2 hard coded und lässt sich nicht mehr abschwächen wie es noch unter Windows Server 2008 möglich ist) zugunsten der Sicherheit ist es nicht mal möglich, Windows NT Clients sowie NT Mitgliedsserver in einer Windows Server 2008 R2 Domäne zu betreiben!
Des Weiteren kann auch keine Vertrauensstellung zwischen einer Windows Server 2008 R2 und einer Windows NT Domäne erstellt werden.
Ein DC älter als ein Windows Server 2003 SP2 x64-System, kann nicht per Inplace-Update auf Windows Server 2008 R2 aktualisiert werden.
Ein Inplace-Update von Windows Server 2003 SP1/SP2/2003 R2 x64 oder Windows Server 2008 x64 Vollinstallation (kein Server Core), ist auf den Windows Server 2008 R2 Core nicht möglich.
Ein Inplace-Update eines x64 Windows Server 2008 Core DCs kann nicht auf Windows Server 2008 R2 Vollinstallation durchgeführt werden.

Windows Server 2008 Core
Ein Cross-Update von einem x86 auf x64 System wird nicht unterstützt. Ebenso wenig wie von einem iA64 auf x64 System. Das bedeutet, es ist nicht möglich auf einem 32bit Windows Server 2003 SP1/SP2/2003 R2/2008 DC eine Windows Server 2008 R2 DVD einzulegen, um das System per Inplace-Update zu aktualisieren.
Ein Cross-Update auf eine andere Betriebssystem-Sprache wird nicht unterstützt. Als Beispiel: Auf einem deutschen Windows Server 2003 SP2 x64 DC wird die englische Windows Server 2008 R2 DVD eingelegt um den DC, auf einen englischen Windows Server 2008 R2 DC zu aktualisieren.

Die Voraussetzungen für eine Windows 2000/2003/2003 R2/2008 Gesamtstruktur, damit der erste Windows Server 2008 R2 DC hinzugefügt werden kann

Die Domäne in der man den Windows Server 2008 R2 DC hinzufügen möchte, muss sich im einheitlichen Domänenfunktionsmodus (entweder Windows 2000 pur, Windows Server 2003 oder Windows Server 2008) befinden. Denn wenn sich die Domäne nicht im einheitlichen Domänenfunktionsmodus befindet, lässt sich der Befehl Adprep /Domainprep /Gpprep nicht ausführen. In welchem Modus sich der Gesamtstrukturfunktionsmodus befindet, spielt dabei keine Rolle.
Ist jedoch der Einsatz eines Windows Server 2008 oder Windows Server 2008 R2 RODCs in der Gesamtstruktur geplant, so ist das erst ab der Gesamtstrukturfunktionsebene Windows Server 2003 möglich. Des Weiteren muss sich bereits ein Windows Server 2008 DC oder Windows Server 2008 R2 DC in der Domäne befinden, in der man den RODC hinzufügen möchte.
Alle Domänencontroller in der Gesamtstruktur sollten sich mindestens auf Windows 2000 Server mit Service Pack 4 oder höher befinden.

Schritt für Schritt-Anleitung für eine 32bit oder x64 Windows 2000/2003/2003 R2/2008 Gesamtstruktur, damit der erste Windows Server 2008 R2 DC hinzugefügt werden kann

Zuerst muss das Active Directory Preparation Tool (kurz ADPREP), das sich auf der Windows Server 2008 R2 DVD im Verzeichnis <DVD-Laufwerk>:\Support\Adprep befindet, mit dem Parameter /Forestprep auf dem Schema-Master ausgeführt werden. Allerdings befinden sich im Adprep-Verzeichnis zwei ADPREP-Dateien. Eine „Adprep.exe“ für x64-DCs und eine „Adprep32.exe“ für 32bit-DCs. Mit ausführen von Adprep32 /Forestprep auf einem 32bit Schema-Master, wird die Gesamtstruktur auf Windows Server 2008 R2 aktualisiert. Befindet sich der Schema-Master auf einem x64 DC, so lautet der Befehl Adprep /Forestprep.

Hinweis: Im weiteren Verlauf des Artikels wird die x32Bit Version des Adpreps angegeben, da sicherlich in den meisten Unternehmen noch hauptsächlich 32bit DCs existieren.

Der Parameter /Forestprep muss und kann nur ein einziges Mal in der Gesamtstruktur ausgeführt werden. Dabei muss das Benutzerkonto mit dem das ADPREP ausgeführt wird, Mitglied der folgenden drei Gruppen sein:

- Organisations-Admins
- Schema-Admins
- Domänen-Admins in der Domäne, in der der Schema-Master Mitglied ist
Ruft man das Adprep32 /Forestprep nicht auf dem Schema-Master auf, bringt das Tool den Hinweis, dass die Gesamtstrukturaktualisierung nur auf dem Schema-Master durchgeführt werden kann und bricht den Vorgang ab. Microsoft empfiehlt das Verzeichnis „Adprep“ (mit dem kompletten Inhalt!) vorher auf den DC zu kopieren, um z.B. Lesefehler des DVD-Laufwerks während der Ausführung von Adprep zu vermeiden.

An error occurs when you run the ADPREP/FORESTPREP command on a Windows Server 2003-based or Windows Server 2008-based computer: "An attribute with the same link identifier already exists"
Das Adprep32 /Forestprep aktualisiert die Gesamtstruktur auf Windows Server 2008 R2, in dem neue Attribute sowie Klassen dem Schema hinzugefügt bzw. bestehende (z.B. die Berechtigungen) geändert werden. Nach dem Aufruf von Adprep32 /Forestprep werden abhängig von der Schema-Version die LDF-Dateien, die zur Schema-Aktualisierung benötigt werden, aus dem Verzeichnis „Support\Adprep“ auf dem DC in das Verzeichnis „%windir%\system32“ kopiert.

In einer Windows 2000 Gesamtstruktur werden die LDF-Dateien ab sch14.ldf, in einer Windows Server 2003 ab sch31.ldf, in einer Windows Server 2003 R2 ab sch32.ldf und in einer Windows Server 2008 Umgebung ab sch45.ldf bis zur sch47.ldf in das Schema importiert. Das Schema wird somit auf die Version 47 aktualisiert.

Die Schema-Versionen sind (in Dezimal):

- Schema-Version 13 = Windows 2000 RTM mit allen Service Packs
- Schema-Version 30 = Windows Server 2003 RTM mit allen Service Packs
- Schema-Version 31 = Windows Server 2003 R2 RTM mit allen Service Packs
- Schema-Version 44 = Windows Server 2008 RTM mit allen Service Packs
- Schema-Version 47 = Windows Server 2008 R2 mit allen Service Packs

Die Schema-Version kann man sich auf jedem DC in der Gesamtstruktur zum einen in der Registry in dem folgenden Pfad ansehen:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\<Schema Version>
Zum anderen lässt sich im Attribut objectVersion, das sich in den Eigenschaften der Schema-Partition CN=Schema,CN=Configuration,DC=<Root-Domäne>,DC=<TLD> befindet, die Schemaversion anzeigen (z.B. mit ADSIEdit.msc oder LDP.exe).

Auch mit Dsquery lässt sich die Schema-Version abfragen. Der Befehl lautet wie folgt:
dsquery * CN=Schema,CN=Configuration,DC=Root-Domäne -Scope Base -attr objectVersion
Wenn das Adprep32 /Forestprep durchgeführt wurde, wird in der Konfigurationspartition der Container CN=ActiveDirectoryUpdate,CN=ForestUpdates,CN=Configuration,DC=<Root-Domäne> erstellt. Der Container selbst bleibt leer. Das Attribut Revision in den Eigenschaften des Containers CN=ActiveDirectoryUpdate erhält den Wert 5. Danach sollte sichergestellt werden, dass sich dieser Container zuerst auf alle DCs der Gesamtstruktur repliziert, um dann den nächsten Schritt mit Adprep durchzuführen.

In erster Linie sollten die DC`s der einzelnen Domänen die Aktualisierung empfangen haben, die die FSMO-Rolle des Infrastruktur-Master innehaben. Dazu gilt es den nächsten Punkt zu beachten.

Hinweis für Windows Server 2008 Umgebungen: Falls schon ein Windows Server 2008 DC in der (z.B. Windows 2000 oder Windows Server 2003) Domäne besteht oder es sich um eine reine Windows Server 2008 Umgebung handelt, existiert bereits der Container CN=ActiveDirectoryUpdate. Das Attribut Revision enthält dagegen als Wert 2. Wird nun das Adprep32 /Forestprep von der Windows Server 2008 R2 DVD ausgeführt, wird der Wert auf 5 geändert.

Hinweis: Im Gegensatz zu Windows Server 2008 Zeiten kann nun auch auf einem deutschen Schemamaster das ADPREP von einer englischen Windows Server 2008 R2 DVD ausgeführt werden. Zu Zeiten Windows Server 2008 gab es an dieser Stelle ein Sprach-Problem und nach dem Ausführen von ADPREP passierte einfach nichts, es erschien noch nicht einmal eine Fehlermeldung. Aber: Existiert ein englischer Schemamaster und man führt das ADPREP von einer deutschen Windows Server 2008 R2 DVD aus, besteht der Fehler weiterhin. Der Cursor blinkt in der nächsten Zeile ohne das irgendetwas passiert. Besteht ein englischer Schemamaster, kann man entweder den Schemamaster auf einen deutschen DC verschieben und danach das ADPREP von einer deutschen DVD ausführen oder man führt das ADPREP gleich von einer englischen DVD aus!
ADPREP "multi-language"
Im zweiten Schritt muss das Adprep32 mit den Parametern /Domainprep /Gpprep auf dem Infrastruktur-Master in der Domäne, in der man den Windows Server 2008 R2 als DC hinzufügen möchte, ausgeführt werden. Das Benutzerkonto, mit dem dieser Befehl ausgeführt wird, muss Mitglied der Sicherheitsgruppe Domänen-Admins sein. Mit Ausführen von /Domainprep /Gpprep wird die Domäne auf Windows Server 2008 R2 aktualisiert. Der Parameter /Domainprep bewirkt, dass neue Objekte erstellt sowie die ACLs an diversen Objekten in der Domänenpartition geändert werden. Der Parameter /Gpprep sorgt dafür, dass die Berechtigungen der Gruppenrichtlinienobjekte die sich im Sysvol-Verzeichnis befinden, angepasst werden. Führt man diesen Befehl aus, noch bevor die Gesamtstrukturaktualisierung auf den Infrastruktur-Master repliziert wurde, bricht der Vorgang ab. Dieser bricht auch dann ab, wenn der Befehl nicht auf dem Infrastruktur-Master ausgeführt wird. Durch Ausführen dieses Befehls wird der folgende Container in der Domänenpartition erstellt: CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System,DC=<Domäne>

Auch dieser Container bleibt leer. Das Attribut Revision das sich in den Eigenschaften des Containers CN=ActiveDirectoryUpdate befindet, bekommt ebenfalls den Wert 5. Es ist möglich zuerst das Adprep lediglich mit dem Parameter /Domainprep auszuführen und zu einem späteren Zeitpunkt die Berechtigungen der GPOs, mit Adprep /Domainprep /Gpprep zu aktualisieren. Empfehlenswert ist jedoch, beide Parameter in einem Schritt durchzuführen.

Hinweis für Windows Server 2008 Umgebungen: Wenn sich aber bereits ein Windows Server 2008 DC in der (z.B. Windows 2000 oder Windows Server 2003) Domäne befindet oder es sich um eine reine Windows Server 2008 Umgebung handelt, besteht bereits der Container CN=ActiveDirectoryUpdate in der Domänenpartition. Der Wert im Attribut Revision wird dann von 3 auf 5 geändert. In den Umgebungen wo bereits ein Windows Server 2008 DC existiert, ist es auch nicht notwendig den Parameter /Gpprep auszuführen, da bereits die Berechtigungen der GPOs im Sysvol-Verzeichnis angepasst wurden. Das gilt aber nur für die Umgebungen, in denen bereits beim hinzufügen des zusätzlichen Windows Server 2008 DCs der Parameter /Gpprep mit angegeben wurde. In einer Windows Server 2008 Domäne ist der Parameter /Gpprep ohnehin nicht notwendig. Es ist aber nicht weiter tragisch wenn der Parameter doch mit angegeben werden sollte, denn der Assistent bringt lediglich den Hinweis, dass die Berechtigungen der GPOs bereits angepasst wurden.
Wenn der Einsatz eines Read-Only Domain Controllers (RODC) in irgendeiner Domäne der Gesamtstruktur geplant ist, dann ist das Adprep32 mit dem Parameter /Rodcprep lediglich einmalig aufzurufen. Der DC, auf dem dieser Befehl ausgeführt wird, muss auch nicht der Träger der FSMO-Rollen sein. Beim Ausführen dieses Befehls werden die einzelnen Infrastruktur-Master der Domänen kontaktiert, um die Berechtigungen (Security Descriptor, SD) der Domänen- sowie Anwendungsverzeichnispartitionen DomainDNSZones und ForestDNSZones zu aktualisieren.

Es reicht völlig aus, diesen Befehl erst vor dem Hinzufügen des ersten RODC`s in der Gesamtstruktur auszuführen. Das Benutzerkonto, mit dem dieser Befehl ausgeführt wird, muss Mitglied in der Sicherheitsgruppe Organisations-Admins sein. Nach Ausführung von /Rodcprep wird der folgende Container, der ebenfalls leer bleibt, erstellt:
CN=ActiveDirectoryRodcUpdate,CN=ForestUpdates,CN=Configuration,DC=<Root-Domäne>.

Das Attribut Revision in den Eigenschaften des Containers, erhält als Wert 2.

Hinweis für Windows Server 2008 Umgebungen: Existiert bereits ein Windows Server 2008 DC in der (z.B. Windows 2000 oder Windows Server 2003) Domäne oder handelt es sich um eine reine Windows Server 2008 Umgebung, so kann ein Windows Server 2008 R2 als RODC zur Domäne hinzugefügt werden. Es ist nicht unbedingt notwendig, dass bereits ein Windows Server 2008 R2 DC in der Domäne besteht um einen Windows 2008 R2 als RODC zur Domäne hinzuzufügen. Denn die Voraussetzungen um einen RODC zur Domäne hinzuzufügen sind schließlich, dass sich der Gesamtstrukturfunktionsmodus mindestens auf „Windows Server 2003“ befindet, sich bereits ein Windows Server 2008 DC in der Domäne befindet und das Adprep32 /Rodcprep ausgeführt wurde.

Read-Only Domain Controller (RODC)
Die Installation eines RODC
Wird eine neue Gesamtstruktur unter Windows Server 2008 R2 erstellt, so ist das Ausführen von Adprep/Adprep32 keineswegs notwendig. Weder der Parameter /Forestprep, noch /Domainprep /Gpprep oder /Rodcprep müssen angewendet werden.
Es wird bei jedem Ausführen von Adprep im Verzeichnis %Systemroot%\Debug\Adprep\Logs ein Ordner erstellt, dass als Namen das aktuelle Datum sowie die Uhrzeit erhält. Darin befindet sich (neben anderen) das Adprep-Protokoll mit dem Namen ADPrep.log, welches einen detaillierten Bericht zum Vorgang liefert. Wenn Adprep abbrechen oder einen Fehler melden sollte, ist dieses Protokoll bei der Fehlersuche hilfreich.

Debug Protokollierung
Nach der Domänenaktualisierung auf Windows Server 2008 R2, kann nun der neue Server als "zusätzlicher DC der bestehenden Domäne" hinzugefügt werden. Während dem Heraufstufen zum DC sollte an entsprechender Stelle, dass DNS mit installiert und zusätzlich der globale Katalog aktiviert werden. Anschließend sollten noch die FSMO-Rollen auf den Windows Server 2008 R2 DC verschoben werden.

Globaler Katalog (Global Catalog – GC)
Der PDC-Emulator
Die FSMO-Rollen verschieben

Szenario 1

Eine Domänenaktualisierung von Windows 2000 auf Windows Server 2008 R2 durchführen

In einer Windows 2000 Active Directory Umgebung kann die Domänenaktualisierung auf Windows Server 2008 R2 über einen zusätzlichen Windows Server 2008 R2 DC realisiert werden. Dazu ist zuerst die Schritt für Schritt-Anleitung die am Anfang dieses Artikels beschrieben ist durchzuführen. Anschließend kann ein Windows Server 2008 R2 als zusätzlicher Domänencontroller der bereits bestehenden Domäne hinzugefügt werden.
Es ist zuerst ein Inplace-Update von Windows 2000 auf Windows Server 2003 mit mindestens dem Service Pack 2 (besser aktueller) durchzuführen. Erst dann kann per Inplace-Update auf Windows Server 2008 R2 aktualisiert werden, natürlich auch erst nach Ausführung der Schritt für Schritt-Anleitung.

Szenario 2

Eine Domänenaktualisierung von Windows Server 2003 auf Windows Server 2008 R2 durchführen

Wie in einer Windows 2000 Gesamtstruktur sollte auch in einer Windows Server 2003 Gesamtstruktur die Domänenaktualisierung über einen zusätzlichen Windows Server 2008 R2 Domänencontroller erfolgen. Selbstverständlich auch nur dann, wenn die Schritt für Schritt-Anleitung durchgeführt wurde.
Ist mindestens das Service Pack 2 für den Windows Server 2003 auf dem DC installiert, so kann mit einem Inplace-Update der Windows Server 2003 DC auf Windows Server 2008 R2 aktualisiert werden. Die Schritt für Schritt-Anleitung die am Anfang dieses Artikels beschrieben wird, ist dabei zuerst durchzuführen.

Szenario 3

Eine Domänenaktualisierung von Windows Server 2003 R2 auf Windows Server 2008 R2 durchführen

Da in einem Windows Server 2003 R2 ein Windows Server 2003 mit mindestens dem Service Pack 2 enthalten ist, kann nach vorheriger Ausführung der Schritt für Schritt-Anleitung ein zusätzlicher Windows Server 2008 R2 DC zur bestehenden Domäne hinzugefügt werden.
Des Weiteren kann ein Windows Server 2003 R2 SP2 DC per Inplace-Update auf Windows Server 2008 R2 aktualisiert werden, wenn vorher die Schritt für Schritt-Anleitung durchgeführt wurde.

Szenario 4

Eine Domänenaktualisierung von Windows Server 2008 auf Windows Server 2008 R2 durchführen

Eine Domänenaktualisierung kann durch hinzufügen eines zusätzlichen Windows Server 2008 R2 DCs durchgeführt werden. Die Schritt für Schritt-Anleitung am Anfang des Artikels gilt es zuerst durchzuführen. Hier in Kurzform: Zuerst muss auf dem Schema-Master das Adprep32 /Forestprep und auf dem Infrastruktur-Master das Adprep32 /Domainprep ausgeführt werden.
Ein Windows Server 2008 DC kann auch per Inplace-Update auf Windows Server 2008 R2 aktualisiert werden. Vorher muss ebenfalls auf dem Schema-Master das Adprep32 /Forestprep und auf dem Infrastruktur-Master das Adprep32 /Domainprep durchgeführt werden.

Szenario 5

Eine Domänenaktualisierung von einem x64Bit Windows Server 2008 Core auf Windows Server 2008 R2 Core durchführen

Die Domänenaktualisierung kann hier ebenfalls durch hinzufügen eines zusätzlichen Windows Server 2008 R2 Core DCs erfolgen. Natürlich muss auch in diesem Fall vorher das ausführen von Adprep32 /Forestprep auf dem Schema-Master und das Adprep32 /Domainprep auf dem Infrastruktur-Master erfolgen.
Der x64Bit Windows Server 2008 Core DC lässt sich per Inplace-Update auf einen Windows Server 2008 R2 Core aktualisieren. Auch hier gilt es im ersten Schritt auf dem Schema-Master das Adprep /Forestprep und im zweiten, auf dem Infrastruktur-Master das Adprep /Domainprep auszuführen.

Szenario 6

Eine Windows Server 2008 R2-Subdomäne in einer Windows 2000/2003/2003 R2/2008 Gesamtstruktur erstellen

Soll in einer Gesamtstruktur die erste Windows Server 2008 R2-Domäne und somit der erste Windows Server 2008 R2-DC zur Gesamtstruktur hinzugefügt werden, so muss lediglich auf dem Schema-Master das Adprep /Forestprep ausgeführt werden. Anschließend kann mit dem Windows Server 2008 R2 die Subdomäne erstellt werden.

Befindet sich in einer Windows 2000 Umgebung die FSMO-Rolle des Domänennamenmasters auf einem Windows 2000 DC, wird das Attribut msDS-BehaviorVersion im entsprechenden crossRef-Objekt nicht aktualisiert, wenn eine Subdomäne bzw. eine neue Domänenstruktur (Tree) unter Windows Server 2008 oder Windows Server 2008 R2 erstellt wird. In diesem Fall kann es bei einigen Anwendungen zu Kompatibilitätsproblemen kommen. Insbesondere wenn mit DCDIAG die AD-Replikation überprüft werden soll, schlägt der Replikationstest fehl. Die Abhilfe dieses Problems ist, die Rolle des Domänennamenmasters entweder auf einen Windows Server 2003, Windows Server 2008 oder Windows Server 2008 R2 DC zu übertragen, bevor eine neue Subdomäne bzw. eine neue Domänenstruktur (Tree) erstellt wird. >> >

>>>>>>>
Weitere Informationen:
Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen
Migration von Windows Server 2000 auf Windows Server 2003 (Inplace-Update)
Schemaupdate beim Windows Server 2003 R2
Einen zusätzlichen DC in die Domäne hinzufügen
Die AD-Powershell im Windows Server 2008 R2
Das Active Directory Preparation Tool – ADPREP
Domänen- und Gesamtstrukturfunktionsmodus
Windows Server 2008 R2 Upgrade Paths
Upgrading Active Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Eine Domänenmigration durchführen

Yusuf Dikmenoglu — Sun, 21 Dec 2008 15:30:58 GMT

Die Unternehmen entwickeln sich und ihre Produkte weiter. Stetig müssen sich die Firmen an die Marktansprüche und an die Kundenwünsche anpassen, um ihr Business zu betreiben. So wie sich die Unternehmen an die Marktansprüche anpassen müssen, so muss sich auch die IT innerhalb eines Unternehmens anpassen, um den wirtschaftlichen Interessen des Unternehmens auch aus der IT-Sicht gerecht zu werden.

Die Firmen die bereits schon seit längerem eine Active Directory-Umgebung betreiben, denken vielleicht darüber nach ihre Gesamtstruktur zu verändern. Ihre schon in die Jahre gekommene Struktur spiegelt evtl. die heutigen Ansprüche des Unternehmens nicht wieder. Für die damalige Zeit war das gewählte Multidomänenmodell vielleicht notwendig und das richtige Domänenmodell. Aber heute ist das damals gewählte Domänendesign in die Jahre gekommen und genügt evtl. weder den heutigen Ansprüchen, noch ist es zeitgerecht.

Es kann viele Gründe dafür geben, warum eine Umstrukturierung der Gesamtstruktur sinnvoll wäre. Ein weiterer Grund für das Re-Design der Umgebung wäre z.B. der Domänenname. Eine Migration in eine neue Gesamtstruktur ist in vielen Umgebungen sinnvoller, als den Domänennamen zu ändern. Oder wenn Firmen fusionieren und die eine Firma in die andere migriert werden soll.

Ist erst mal die Entscheidung getroffen den Schritt einer Umstrukturierung zu gehen, sei es innerhalb einer Gesamtstruktur (Intra-Forest) oder in eine neue Gesamtstruktur zu migrieren (Inter-Forest, zwischen zwei Gesamtstrukturen), so gilt es als einer der nächsten Schritte das richtige Migrationswerkzeug zu wählen.

Auf der Suche im Internet nach einem Migrationstool stößt man recht schnell auf das kostenlose Werkzeug von Microsoft. Das Tool nennt sich Active Directory Migration Tool - ADMT. Aber neben dem ADMT stolpert man unter anderem über das kommerzielle Werkzeug aus dem Hause Quest. Der Quest Migration Manager for Active Directory (kurz QMMAD) ist das Pendant zu ADMT und kann einiges mehr als das wohlgemerkt kostenlose Tool von Microsoft. Aber neben Quest wäre noch das Migrationswerkzeug von NetIQ zu erwähnen (was hier jedoch nicht berücksichtigt wird).

Migrationsmöglichkeiten

Eine Domänenmigration kann auf verschiedene Wege mit verschiedenen Werkzeugen erfolgen. Viele Unternehmen nehmen eine Domänenmigration auch zum Anlass, ihre Daten neu zu organisieren. Denn durch die Jahre entstand auf manchen Fileservern evtl. diverser Daten-Wildwuchs, den es neu zu strukturieren gilt. Die Migration muss natürlich ohne größere Auswirkungen auf die produktiven Einheiten und möglichst unauffällig verlaufen.

1. Die Migration mit Hilfe von Skripten

Einige Unternehmen migrieren ihre Benutzer-, Gruppen- sowie Computerkonten mit ADMT in die neue Domäne. Die File- bzw. Ressourcenserver fügen sie händisch der Ziel-Domäne hinzu und führen anschließend das sogenannte Re-ACLing (=Rechte neu setzen) ihrer Netzwerkressourcen (Dateien, Drucker etc.), mit Skripten durch. Dabei kommt oft ein Computer-Startupskript zum Einsatz.

>

2. Die Migration mit der SIDHistory

Je nach Größe bzw. Dauer der Migration ist es evtl. notwendig, dass die bereits migrierten Benutzer noch auf die Ressourcen in der Quell-Domäne zugreifen können. Damit während der Migrationsphase die bereits migrierten Benutzer, sei es bei einer Intra- oder Inter-Forest Migration, weiterhin Zugriff auf die Ressourcen der alten Domäne haben, wäre einer der gängigsten Varianten die während einer Migration zum Einsatz kommen, die Migration mit der SIDHistory. Dadurch kann das neue Benutzerkonto aus der neuen Domäne, auf die Ressourcen der alten Domäne zugreifen. Das Attribut SIDHistory ist ein mehrwertiges Attribut in dem eine Liste der SIDs, die zuvor einem Benutzer oder einer Gruppe zugewiesen wurden, eingetragen wird.

Mit den entsprechenden Migrationswerkzeugen, wie z.B. den im weiteren Verlauf vorgestellten Tools, können die Benutzer- und Gruppenkonten mit ihrer SID migriert werden. Dabei wird ein neues Sicherheitsprinzipal (Benutzer- oder Gruppenkonto) in der neuen Domäne erstellt und die SID des alten Sicherheitsprinzipals an das neue Konto der neuen Domäne im Attribut SIDHistory hinzugefügt. Dadurch wäre das neue Benutzerkonto in der Lage, die alte SID als "Ausweis" vorzuzeigen, wenn die neue SID des Benutzerkontos keinen Zugriff bekommt. Möchte also das "neue" Benutzerkonto aus der neuen Domäne, auf die Ressourcen der "alten" Domäne zugreifen, tritt hier die SIDHistory in Aktion.

Wird ein Benutzer von einer Domäne in eine andere migriert, so wird seine SID nicht mit übernommen, denn der mittlere Part der SID ist die Nummer der Domäne. Bei der Benutzer-Migration mit den herkömmlichen Migrationswerkzeugen wird jedesmal ein neues Benutzerkonto mit einer neuen SID in der Ziel-Domäne eingerichtet. Da das neue Benutzerkonto eine neue SID bekommen hat, bekommt das Konto nicht die gleichen Berechtigungen wie es das alte Benutzerkonto hatte, auch wenn der Benutzername gleich lautet. Denn bekanntlich sind Namen in der IT "Schall und Rauch". Dank der SIDHistory aber, müssen die Berechtigungen in der alten Domäne nicht gleich angepasst werden, denn dadurch hat das neue Benutzerkonto Zugriff auf die Ressourcen der alten Domäne.

Die SIDHistory funktioniert sogar wenn die alte Domäne nicht mehr existiert! Wenn die Verbindung zur alten Domäne aufgelöst wurde (Domäne wurde entfernt oder die Verbindung ist getrennt), werden die Berechtigungseinträge auf den Ressourcen nicht mehr im Klartext als Namen angezeigt, sondern es erscheint die SID (S-1-5-21-…). Die Berechtigungen funktionieren aber wie bereits erwähnt weiterhin. Dafür erschwert sich aber die Administration, da man nicht mehr so einfach beurteilen kann, um welches Konto es sich dabei handelt. Wie denn auch, wenn niemand mehr weiß wie die Konten hießen.

Wenn die Migration abgeschlossen ist, wäre es ohnehin empfehlenswert die SIDHistory zu bereinigen. Nach dem bereinigen der SIDHistory kann der Benutzer lediglich mit der "neuen" SID auf die Ressourcen zugreifen. Die ACL-Umsetzung sollte natürlich zu diesem Zeitpunkt bereits abgeschlossen sein.

Denn wenn sich nämlich ein Benutzer anmeldet, bekommt er ein Access-Token in dem seine richtige SID, die SIDs der SIDHistory (samt der SIDHistory aller Gruppen) und die SID's aller Gruppen, denen der Benutzer angehört (direkt oder verschachtelt), enthalten ist. Das Access-Token kann aber max. 1024 Einträge enthalten und von daher, sollte nach einer Migration die SIDHistory stets bereinigt werden. Ansonsten könnte es bei zukünftigen Migrationen zu Problemen kommen. >

Zum entfernen der SIDHistory kann dazu das folgende VBSkript verwendet werden.
How To Use Visual Basic Script to Clear SidHistory

Leider ist die Handhabung mit dem Skript eher umständlich, denn die Objekte bei denen die SIDHistory entfernt werden soll, müssen einzeln angegeben werden. Aber mit etwas Skriptingkenntnisse lässt sich das Skript an die eigenen Bedürfnisse anpassen. Alternativ lässt sich die SIDHistory auch mit ADModify entfernen.

3. Die Migration mit Dual-ACL

Neben der Variante mit der SIDHistory, kommt als weitere gängige Migrationsvariante Dual-ACL häufig zum Einsatz. Auch hierbei können während der Migrationsphase die bereits migrierten Benutzer, sei es bei einer Intra- oder Inter-Forest Migration, weiterhin auf die Ressourcen der alten Domäne zugreifen. Dadurch kann das neue Benutzerkonto aus der neuen Domäne, auf die Ressourcen der alten Domäne zugreifen.

Die in diesem Artikel erwähnten Migrationstools können auch die vorhandenen Berechtigungen auf Clients oder Servern bearbeiten. Die bereits migrierten „neuen“ Benutzer- und Gruppenkonten können zusätzlich zu den vorhandenen Berechtigungen eingetragen werden (Dual ACL) oder die alten Berechtigungen auf den Ressourcen ersetzen. Mit ADMT kann das der Assistent zur Computermigration durchführen, während im QMMAD das Ressource Updating dafür zuständig ist.

Weitere hilfreiche Tools für die Migration

Je nachdem welche Migrationsstrategie und welches Migrationswerkzeug man gewählt hat, können im Nachhinein die Tools wie SUBINACL oder SIDWALK dabei helfen, die Berechtigungen zu bereinigen. Auch das ADModify kann bei Massenänderungen, die bei einer Migration notwendig sein könnten, hilfreich sein.>

Die SID-Filterung bei der Inter-Forest Migration

Die SID-Filterung ist dazu gedacht, die Benutzer an der Nutzung der im Attribut SIDHistory eingetragenen SIDs daran zu hindern, um auf Ressourcen einer separaten Gesamtstruktur zuzugreifen. Die SID-Filterung zu deaktivieren stellt aber ein gewisses Sicherheitsrisiko dar, denn ein Angreifer mit Administratorrechten könnte administrative SIDs in der vertrauenden Gesamtstruktur dem Attribut SIDHistory eines Sicherheitsprinzipals in der vertrauten Gesamtstruktur hinzufügen. Damit ist es dem Konto möglich, administrativen Zugriff auf die vertraute Gesamtstruktur zu erlangen.

Mit der SID-Filterung kann die Verwendung des Attributs SIDHistory in der gesamten Gesamtstrukturvertrauensstellung bzw. externen Vertrauensstellung blockiert werden. Wenn aber das neue Benutzerkonto auf die Ressourcen der alten Domäne zugreifen möchte, muss bei einer Inter-Forest Migration die SID-Filterung ausgeschaltet sein. Die SID-Filterung sollte aber nur für einen begrenzten Zeitraum deaktiviert werden.

Die SID-Filterung lässt sich mit NETDOM, welches sich in den Windows Support Tools befindet, deaktivieren. Der Befehl lautet wie folgt:
Netdom Trust TrustingDomainName /domain:TrustedDomainName /quarantine:No /userD:Domänen-Administrator /passwordD:Domänen-Admin-Kennwort

Disable SID filter quarantining

Es wäre auch möglich, die auf die Gesamtstrukturvertrauensstellung angewendete Standard-SID-Filterung mit der Option /enablesidhistory:yes abzuschwächen.
Der genaue Befehl lautet folgendermaßen:
Netdom Trust TrustingDomainName /domain:TrustedDomainName /enablesidhistory:Yes /usero:Domänenadministratorkonto /passwordo:Domänenadministratorkennwort

Was sind die Voraussetzungen für eine Migration mit ADMT oder dem QMMAD?

Natürlich muss zuerst auf IP-Ebene das Routing zwischen der Quell- und Ziel-Domäne funktionieren.
Als nächstes muss die Namensauflösung zwischen der Quell- und Ziel-Domäne sichergestellt sein. Dazu könnte man im DNS entweder eine sekundäre Zone der jeweils anderen Domäne einrichten oder ab Windows Server 2003 eine bedingte Weiterleitung einrichten. Neben der DNS-Namensauflösung könnte man zusätzlich noch die NetBIOS-Namensauflösung z.B. durch eine WINS-Replikation sicherstellen.
Idealerweise sollte eine (einseitige oder bidirektionale) Vertrauensstellung zwischen der Quell- sowie Ziel-Domäne existieren.
Die Ziel-Domäne muss sich sowohl bei einer Intra-Forest als auch Inter-Forest Migration im einheitlichen Modus befinden. Der Grund dafür ist, da das Attribut SIDHistory in Benutzer- sowie Gruppenkonten nur im einheitlichen Modus verfügbar ist. Nur wenn sich die Ziel-Domäne im Domänenfunktionsmodus „Windows 2000 pur“, „Windows Server 2003“ oder „Windows Server 2008“ befindet, kann die SIDHistory mit Werten gefüllt werden. Wobei eine Inter-Forest Migration auch ohne die SIDHistory stattfinden kann, jedoch stellt die SIDHistory eine Art doppelter Boden dar. Denn die Migration an sich ist kompliziert und aufwändig genug, wenn man da nicht an jede Berechtigung denkt erhöht sich der administrative Aufwand im nachhinein unnötig.

Die Migration mit dem Active Directory Migration Tool - ADMT

Das ADMT existiert in der Version 2.0, 3.0 sowie 3.1. Die Installation des ADMT v2.0 kann auf Windows 2000 Server oder Windows Server 2003 erfolgen. Wobei das ADMT v3.0 nur auf Windows Server 2003 und die ADMT v3.1 nur auf Windows Server 2008 (aber nicht auf einem RODC oder Server Core) installiert werden kann.

Während der Installation von ADMT wird auch die Microsoft SQL Server Desktop Engine (MSDE) mit installiert. Das Tool kann aber so konfiguriert werden, dass es entweder die MSDE oder einen bereits bestehenden SQL-Server verwendet. Das ADMT besteht aus einer Reihe von Assistenten, die für die Migration der Objekte verwendet werden können.

Nach der Installation steht das Tool als MMC unter Start-Programme-Verwaltung-Active Directory Migration Tool zur Verfügung.

Das Benutzerkonto mit dem das ADMT ausgeführt wird, sollte Administratorrechte in der Quell-sowie Ziel-Domäne haben. Es muss bei der Migration der Computerkonten ein Agent auf den Clients installiert werden und das funktioniert natürlich nur, wenn das Konto lokale Adminrechte hat.

Das ADMT kann für eine Intra-Forest (innerhalb der Gesamtstruktur) oder Inter-Forest (zwischen zwei Gesamtstrukturen) Migration eingesetzt werden. Das Werkzeug kann über die grafische Oberfläche oder als Kommandozeilentool eingesetzt werden. Es stellt auch eine Skriptingschnittstelle bereit.

Bevor es an die produktive Migration mit ADMT geht, gilt es unbedingt vorher das Whitepaper zum Tool zu lesen und idealerweise eine Testmigration in einer Testumgebung durchzuführen.

Active Directory Migration Tool v.2.0
Active Directory Migration Tool v3.0
ADMT v3 Migration Guide
Active Directory Migration Tool version 3.1
ADMT v3.1 Guide: Migrating and Restructuring Active Directory Domains
How to troubleshoot inter-forest sIDHistory migration with ADMTv2
You find that several custom attributes are missing when you use ADMT to migrate users between two forests

Quest Migration Manager for Active Directory - QMMAD

Der Hersteller wirbt mit den Worten Zero Impact für sein Werkzeug und in der Tat fallen einem je nach Migration die Vorteile recht fix ins Auge. Das Tool welches zur Zeit in der Version 8.3 zur Verfügung steht, lässt sich einfach bedienen und es fällt schnell auf das sich vieles bei einer Intra- oder Inter-Forest Migration im Hintergrund bereits migrieren lässt, ohne dass die Benutzer etwas davon merken. Egal welche Migration durchgeführt wird, die Arbeiten können weitestgehend und ohne große Auswirkungen auf die Benutzer, im laufenden Betrieb erfolgen.

Natürlich möchte Quest bei seinen Migrationswerkzeugen sicherstellen, dass ihre Werkzeuge nur von Fachleuten, am liebsten aber (verständlicherweise) von seinen eigenen Consultants oder qualifizierten Partnern eingesetzt wird. Letztenendes aber möchte Quest seine Software schließlich an den Kunden bringen. Daher kommt es auf das Gespräch mit Quest an. Quest verkauft seinen QMMAD auch ohne Dienstleistung, möchte vorher aber vom Kunden schriftlich bestätigt bekommen, dass dieser das Werkzeug ausgiebig getestet hat. Es ist auch möglich, mit dem Hersteller einen privaten interaktiven Webcast über das Werkzeug zu veranstalten.

Damit man das Tool einsetzen kann, wird ein Lizenzfile benötigt. Das Lizenzfile kostet pro zu migrierender Benutzer 13 Euro. Je nach Anzahl sind ca. 10% Rabatt möglich. Es zählen nur die zu migrierenden Benutzerkonten. Gruppen- bzw. Computerkonten sind davon nicht betroffen. Nach einer Registrierung auf der Quest-Webseite kann man sich ein Test-Lizenzfile (begrenzt für einen bestimmten Zeitraum und für eine begrenzte Anzahl an Benutzer) zumailen lassen.

Der QMMAD setzt eine Active Directory Application Mode (ADAM)-Instanz und den IIS für ausführlichere Statistiken voraus. Bei der Standardinstallation wird ADAM gleich mit installiert und konfiguriert. Wird bei der Installation des QMMAD die benutzerdefinierte Variante gewählt, so kann eine bereits bestehende und vorbereitete ADAM-Instanz angegeben werden.

Das Quest-Tool kann sowohl bei einer Intra- als auch Inter-Forest Migration eingesetzt werden. Im Gegensatz zu ADMT kann dieses Werkzeug weitaus mehr Objekte migrieren und ist in der Anwendung komfortabler. Die ohnehin stressige Migration wird dadurch für den Administrator effizienter und flexibler. Bei den einzelnen Migrationsphasen kann ein entsprechendes Benutzerkonto das die benötigten Rechte für die jeweils auszuführende Aufgabe besitzt hinterlegt werden.
>

Active Directory Migration managed with Active Directory Migration Tools from Quest Software

ADMT vs. QMMAD

Funktion	ADMT	QMMAD	Bemerkung
Intra- und Inter-Forest Migration	Bei einer Intra-Forest Migration werden die Objekte aus der Quell-Domäne entfernt. Das Objekt existiert nach der Migration nur noch in der Ziel- und nicht zusätzlich in der Quell-Domäne. Bei der Inter-Forest Migration bleiben die Objekte hingegen weiterhin in der Quell-Domäne bestehen, die deaktiviert werden können.	Die Objekte bleiben sowohl bei einer Intra-als auch bei einer Inter-Forest Migration in der Quell-Domäne bestehen. Die Quell-Objekte können hier bei der Intra- sowie Inter-Forest Migration deaktiviert werden.	Bei der Migration mit dem QMMAD ist man flexibler und kann vieles im Hintergrund bereits durchführen.
Migration von Benutzer- und Gruppenkonten	Ist bei einer Intra- sowie Inter-Forest Migration möglich.	Das Quest-Tool kann ebenfalls beide Arten von Konten bei der Intra- als auch Inter-Forest Migration migrieren.	Die Migration von Benutzer- und Gruppenkonten gehört bei beiden Tools zu den grundlegendsten Funktionen.
Gesperrte Benutzerkonten migrieren	Der Zustand eines gesperrten Benutzerkontos wird mit ADMT mit migriert.	Nach der Migration eines gesperrten Benutzerkontos mit dem QMMAD ist das Konto anschließend nicht mehr gesperrt.	Hierbei hat der QMMAD einen klaren Nachteil.
SIDHistory	Bei der Intra-Forest Migration ist die SIDHistory erforderlich und wird automatisch übernommen. Die SIDHistory ist bei der Inter-Forest Migration optional.	Auch der QMMAD kann bei einer Intra- und Inter-Forest Migration mit der SIDHistory migrieren.	Auch diese Funktion gehört zu den grundlegendsten Funktionen beider Tools.
Entfernen der SIDHistory	Das ADMT kann die SIDHistory von den Objekten nicht entfernen.	Mit dem QMMAD kann recht einfach die SIDHistory von den Objekten entfernt werden.	Mit dem QMMAD kann mit wenigen Mausklicks die SIDHistory von den Objekten entfernt werden (durch einen extra Durchlauf).
Das lösen von Konflikten	Mit ADMT ist die Konfliktlösung abhängig ob Intra- oder Inter-Forest Migration sehr beschränkt.	Der QMMAD kann Konflikte z.B. durch hinzufügen eines Präfix lösen.	Bei der Konfliktlösung (z.B. doppelter sAMAccountName) löst der QMMAD gegenüber dem ADMT einen Konflikt eleganter durch hinzufügen eines Präfix.
Migration von Computerkonten	Die Migration von Computerkonten ist bei der Intra- und Inter-Forest Migration möglich.	Auch der QMMAD kann Computerkonten bei einer Intra- und Inter-Forest Migration migrieren.	Auch die Migration von Computerkonten ist bei beiden Tools eines der grundlegendsten Funktionen. Beide Tools können Clients und Mitgliedsserver migrieren, aber KEINE DCs. DCs müssen aus der alten Domäne herunter- und in der neuen Domäne heraufgestuft werden.
Migration der OU Hierarchie	Das ADMT kann die OU Hierarchie aus der Quell-Domäne nicht migrieren. Die OUs müssen in der Ziel-Domäne manuell erstellt werden. Delegierungen müssten neu eingerichtet werden.	Das Quest-Tool kann die OU Hierarchie, optional sogar mit dem Security Descriptor (sprich den Delegierungen), mit migrieren.	Der QMMAD kann an dieser Stelle mehr als das ADMT.
Verändern von Objekteigenschaften während der Migration	ADMT kann während der Migration keine zusätzlichen Daten zu den Objekten einbinden.	Der QMMAD kann während der Migration zusätzliche Daten zu den Objekten einbinden.	Mit dem QMMAD könnten während der Migration zusätzliche Informationen z.B. in die Benutzerkonten eingepflegt werden.
Migration der Active Directory Standort-Topologie	AD-Standorte können mit dem ADMT nicht migriert werden.	Mit dem QMMAD können AD-Standorte, Subnetze sowie Standortverknüpfungen migriert werden.	Auch hier können mit dem Quest Werkzeug mehrere Objekte migriert werden.
Migration der Benutzerkennwörter	Die Kennwörter bleiben automatisch bei der Intra-Forest Migration erhalten, jedoch wird der Benutzer bei der ersten Anmeldung in der neuen Domäne aufgefordert, sein Kennwort zu ändern. Oder das Kennwort wird mit dem Password Export Server (PES) ebenfalls migriert, dann bleibt das alte Kennwort erhalten. Bei einer Inter-Forest Migration können die Kennwörter mit dem Password Export Server optional migriert werden.	Die Benutzerkennwörter können mit dem QMMAD bei einer Intra- oder Inter-Forest Migration einfach migriert werden.	Die Migration der Benutzerkennwörter lässt sich mit dem QMMAD einfacher als mit dem ADMT bzw. PES durchführen.
Benutzerprofile	Die Benutzerprofile bleiben erhalten.	Die Profile der Benutzer bleiben auch hier ebenfalls erhalten.	Die Profile werden bei der Migration der Clients übernommen.
Komfortable Auswahl der Objekte	Mit ADMT ist die Auswahl der Objekte eher eingeschränkt.	Der QMMAD bietet starke Filtermöglichkeiten um die entsprechenden Objekte auszuwählen.	Auch hier spielt das Quest-Werkzeug seine Stärken aus.
Statistiken über Fortschritt	Keine.	Der QMMAD bringt ein Statistikportal mit.	Mit dem QMMAD werden detaillierte Informationen über das Statistikportal geliefert.
Undo Funktion	Das ADMT kann nur den letzten Directory-Lauf rückgängig machen (Migration von AD-Objekten), aber nicht das Ressource Updating (RE-ACLing).	Das Quest-Tool bietet komplette Undo-Funktionen. Jede Aktion kann rückgängig gemacht werden.	Auch hierbei ist das Quest Werkzeug umfangreicher.
Kontinuierliche Synchronisation	Ist mit ADMT so nicht möglich. Höchstens aufwändig und eher umständlich mit Skripten und der ADMT-Skriptingschnittstelle.	Mit dem QMMAD kann eine Synchronisation zwischen dem alten und neuen Objekt eingerichtet werden. Somit kann bei einer lang andauernden Migration ein Abgleich zwischen dem alten und neuen Objekt stattfinden.	Gerade bei längeren Migrationsphasen ist die kontinuierliche automatische Echtzeitsynchronisation bei längeren Koexistenzphasen sehr wichtig.
Konsolidiertes Ressourcen Updating	Nicht möglich.	Ist mit dem QMMAD möglich.	Beim zusammenfügen von mehreren Quell-Domänen benötigt der QMMAD nur einen Durchlauf, während das ADMT pro Domäne einen Durchlauf benötigt.
Client Update	Eingeschränkt.	Der QMMAD aktualisiert sogar die geplanten Tasks und Zertifikate auf dem Client. Zusätzlich wird die default Domäne für die Anmeldung umgestellt (im Anmeldefenster das Feld „Anmelden an“).	Ein weiterer Vorteil bei dem Quest Werkzeug.
Mitgliedsserver Aktualisierung	Das ADMT kann das Ressource Updating für Exchange 5.5 durchführen.	Der QMMAD kann die Berechtigungen von den folgenden Applikationen anpassen: Exchange 5.5/2000/2003. IIS. SQL 6.5/7.0/2000. SMS 2.3/2003. System Center 2007. NAS/SAN. Sharepoint 2003 und 2007.	Das Quest-Tool kann die Berechtigungen von mehreren Applikationen anpassen.
Test-Migration	Seit ADMT 3.0 ist die Testmigration nicht mehr möglich.	Mit dem QMMAD kann man die Migrationseinstellungen vor der produktiven Migration in einem Testlauf testen.	Mit der Testmigration können Konfigurationsfehler aufgedeckt werden. Dies erleichtert die Fehlersuche.
Auswahl von Objekten	Das ADMT bietet einen Standard Dialogfenster, in dem die Benutzer und Gruppen als flache Liste angezeigt werden. Die Filterung nach deaktivierten, abgelaufenen oder Systemkonten ist nicht möglich.	Der QMMAD bietet erweiterte Filtermöglichkeiten bei der Auswahl der Objekte. Z.B. können deaktivierte und/oder abgelaufene Benutzerkonten von vornherein ausgeblendet werden.	Gerade in größeren Umgebungen gestaltet sich die Auswahl der zu migrierenden Objekte einfacher als mit ADMT.
Berechtigungen anpassen	Das ADMT kann die folgenden Berechtigungen anpassen: NTFS-Berechtigungen, Freigabeberechtigungen, Drucker, Registry, Profile.	Der QMMAD kann folgende Berechtigungen anpassen: Lokale Gruppenmitgliedschaften, Benutzer Berechtigungen, Dienste, Geplante Tasks, Registry, lokale und servergespeicherte Profile, Freigaben, Drucker, NTFS-Berechtigungen, DCOM, COM+	Die nötigsten Berechtigungen können beide Werkzeuge anpassen, wobei der QMMAD einiges mehr anpassen kann.
Migration von Vertrauensstellungen	Nicht möglich.	Ist möglich.	Ein weiteres nettes Feature des QMMAD.
Fehler Analyse während der Migration	Mit ADMT kann nach der Migration manuell ein Bericht über Konflikte erstellt werden.	Der QMMAD gibt einen detaillierten Bericht über fehlgeschlagene Objekte, Verzeichnis Fehler, Konflikte, nicht aufgelöst Objekte (z.B. Gruppenmitglieder) sowie abgeschlossene Migrationen und Synchronisationen.	Der detaillierte Bericht beim QMMAD erleichtert im Fehlerfall dem Administrator die Fehlersuche.

Fazit
>
Mit dem ADMT lässt sich jede Umgebung, egal wie groß sie ist, sowohl bei einer Intra- als auch Inter-Forest Migration über jeden Zeitraum migrieren. Die einzelnen Migrationsschritte mit ADMT müssen insbesonders bei der Intra-Forest Migration genauer geplant werden. Zwar hat das ADMT gegenüber dem Quest-Werkzeug klar seine Einschränkungen, jedoch ist dafür das ADMT kostenlos! Die Restarbeiten können mit etwas Handarbeit (oder mit Skripten) durchgeführt werden.

Das Quest-Werkzeug bietet gerade in seinem Umfang mehr Vorteile als das ADMT. Es kann weitaus mehr Objekte migrieren als das ADMT und man kann vieles im laufenden Betrieb migrieren, ohne das die Benutzer etwas davon merken. Auch bei länger andauernden Migrationen spielt der QMMAD dank seiner Synchronisation seine Stärken aus. Des Weiteren kann dieses Werkzeug die Berechtigungen von mehreren Applikationen anpassen.

Weitere Informationen:
Microsoft Online Migration Toolkit
NetIQ Migration Suite
>>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Einen Domänensplitt durchführen

Yusuf Dikmenoglu — Sun, 31 Aug 2008 22:29:46 GMT

In der heutigen Zeit ist es üblich das Firmen fusionieren, übernommen werden, komplett oder bloß ein Firmenteil verkauft
bzw. selbstständig wird. Wenn Firmen fusionieren ist es meistens erforderlich, eine Verbindung zwischen den Strukturen herzustellen.
Das kann eine Vertrauensstellung oder aber auch eine Migration bedeuten, je nachdem welche Anforderungen erfüllt werden müssen.
Soll sich aber ein Firmenteil eigenständig machen, steht dem Administrator eine Migration bevor. Oder etwa doch nicht?

Der gestresste Administrator der ohnehin mit seinen täglichen Aufgaben mehr als genug zu tun hat, möchte sich die Arbeit
der Firmenteilung gering halten. Er stellt sich dabei vor, weitere DCs in der Root-Domäne der Muttergesellschaft zu installieren
und die AD/DNS-Replikation abzuwarten. Anschließend stellt er diese DCs in einem isolierten Netzwerk, das keine Verbindung
zur Gesamtstruktur der Muttergesellschaft hat an ihren Zielort auf. Die überflüssigen AD-Objekte (Benutzer- und Computerkonten,
OUs, AD-Standorte, DC-Objekte, Sub-Domänen etc.) werden auf den verschobenen DCs entfernt. Ebenso werden auf den DCs
der Muttergesellschaft die verschobenen Objekte entfernt.

Weitere Details werden an dieser Stelle mit Absicht nicht genannt!

Wenn die DCs an ihrem Zielort stehen hat man als Ergebnis nun zwei völlig unabhängige Gesamtstrukturen,
was sogar mit dem minimalsten Aufwand erreicht wurde, nicht wahr? Weiterhin denkt sich der scheinbar clevere Administrator,
dass dieser Domänensplitt keine Sicherheitsrisiken für beide Gesamtstrukturen mit sich bringt.

Das nach dem Splitt beide Gesamtstrukturen den gleichen internen NetBIOS- sowie DNS-Domänennamen haben stört
den Administrator nicht, da es sich schließlich um interne Domänennamen handelt. Diese können bekanntermaßen auch
mühevoll unter Windows Server 2003/2008 geändert werden. Aber ob dies am Ende vollständig von Erfolg gekrönt ist,
steht auf einem anderen Blatt.

Außerdem ist der ganz schlaue Administrator der Meinung, dass solch ein Domänensplitt auch einen Vorteil hätte.
Denn falls das unternehmerische Vorhaben der Firmenteilung scheitern und beide Firmenteile sich erneut zusammenschließen würden,
könnte er einfach die verschobenen DCs zurück zur Domäne der Muttergesellschaft stecken. Nur was würde das bringen,
wenn auf beiden Seiten die DC-Objekte der jeweils anderen Seite gelöscht wurden.

Kommen wir zu dem Punkt des Sicherheitsfaktors.
Unterliegen nach einem Domänensplitt beide Gesamtstrukturen wirklich keinem Sicherheitsrisiko?
Die Antwort lautet: In beiden Gesamtstrukturen wäre die Sicherheit so löchrig wie ein Schweizer Käse!

Wird eine Root-Domäne geteilt, sind in beiden Firmenteilen unter anderem die folgenden Punkte identisch:

Beide Seiten enthalten das vordefinierte Administratorkonto mit dem gleichen Kennwort.

Alle vordefinierten Sicherheitsgruppen, in erster Linie die Sicherheitsgruppe Organisations-Admins wären auf beiden Seiten identisch.>
Auf beiden Seiten ist die Domäne als Root-Domäne deklariert, mit derselben SID.

Durch den globalen Katalog existieren auch auf den verschobenen DCs alle Objekte aus der Gesamtstruktur der Muttergesellschaft.
>

Diese Situation stellt für beide Seiten ein echtes Sicherheitsrisiko dar.
In den richtigen Händen ist keines der Domänen vor einer Kompromittierung sicher.

Weitere Risiken wären:

Auf den verschobenen DCs wären ebenfalls die Tombstones der Muttergesellschaft enthalten
die wiederbelebt werden könnten. Tombstones sind bereits gelöschte Objekte die aber noch in der AD-Datenbank existieren,
solange noch nicht die Tombstone Lifetime abgelaufen ist.

Wenn Applikationen in der Muttergesellschaft eingesetzt werden die sensible Informationen im Active Directory speichern,
wandern diese Daten ebenfalls auf den verschobenen DCs mit.

Sind Applikationen vorhanden die sich ins Active Directory verankern (wie z.B. Exchange), wandern diese Informationen ebenfalls mit.
>

Daher kann ich nur an jeden appellieren, auch wenn der Kunde König ist:

Finger weg von einem Domänensplitt!

Diese Art der Migration wird seitens Microsoft nicht supportet!
Wer einen Domänensplitt durchführt, der sollte sich ernsthaft überlegen ob er den richtigen Job ausübt.

Findet eine Firmenteilung statt, ist stets eine Migration durchzuführen.
Nur eine Migration wird seitens Microsoft unterstützt und ist auch reichlich sowie ausführlich auf den Microsoft-Seiten dokumentiert.
Eine Migration durchzuführen benötigt Zeit, Know-How und kann mehr oder weniger je nach Größe der Umgebung kompliziert sein.
Doch trotzdem rechtfertigt dies nicht einen Domänensplitt durchzuführen. Wer einer Migration nicht gewachsen ist,
der sollte sich statt einen Domänensplitt durchzuführen, besser einen erfahrenen Dienstleister zur Seite holen.

Ein Tool welches bei einer Migration nie fehlen darf, ist das Active Directory Migration Tool - ADMT.

>>>>
Weitere Informationen:
Eine Domänenmigration durchführen
ADMT Version 3.1
Forest Recovery

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

ADMT Version 3.1

Yusuf Dikmenoglu — Thu, 10 Jul 2008 11:24:21 GMT

Nun da seit einigen Monaten der Windows Server 2008 gelaunched wurde, ist auch seit gestern (09.07.2008) die neue ADMT Version 3.1 verfügbar,
das jetzt auch den Windows Server 2008 unterstützt. Wer einmal eine Migration mit dem „Active Directory Migration Tool“ durchgeführt hat,
weiß dieses Tool zu schätzen. Damit ist es möglich, Benutzer-, Computer- sowie Gruppenkonten von einer Domäne in eine andere Domäne
zu migrieren. Die Profileinstellungen der Benutzer bleiben alle samt erhalten. Der Benutzer selbst merkt von dieser Migration nichts.

Allerdings wird Windows NT standardmäßig nicht mehr unterstützt!

Jedoch gibt es auf der Download-Seite von ADMT v3.1 den folgenden Hinweis:

To obtain customer support if you are performing migration operations involving NT 4.0 source domains or NT 4.0 domain controllers
(with SP4 or higher), please contact your Microsoft Services representative or visit http://www.microsoft.com/microsoftservices.

Hier der Download:

Download details: ADMT v3.1

Hier das Whitepaper zu dem Tool:
Download details: Migrating and Restructuring Active Directory Domains Using ADMT v3.1

>
Weitere Informationen:
Benutzermigration mit ADMT v3: How-To
> >>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen

Yusuf Dikmenoglu — Sun, 13 Jan 2008 13:23:21 GMT

Der Windows Server 2008 bringt einige Verbesserungen bzw. Funktionen mit, die aber erst im Domänenfunktionsmodus
Windows Server 2008 zur Verfügung stehen. Damit z.B. mehrere Kennwortrichtlinien (Password Settings Objects)
in einer Domäne eingesetzt werden können, muss sich der Domänenfunktionsmodus auf Windows Server 2008 befinden.
Oder die Replikation des Sysvol-Verzeichnisses über die Distributed File System Replikation (DFS-R), ist ebenfalls nur im
Domänenfunktionsmodus Windows Server 2008 möglich.

Damit diese (und weitere) Funktionen genutzt werden können, muss zuerst eine Domänenaktualisierung der bestehenden
Gesamtstruktur auf Windows Server 2008 erfolgen.

Was ist möglich?

In einer Windows 2000 Gesamtstruktur kann ein Windows Server 2008 als zusätzlicher Domänencontroller (DC)
zu einer bestehenden Domäne hinzugefügt werden.

In einer Windows Server 2003/R2 oder SBS 2003 SP1/R2 Gesamtstruktur kann ein Windows Server 2008
als zusätzlicher Domänencontroller zu einer bestehenden Domäne hinzugefügt werden.

Ein Windows Server 2003 mit mindestens dem Service Pack 1 oder Windows Server 2003 R2 Domänencontroller,
kann per Inplace-Update auf Windows Server 2008 aktualisiert werden.

Was ist nicht möglich?

Ein Inplace-Update von Windows NT auf Windows Server 2008 ist nicht möglich.

Ein Inplace-Update von Windows 2000 auf Windows Server 2008 ist nicht möglich.

Ein Inplace-Update von einem Windows Server 2003/R2 Domänencontroller (oder Mitgliedsserver) worauf der
Exchange Server 2007 ohne/mit SP1 installiert ist, kann auf Windows Server 2008 nicht durchgeführt werden.

Ein installierter Exchange-Server auf einem DC ist nur ein Beispiel. Es muss vor einem Inplace-Update geprüft werden,
ob die installierten Applikationen auf dem DC, unter Windows Server 2008 noch funktionieren.

Ein Inplace-Update von früheren Server Betriebssystemen, ist auf den Windows Server 2008 Core nicht möglich.

Windows Server 2008 Core

Ein Cross-Update von einem x86 auf x64 System wird nicht supportet.

Ein Cross-Update auf eine andere Betriebssystem-Sprache wird nicht unterstützt. Als Beispiel, auf einem deutschen
Windows Server 2003 DC wird die englische Windows Server 2008 DVD eingelegt um den DC, auf einen
englischen Windows Server 2008 DC zu aktualisieren.

Voraussetzungen für eine Windows 2000/2003/R2 Gesamtstruktur, damit der erste
Windows Server 2008 DC hinzugefügt werden kann

Die Domäne in der man den Windows Server 2008 DC hinzufügen möchte, muss sich im einheitlichen Domänenfunktionsmodus
(entweder Windows 2000 pur oder Windows Server 2003) befinden. Dabei spielt es keine Rolle, auf welchem Modus sich der
Gesamtstrukturfunktionsmodus befindet.

Ist jedoch der Einsatz eines RODCs in der Gesamtstruktur geplant, so ist das erst ab der Gesamtstrukturfunktionsebene
Windows Server 2003 möglich. Des Weiteren muss sich bereits ein Windows Server 2008 DC in der Domäne befinden,
in der man den RODC hinzufügen möchte!

Alle Domänencontroller in der Gesamtstruktur sollten sich mindestens auf Windows 2000 Server mit Service Pack 4 befinden.

Step-by-Step Anleitung für eine Windows 2000/2003/R2 Gesamtstruktur, damit der erste
Windows Server 2008 DC hinzugefügt werden kann

Im ersten Schritt muss das Active Directory Preparation-Tool ADPREP, das auf der Windows Server 2008 DVD im Verzeichnis
"<DVD-Laufwerk>:\Sources\Adprep" mitgeliefert wird, mit dem Parameter /Forestprep auf dem Windows 2000 Server bzw.
Windows Server 2003 Schema-Master ausgeführt werden. Dadurch wird die Gesamtstruktur auf Windows Server 2008 aktualisiert.
Der Parameter /Forestprep wird nur ein einziges Mal in der Gesamtstruktur ausgeführt. Das Benutzerkonto mit dem das
Adprep /Forestprep ausgeführt wird, muss Mitglied der folgenden drei Sicherheitsgruppen sein:

- Organisations-Admins
- Schema-Admins
- Domänen-Admins in der Domäne, in der der Schema-Master Mitglied ist
Ruft man das Adprep /Forestprepnicht auf dem Schema-Master auf, bringt das Tool den Hinweis, dass die
Gesamtstrukturaktualisierung nur auf dem Schema-Master durchgeführt werden kann und bricht den Vorgang ab.
Es ist nun auch möglich, dass ADPREP von der 64Bit DVD des Windows Server 2008 auf einem
32Bit Windows Server 2003 DC auszuführen!

Microsoft empfiehlt das Verzeichnis <DVD-Laufwerk>:\Sources\Adprep vorher auf den Server zu kopieren, um z.B. Lesefehler
des DVD-Laufwerks während der Ausführung von Adprep zu vermeiden.

An error occurs when you run the ADPREP/FORESTPREP command on a Windows Server 2003-based or Windows Server 2008-based computer: "An attribute with the same link identifier already exists"

Mit Ausführen von Adprep /Forestprep wird die Gesamtstruktur auf Windows Server 2008 vorbereitet,
in dem neue Attribute sowie Klassen dem Schema hinzugefügt werden. Nach dem Aufruf von Adprep /Forestprep werden
abhängig von der Schema-Version die LDF-Dateien, die zur Schema-Aktualisierung benötigt werden, aus dem Verzeichnis
\Sources\Adprep in das Verzeichnis %windir%\system32 kopiert.

In einer Windows 2000 Gesamtstruktur werden die LDF-Dateien ab sch14.ldf, in einer Windows Server 2003
ab sch31.ldf und in einer Windows Server 2003 R2 Umgebung ab sch32.ldf bis zur sch44.ldf in das Schema importiert.
Das Schema wird somit auf die Version 44 aktualisiert.

Die Schema-Versionen wären (in Dezimal):

- Schema-Version 13 = Windows 2000 (ohne/mit allen SPs)
- Schema-Version 30 = Windows Server 2003 ohne/mit SP1/SP2 (und höhere SPs)
- Schema-Version 31 = Windows Server 2003 R2 ohne/mit SP2 (und höhere SPs)
- Schema-Version 44 = Windows Server 2008
- Schema-Version 47 = Windows Server 2008 R2

Die Schema-Version kann man sich auf jedem DC in der Gesamtstruktur zum einen in der Registry im Pfad:
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\<Schema Version>

… und zum anderen in dem Attribut objectVersion (z.B. mit ADSIEdit.msc oder LDP.exe), das sich in den
Eigenschaften der Schema-Partition CN=Schema,CN=Configuration,DC=<Domäne>,DC=<TLD> befindet, anzeigen lassen.

Auch mit Dsquery lässt sich die Schema-Version abfragen. Der Befehl lautet wie folgt:
dsquery * CN=Schema,CN=Configuration,DC=Root-Domäne -Scope Base -attr objectVersion

>

Wenn das Adprep /Forestprep durchgeführt wurde, wird in der Konfigurationspartition das Objekt
CN=ActiveDirectoryUpdate,CN=ForestUpdates,CN=Configuration,DC=<ForestRootDomäne> erstellt.

Dabei erhält das Attribut Revision im Objekt CN=ActiveDirectoryUpdate den Wert 2. Danach sollte sichergestellt werden,
dass sich dieses Objekt zuerst auf alle DCs der Gesamtstruktur repliziert, um dann den nächsten Schritt mit Adprep durchzuführen.
In erster Linie sollten die DC`s der einzelnen Domänen die Aktualisierung empfangen haben,
die die FSMO-Rolle des Infrastruktur-Master innehaben. Dazu gilt es den nächsten Punkt zu beachten.

Achtung: Wenn man das ADPREP /FORESTPREP auf dem Schema-Master ausführt und anschließend einfach nichts passiert,
also weder die Schemaerweiterung durchgeführt, noch eine Fehlermeldung angezeigt wird, so liegt mit hoher Wahrscheinlichkeit
ein "Sprach-Problem" vor. Wenn z.B. der Schema-Master auf einem englischen Betriebssystem läuft und man führt das ADPREP /FORESTPREP
von einer deutschen Windows Server 2008 DVD aus, so kommt es genau zu diesem Verhalten. Es ist zwingend notwendig auf einem
deutschen System, dass ADPREP von einer deutschen Windows Server 2008 DVD auszuführen.

Im zweiten Schritt muss das Adprep mit den Parametern „/Domainprep /Gpprep“ auf dem Infrastruktur-Master in der Domäne,
in der man den Windows Server 2008 als DC hinzufügen möchte, ausführen. Das Benutzerkonto, mit dem dieser Befehl ausgeführt wird,
muss Mitglied der Sicherheitsgruppe Domänen-Admins sein. Mit Ausführen von „/Domainprep /Gpprep“ wird die Domäne auf
Windows Server 2008 aktualisiert. Der Parameter /Domainprep bewirkt, dass neue Objekte erstellt sowie die ACLs an diversen
Objekten in der Domänenpartition geändert werden. Der Parameter /Gpprep sorgt dafür, dass die Berechtigungen der
Gruppenrichtlinienobjekte die sich im Sysvol-Verzeichnis befinden, angepasst werden.

Führt man diesen Befehl aus, noch bevor die Gesamtstrukturaktualisierung auf den Infrastruktur-Master repliziert wurde,
bricht der Vorgang ab. Dieser bricht auch dann ab, wenn der Befehl nicht auf dem Infrastruktur-Master ausgeführt wird.
Durch Ausführen dieses Befehls wird das folgende Objekt erstellt:
CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System,DC=<Domäne>

Das Attribut Revision im Objekt CN=ActiveDirectoryUpdate bekommt dabei den Wert 3.
Es ist möglich zuerst das Adprep lediglich mit dem Parameter /Domainprep auszuführen und zu einem späteren Zeitpunkt
die Berechtigungen der GPOs, mit Adprep /Domainprep /Gpprep zu aktualisieren. Empfehlenswert ist es aber,
dass in einem Schritt durchzuführen.

Wenn der Einsatz eines Read-Only Domain Controllers in irgendeiner Domäne der Gesamtstruktur geplant ist,
dann ist das Adprep mit dem Parameter /Rodcprep lediglich einmalig aufzurufen. Der DC, auf dem dieser Befehl
ausgeführt wird, muss auch nicht der Träger der FSMO-Rollen sein. Beim Ausführen dieses Befehls werden die einzelnen
Infrastruktur-Master der Domänen kontaktiert, um die Berechtigungen (Security Descriptor, SD) der Domänen- sowie
Anwendungsverzeichnispartitionen DomainDNSZones und ForestDNSZones zu aktualisieren.

Error message when you run the "Adprep /rodcprep" command in Windows Server 2008: "Adprep could not contact a replica for partition DC=DomainDnsZones,DC=Contoso,DC=com"

Es reicht völlig aus, diesen Befehl erst vor dem Hinzufügen des ersten RODC`s in der Gesamtstruktur auszuführen.
Das Benutzerkonto, mit dem dieser Befehl ausgeführt wird, muss Mitglied in der Sicherheitsgruppe Organisations-Admins sein.
Nach Ausführung von /Rodcprep wird das folgende Objekt erstellt:
CN=ActiveDirectoryRodcUpdate,CN=ForestUpdates,CN=Configuration,DC=<ForestRootDomäne>.

Das Attribut Revision erhält dabei den Wert 2.

Read-Only Domain Controller (RODC)

Wenn eine Gesamtstruktur mit Windows Server 2008 erstellt wird, ist das Ausführen von Adprep in keinster Weise notwendig.
Weder der Parameter /Forestprep, noch „/Domainprep /Gpprep“ oder /Rodcprep müssen angewendet werden.

Es wird bei jedem Ausführen von Adprep im Verzeichnis %Systemroot%\Debug\Adprep\Logs ein Ordner erstellt,
dass als Namen das aktuelle Datum sowie die Uhrzeit erhält. Darin befindet sich das Adprep-Protokoll mit dem Namen ADPrep.log,
welches einen detaillierten Bericht zum Vorgang liefert. Wenn Adprep abbrechen oder einen Fehler melden sollte,
ist dieses Protokoll bei der Fehlersuche hilfreich.

Nach der Domänenaktualisierung auf Windows Server 2008, kann nun der neue Server als "zusätzlicher DC der bestehenden Domäne"
hinzugefügt werden. Während dem Heraufstufen zum DC sollte an entsprechender Stelle, dass DNS mit installiert und zusätzlich
der globale Katalog aktiviert werden. Anschließend sollten noch die FSMO-Rollen auf den Windows Server 2008 DC verschoben werden.

Globaler Katalog (Global Catalog - GC)
Der PDC-Emulator

>

Szenario 1

Migrations-Möglichkeiten von Windows NT auf Windows Server 2008

Es muss zuerst ein Inplace-Update vom Windows NT-PDC auf Windows Server 2003 mit mindestens dem Service Pack 1
durchgeführt werden. Erst dann kann per Inplace-Update auf Windows Server 2008 aktualisiert werden.
Das Update könnte mit einer VM durchgeführt werden.

Statt des Inplace-Updates von Windows Server 2003 auf Windows Server 2008, kann natürlich auch ein
zusätzlicher Windows Server 2008 hinzugefügt werden.

Im ersten Schritt kann von der NT-Domäne mit ADMT in eine Windows Server 2003 SP1 Domäne migriert und im zweiten Schritt
dann ein Inplace-Update auf Windows Server 2008 durchführt werden. Es bleibt abzuwarten, ob Microsoft ein aktualisiertes ADMT
veröffentlicht, wovon ich aber ausgehe.

Anstatt dann den Windows Server 2003 DC auf Windows Server 2008 zu aktualisieren, kann nach der Anwendung von Adprep ein
zusätzlicher Windows Server 2008 DC zur Domäne hinzugefügt werden.

>>

Szenario 2

Migrations-Möglichkeiten von Windows 2000 auf Windows Server 2008

In einer Windows 2000 Active Directory Umgebung kann die Domänenaktualisierung auf Windows Server 2008 über einen
zusätzlichen Windows Server 2008 DC realisiert werden. Dazu ist zuerst die Step-by-Step Anleitung durchzuführen,
die am Anfang dieses Artikels beschrieben ist. Anschließend kann ein Windows Server 2008 als zusätzlicher Domänencontroller
der bereits bestehenden Domäne hinzugefügt werden.

Es ist zuerst ein Inplace-Update von Windows 2000 auf Windows Server 2003 mit mindestens dem Service Pack 1 durchzuführen.
Erst dann kann per Inplace-Update auf Windows Server 2008 migriert werden.
Ein Windows 2000 DC kann nicht direkt auf Windows Server 2008 aktualisiert werden, denn dieses wird erst ab
Windows Server 2003 mit Service Pack 1 unterstützt.

Migration von Windows Server 2000 auf Windows Server 2003 (Inplace-Update)
>>

Szenario 3

Migrations-Möglichkeiten von Windows Server 2003 auf Windows Server 2008

Wie in einer Windows 2000 Gesamtstruktur kann auch in einer Windows Server 2003 Gesamtstruktur die Domänenaktualisierung über einen
zusätzlichen Windows Server 2008 Domänencontroller erfolgen. Natürlich auch nur dann, wenn die Step-by-Step Anleitung durchgeführt wurde.

Ist mindestens das Service Pack 1 für den Windows Server 2003 auf dem DC installiert, so kann mit einem Inplace-Update der
Windows Server 2003 DC auf Windows Server 2008 aktualisiert werden. Die Step-by-Step Anleitung die am Anfang dieses Artikels
beschrieben wird, ist dabei zuerst durchzuführen.
>>

Szenario 4

Migrations-Möglichkeiten von Windows Server 2003 R2 auf Windows Server 2008

Da in einem Windows Server 2003 R2 ein Windows Server 2003 mit mindestens dem Service Pack 1 enthalten ist,
kann nach vorheriger Ausführung von Adprep ein zusätzlicher Windows Server 2008 DC zur bestehenden Gesamtstruktur hinzugefügt werden.

Des Weiteren kann ein Windows Server 2003 R2 DC per Inplace-Update auf Windows Server 2008 aktualisiert werden.

>>

Probleme die nach dem Hinzufügen des ersten Windows Server 2008 DC entstehen können

Client computers may not work correctly when you add a Windows Server 2008-based domain controller to an existing pre-Windows Server 2008 domain
When a Windows NT 4.0-based computer tries to use the NETLOGON service to establish a security channel to a Windows Server 2008-based domain controller, the operation may fail
Modify Default Security Policies on Windows Server 2008-Based Domain Controllers
Group Policy settings are not applied on member computers that are running Windows Server 2008 or Windows Vista SP1 when certain SMB signing policies are enabled
Office Communications Server 2007 or Live Communications Server 2005 does not work correctly after you upgrade a domain controller to Windows Server 2008
You cannot locally configure or locally delete the application partitions that are created for IP telephony after you upgrade from Windows Server 2003 to Windows Server 2008
RODC Compatibility Pack
DCDIAG: NCSecDesc Fehler
Description of the Microsoft server applications that are supported on Windows Server 2008
You cannot remotely access encrypted files after you upgrade a Windows Server 2003 file server to Windows Server 2008

Weitere Informationen:
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
Information and resources to use when you plan to upgrade Windows Server 2003 to Windows Server 2008
Adding a Server Running Windows Server 2008 to a Windows Small Business Server 2003 Network
How to Install Exchange 2007 SP1 Prerequisites on Windows Server 2008 or Windows Vista
How to back up and then restore printers when you upgrade from Windows Server 2003 to Windows Server 2008
Client computers may not work correctly when you add a Windows Server 2008-based domain controller to an existing pre-Windows Server 2008 domain
Upgrading Active Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains

>>>>>>> >>> >

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Das Active Directory Preparation Tool - ADPREP

Yusuf Dikmenoglu — Sun, 05 Aug 2007 20:18:05 GMT

Steht eine Domänenaktualisierung von Windows 2000 auf Windows Server 2003/2003 R2 oder auf Windows Server 2008/2008 R2 bevor,
sei es durch ein Inplace-Upgrade oder durch das Hinzufügen des ersten Windows Server 2003/2003 R2/2008/2008 R2 Domänencontroller zur Gesamtstruktur,
so gilt es zuerst das AD-Schema zu aktualisieren.

Doch bevor dieser Schritt durchgeführt wird, wäre es empfehlenswert die Ausgangssituation zu überprüfen.
Die Active Directory- sowie die NTFRS/DFSR- Replikation sollte und muss ohnehin ordnungsgemäß auf allen Domänencontrollern funktionieren.
Das Verzeichnisdienstprotokoll auf den Domänencontrollern sollte weder Warnungen, noch Fehler vorweisen.
Diverse Tests mit den Tools DCDIAG, NetDIAG, FRSDiag sowie REPADMIN sind einem beim sicherstellen der fehlerfreien Funktion der DCs sowie der Replikation hilfreich.
Die genannten Tools befinden sich bis einschließlich Windows Server 2003 in den Windows Support Tools und sind ab Windows Server 2008 bereits "on Bord."

Was noch alles zu beachten und auszuführen wäre, erfährt man aus diesen Artikeln:

Migration von Windows Server 2000 auf Windows Server 2003 (Inplace-Update)
Den einzigen Domänencontroller austauschen
Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen

Hinweis zu Exchange

Wenn ein Exchange 2000 Schema in der Gesamtstruktur vorhanden ist, so ist zuerst die Exchange Schema-Erweiterung zu „korrigieren“.
Dazu wird die Datei InetOrgPersonfix.ldf benötigt, die sich in der Archiv-Datei Support.cab im Verzeichnis „Support\Tools\" auf der
Windows Server 2003 CD befindet. Diese Archiv-Datei gilt es zu entpacken und anschließend mit LDIFDE ins Schema zu importieren.

Der Befehl dazu lautet:
Ldifde.exe /i /f inetOrgPersonFix.ldf /c "DC=X" "DC=Domäne,DC=TLD".

Führt man diesen Schritt vorher nicht aus, würde es zu entstellten Attributen kommen:
Windows Server 2003 adprep /forestprep command causes mangled attributes in Windows 2000 forests that contain Exchange 2000 servers

Soll im Zuge der AD Migration gleichzeitig auch ein Update auf Exchange 2003 erfolgen, so ist es einfacher,
erst das Exchangesetup mit dem Schalter /Forestprep durchzuführen. Der oben beschriebene Fix wird dadurch unnötig.

Hinweis: Im weiteren Verlauf ist zwar die Rede von "Windows Server 2003", doch die einzelnen Schritte gelten auch für neuere Serverbetriebssystemversionen.

Das Ausführen von ADPREP

Wenn alles soweit in Ordnung ist, kann die eigentliche Schemaaktualisierung durchgeführt werden.
Dazu ist das Active Directory Preparation Tool (kurz ADPREP) von der Windows Server 2003 CD zum einen auf dem Schemamaster
und zum anderen auf dem Infrastrukturmaster der jeweiligen Domäne, mit jeweils anderen Parametern auszuführen. >
Alle Windows 2000 Domänencontroller in der Gesamtstruktur sollten idealerweise das aktuelle Service Pack 4 und alle weiteren Updates installiert haben.
Prepare Your Infrastructure for Upgrade
Hotfixes to install before you run adprep /Forestprep on a Windows 2000 domain controller to prepare the Forest and domains for the addition of Windows Server 2003-based domain controllers

Im ersten Schritt, muss zuerst die Gesamtstruktur mit dem Befehl ADPREP /Forestprep auf dem Domänencontroller,
der die Rolle des Schemamaster innehat, auf eine Windows Server 2003 Gesamtstruktur aktualisiert werden.

Würde die Gesamtstruktur (oder Domäne) nicht auf Windows Server 2003 aktualisiert werden, würde der Active Directory-Assistent DCPROMO
beim Heraufstufen des ersten Windows Server 2003/R2 zum Domänencontroller an entsprechender Stelle bzgl. des ADPREP`s einen Fehler melden.
Danach hat man immer noch Zeit das ADPREP auszuführen um anschließend mit dem Heraufstufen des Servers fortzufahren.

Im zweiten Schritt ist das ADPREP mit dem Parameter /Domainprep /GPPREP auf dem Infrastrukturmaster in der Domäne, in der man
den neuen Windows Server 2003 DC hinzufügen möchte auszuführen. Somit wird die Domäne auf Windows Server 2003 aktualisiert.

Wenn man ab Windows Server 2008 einen Read Only Domain Controller (RODC) zur Domäne hinzufügen möchte, so sollte der Befehl ADPREP /RODCPREP auf einem Infrastrukturmaster ausgeführt werden.

Falls das ADPREP in einer Gesamtstruktur oder Domäne nicht ausgeführt wurde, so wird während dem Heraufstufen eines DCs eine Fehlermeldung
bzgl. ADPREP angezeigt und der Vorgang bleibt stehen. Danach kann man jederzeit das ADPREP nachholen und anschließend mit dem Heraufstufen
des DCs fortfahren.

Wie stellt man nun sicher, dass die Änderungen die auf dem Schemamaster mit ADPREP /Forestprep durchgeführt wurden,
auch auf allen Domänencontrollern in der Gesamtstruktur repliziert wurde?

Mit dem Ausführen von ADPREP /Domainprep /GPPREP muss solange gewartet werden, bis die durch ADPREP /Forestprep
vorgenommenen Änderungen vom Schemamaster, auf den Infrastrukturmaster (in der Domäne, in der man den neuen
Windows Server 2003 hinzufügen möchte) repliziert worden ist.

Wenn ADPREP erfolgreich (oder nicht) durchgeführt wurde, wird das in der Kommandozeile angezeigt.
Auf dem Schema-Master wird in der Konfigurationspartition die folgenden beiden Container erstellt und
diese müssen auf allen DCs in der Gesamtstruktur repliziert werden:

CN=Windows2003Update,CN=ForestUpdates,CN=Configuration,DC=Domäne.TLD.
CN=Operations,CN=Windows2003Update,CN=ForestUpdates,CN=Configuration,DC=Domäne.TLD.

Mit Ausführen von Adprep /Forestprep werden 36 Änderungen in der CN=Configuration und CN=Schema Verzeichnispartition des Schemamasters durchgeführt.
Für jede Operation die durch den Befehl ADPREP /Forestprep ausgeführt wird, erstellt der Prozess eine GUID im Container CN=Operations.
Jede GUID stellt eine Operation dar.

Wenn alle 36 Operationen erfolgreich durchgeführt wurden, wird anschließend der folgende Container erstellt:

CN=Windows2003Update,CN=ForestUpdates,CN=Configuration,DC= Domäne,TLD.

Im Container CN=Windows2003Update muss das Attribut Revision den Wert 9 enthalten.
Das ADPREP /Forestprep wird nur einmal auf dem Schemamaster in der Gesamtstruktur ausgeführt.

Welche Änderungen im Detail ausgeführt werden, zeigt dieser Artikel:
Operations that are performed by the Adprep.exe utility when you add a Windows Server 2003 domain controller to a Windows 2000 domain or forest

Hinweis: Welchen Wert das Attribut Revision in den neueren Serverbetriebssystemen hat, verraten die jeweiligen Artikel die am Anfang diesen Artikels aufgeführt sind!

>
Was wird mit ADPREP /Domainprep durchgeführt?

Es werden 50 Änderungen auf dem Infrastrukturmaster vorgenommen.
Auf dem Infrastrukturmaster wird in der Domänenpartition die folgenden beiden Container erstellt und diese müssen auf allen DCs in der Domäne repliziert werden:

CN=Windows2003Update,CN=DomainUpdates,CN=System,DC=Domäne.TLD.CN=Operations,CN=DomainUpdates,CN=System,DC=Domäne.TLD.

Für jede Operation die durch den Befehl ADPREP /Domainprep ausgeführt wird, erstellt der Prozess eine GUID im Container CN=Operations,CN=DomainUpdates,CN=System,DC=Domäne.TLD.
Jede GUID stellt eine Operation dar. Im Container CN=Windows2003Update muss das Attribut Revision den Wert 8 enthalten.

Das ADPREP /Domainprep muss in jeder Domäne, in der ein Windows Server 2003 hinzugefügt werden soll, auf dem Infrastrukturmaster ausgeführt werden.

Für detailierte Infos siehe:
Operations that are performed by the Adprep.exe utility when you add a Windows Server 2003 domain controller to a Windows 2000 domain or forest

Hinweis: Welchen Wert das Attribut Revision in den neueren Serverbetriebssystemen hat, verraten die jeweiligen Artikel die am Anfang diesen Artikels aufgeführt sind!

>
Was macht der Befehl ADPREP /Domainprep /Gpprep?

Dieser Befehl steht ab Windows Server 2003 zur Verfügung und ist bei einer Domänenaktualisierung von Windows 2000 zwingend auszuführen!
Er führt das gleiche wie der Befehl ADPREP /Domainprep aus. Zusätzlich wird durch den Parameter /Gpprep
den Gruppenrichtlinienobjekten im SYSVOL-Verzeichnis vererbbare Zugriffssteuerungseinträge hinzugefügt.

Gibt es etwas vor dem Ausführen von ADPREP zu beachten?

Das Windows 2000 Active Directory-Schema muss eine Schemaaktualisierung zulassen:
Schema Updates Require Write Access to Schema in Active Directory

Des Weiteren wurde in früheren Microsoft-Artikeln empfohlen, den Schemamaster vor dem Ausführen von ADPREP /Forestprep vorübergehend
in ein privates Netzwerk zu isolieren bzw. „offline“ zu nehmen. In der Praxis hat sich diese Vorgehensweise eher als Nachteil erwiesen.
Denn die Schemaänderungen wurden teilweise nach dem Neustart des Schemamasters „zurückgewiesen“.

Wenn man dennoch den Schemamaster vor dem Ausführen von ADPREP /Forestprep isolieren möchte,
dann wäre es empfehlenswert die ausgehende Active Directory-Replikation vorübergehend zu deaktivieren.

Die AD-Replikation lässt sich mit REPADMIN aus den Windows Support Tools deaktivieren. Der Befehl dazu lautet:

REPADMIN /Options +DISABLE_OUTBOUND_REPL

Nach dem Ausführen von ADPREP /Forestprep ist folgendes zu prüfen:

Der Befehl Adprep /Forestprep wurde ohne Fehler in der Kommandozeile ausgeführt.

Der Container CN=Windows2003Update wurde unter "CN=ForestUpdates,CN=Configuration,DC=Domäne.TLD" erstellt.
Der Wert des Attributs Revision im Container CN=Windows2003Update muss 9 sein.

Die Schemaversion wurde auf Version 30 bzw. 31 erhöht. Überprüfen lässt sich die Schema-Version entweder durch die Registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\“SchemaVersion“ (die Zahl in Klammern gibt die Version an)
oder durch das Attribut
ObjectVersion das sich unter "CN=Schema,CN=Configuration,DC=Domäne.TLD befindet.

Auch mit Dsquery lässt sich die Schema-Version abfragen. Der Befehl lautet wie folgt:
dsquery * CN=Schema,CN=Configuration,DC=Root-Domäne -Scope Base -attr objectVersion

Vorausgesetzt dass der Vorgang erfolgreich durchgeführt wurde, ist anschließend die ausgehende Replikation zu aktivieren.
Dazu muss der folgende Befehl in der Kommandozeile ausgeführt werden:

REPADMIN /Options -DISABLE_OUTBOUND_REPL

How to upgrade Windows 2000 domain controllers to Windows Server 2003

Von welcher CD/DVD muss das ADPREP ausgeführt werden?

Das ADPREP muss immer von der Server-CD ausgeführt werden, auf die man aktualisieren möchte.
Das ADPREP befindet sich auf der Windows Server 2003 CD im Verzeichnis CD-Laufwerk:\i386.
Ist der neue DC ein Windows Server 2003 R2, so muss das ADPREP von der zweiten R2-CD aus dem Verzeichnis CD-Laufwerk:\CMPNENTS\R2\ADREP ausgeführt werden.

Unter Windows Server 2008 befindet sich das ADPREP im Verzeichnis: <DVD-Laufwerk>:\Sources\Adprep
Und unter Windows Server 2008 R2 im Verzeichnis: <DVD-Laufwerk>:\Support\Adprep. Achtung: Unter Windows Server 2008 R2 gibt es zwei ADPREP-Versionen.
Eine Version lautet Adprep.exe, mit der man das AD-Schema auf einem x64Bit DC aktualisieren muss. Die andere Version lautet Adprep32.exe, mit der man das AD-Schema auf einem x32Bit DC aktualisieren muss.

Wird hingegen der erste Windows Server 2003 R2 in der 64Bit Version einer 32Bit Windows 2000/2003 Gesamtstruktur hinzugefügt,
so muss von Microsoft entweder ein Hotfix angefordert oder die 32Bit-Trial Version heruntergeladen und von dort das ADPREP ausgeführt werden.
Siehe dazu: Schemaupdate beim Windows Server 2003 R2

Wenn der erste SBS 2003 oder SBS 2003 R2 hinzugefügt werden soll, dann ist das ADPREP von der ersten SBS-CD, im Verzeichnis i386 auszuführen.

In welchen Gruppen muss das Benutzerkonto mit dem das ADPREP ausgeführt wird, Mitglied sein?

Das Benutzerkonto mit dem das ADPREP ausgeführt wird, muss beim ausführen des Parameters /Forestprep Mitglied in den Gruppen
Schema-Admins, Organisations-Admins und Domänen-Admins in der Domäne sein, in der sich der Schemamaster befindet.
Oder die entsprechenden Berechtigungen müssen dem Benutzerkonto delegiert worden sein.

Beim ausführen von ADPREP mit dem Parameter /Domainprep oder /Domainprep /Gpprep muss das Benutzerkonto Mitglied in der Gruppe
Domänen-Admins sein. Die Delegierung der entsprechenden Berechtigungen an das Benutzerkonto wäre ebenfalls möglich.

Für das Ausführen von ADPREP /RODCPREP muss das Benutzerkonto Mitglied in der Gruppe Organisations-Admins sein.

Auf welche Schema-Version wird das Schema aktualisiert? >>>
Die Schema-Version lässt sich in der Registry (das es unter Start-Ausführen-Regedit aufzurufen gilt) des DCs überprüfen.
Anschließend navigiert man zu folgendem Schlüssel: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters.

Dort kontrolliert man den Eintrag "Schema Version". Die Zahl in Klammern, gibt die Schema-Version an.
Diese wären:

- (13) = Windows 2000 (ohne/mit allen SPs)
- (30) = Windows Server 2003 ohne/mit SP1/SP2 (und höhere SPs)
- (31) = Windows Server 2003 R2 ohne/mit SP2 (und höhere SPs)
- (44) = Windows Server 2008
- (47) = Windows Server 2008 R2

Die Schema-Version lässt sich ebenfalls mit ADSIEdit oder dem Active Directory Explorer überprüfen.
Das zu überprüfende Attribut lautet objectVersion und befindet sich im Container:

CN=Schema,CN=Configuration,DC=<DeineDomäne>,DC=<TLD>.

Auch mit Dsquery lässt sich die Schema-Version abfragen. Der Befehl lautet wie folgt:
dsquery * CN=Schema,CN=Configuration,DC=Root-Domäne -Scope Base -attr objectVersion

Gibt es auch ein Protokoll vom ADPREP?

Es wird ein ADPREP-Protokoll im Verzeichnis %Systemroot%\System32\Debug\Adprep\Logs
erstellt und enthält einen detaillierten Bericht zur Domänen- und Gesamtstrukturvorbereitung.

Weitere wichtige Informationen

When you run the "Adprep /forestprep" command to prepare Windows 2000 Active Directory for Windows Server 2003, the forest preparation operation fails
Aktualisieren von einer Windows 2000-Domäne
Enhancements to Adprep.exe in Windows Server 2003 Service Pack 1 and in hotfix 324392
Windows Server 2003 adprep /forestprep command causes mangled attributes in Windows 2000 forests that contain Exchange 2000 servers
Upgrading from Windows 2000 Server to Windows Server 2003
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Migration von Windows Server 2000 auf Windows Server 2003 (Inplace-Update)

Yusuf Dikmenoglu — Wed, 13 Sep 2006 20:01:37 GMT

Welche Schritte müssen beachtet werden, wenn man einen Windows Server 2000 auf Windows Server 2003 R2 aktualisieren möchte ?

Ich gehe an diesem Beispiel davon aus, dass auf dem 2000er Domänencontroller das DNS, Active Directory-integriert installiert ist.

1. Bevor man anfängt, sollte natürlich ein Backup der Daten und vorallem vom SYSTEM STATE existieren:

http://support.microsoft.com/kb/240363/de

Desweiteren muss sich auf allen DCs die Datei "NTDSA.DLL" im Pfad %windir%\system32 befinden, die einen höheren Datumsstempel als den 04. Juni 2001
sowie eine höhere Dateiversion als 5.0.2195.3673 hat. Der Virenscanner sollte während dem Update deaktiviert werden.

2. Zuerst sollte mit der Option „/checkupgradeonly“ das System auf Kompatibilität geprüft werden und falls die Routine an etwas meckert, sollten
zuerst die gemeldeten Probleme beseitigt werden.

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/de/library/ServerHelp/1e2541bb-d42c-49ef-9f8a-18e30b4f2667.mspx?mfr=true

3. Zuallererst gilt es auf dem Windows 2000 DC, dass EFS – Zertifikat zu sichern (falls dieser der erste DC in der Domäne ist):

http://www.faq-o-matic.net/2003/08/18/was-muss-ich-tun-um-den-ersten-dc-zu-deinstallieren/

http://support.microsoft.com/kb/241201/de

4. Auf dem Windows Server 2000 Domänencontroller muss mindestens das SP 2 installiert sein (heutzutage schon das SP4)
(http://www.microsoft.com/windowsserver2003/evaluation/whyupgrade/win2k/w2ktows03-2.mspx).

Die Zeiten der Domänencontroller sollten synchronisiert und auf allen gleich sein.
Danach muss auf dem 2000er DC, der die Rolle des Schemamasters innehat (idealerweise trägt dieser DC alle Rollen sowie den GC),
die Windows Server 2003 CD eingelegt und auf der Kommandozeile (START – AUSFÜHREN – CMD) ins Verzeichnis I386 gewechselt werden,
um „ADPREP /FORESTPREP“ auszuführen. Anschließend muss auf dem DC, der die Rolle des Infrastrukturmasters innehat in der Domäne,
in der der neue DC hinzugefügt werden soll, noch das „ADPREP /DOMAINPREP /GPPREP“ ausgeführt werden.
Das Active Directory Preparation Tool - ADPREP

Möchte man auf Windows Server 2003 R2 aktualisieren, so gilt es ADPREP von der zweiten R2 CD auszuführen und nicht von der ersten:
Schemaupdate beim Windows Server 2003 R2

5. Migriert man auf "Windows Server 2003 mit SP1" (oder R2), sollte noch das „ADPREP /DOMAINPREP /GPPREP“ ausgeführt werden.
Näheres siehe: http://support.microsoft.com/kb/324392/en-us

6. Anschließend führt man auf dem Windows 2000 Domänencontroller das SETUP von der CD aus und folgt den Anweisungen,
damit das Update auf den Windows Server 2003 beginnen kann.

7. Folgendes ist zu beachten, falls Exchange 2000 auf der gleichen Maschine laufen sollte:
Zuerst muss das Exchange 2000 auf Exchange 2003 upgedatet werden. Denn Exchange 2003 läuft unter Windows Server 2000,
aber nicht umgekehrt (Exchange 2000 auf Windows Server 2003), dass geht nicht.

Daher MUß zuerst ein Exchange update gemacht werden und dann das Betriebssystemupdate von Windows Server 2000 auf Windows Server 2003
(es müssen zwei Schemaupdates durchgeführt werden, einmal für Exchange und dann für das Active Directory).
Bevor man mit dem Betriebssystemupdate beginnt, sollte von der Exchange-CD aus dem Verzeichnis "support\exdeploy" das Tool "policytest.exe" ausgeführt werden,

um sicher zu gehen, dass die entsprechenden Berechtigungen im Active Directory bestehen.

How to upgrade Windows 2000 domain controllers to Windows Server 2003

Migration Exchange 2000 auf 2003

Windows Server 2003 adprep /forestprep command causes mangled attributes in Windows 2000 forests that contain Exchange 2000 servers

http://redmondmag.com/columns/article.asp?EditorialsID=663

Hier noch weitere hilfreiche Links:

What do I need to do to prepare my Windows 2000 forest for the installation of the first Windows Server 2003 DC?

http://www.petri.co.il/windows_2003_adprep.htm

Common Mistakes When Upgrading Exchange 5.5/2000 To a Exchange 2003

http://support.microsoft.com/kb/555262/en-us

Considerations when you upgrade to Exchange Server 2003

http://support.microsoft.com/kb/822942/en-us

Common Mistakes When Upgrading a Windows 2000 Domain To a Windows 2003 Domain

http://support.microsoft.com/kb/555040/en-us

Cannot Upgrade Windows 2000 Server to Windows Server 2003 with Windows Services for UNIX 2.0 Installed

http://support.microsoft.com/kb/293783/en-us

When you run the "Adprep /forestprep" command to prepare Windows 2000 Active Directory for Windows Server 2003, the forest preparation operation fails

http://support.microsoft.com/kb/924175/en-us

Enhancements to Adprep.exe in Windows Server 2003 Service Pack 1 and in hotfix 324392

http://support.microsoft.com/kb/324392/en-us - sowie

http://technet2.microsoft.com/WindowsServer/en/library/bc5ebbdb-a8d7-4761-b38a-e207baa734191033.mspx?mfr=true

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.

Schemaupdate beim Windows Server 2003 R2

Yusuf Dikmenoglu — Wed, 13 Sep 2006 06:56:20 GMT

Wann muss beim hinzufügen des ersten Windows Server 2003 R2 zu einer Windows 2000/2003 Gesamtstruktur,
ein Schemaupdate durchgeführt werden?

Möchte man den ersten Windows Server 2003 R2 Domänencontroller in eine Windows 2000/2003 Gesamtstruktur hinzufügen,
dann ist ein Schemaupdate auf dem Schemamaster von der zweiten R2-CD notwendig.
Siehe: Wie aktualisiert man einen DC auf Windows Server 2003 R2
Mit dem Schalter /Forestprep werden die neuen R2-Features (die unter den Punkten zwei bis vier aufgezählt sind) dem Schema hinzugefügt.
Falls die Domäne bereits auf Windows 2003 läuft, so ist der Schalter /Domainprep nicht anzuwenden.
Nur wenn man in einer Windows 2000 Domäne, den ersten Windows Server 2003 R2 Domänencontroller hinzufügen möchte,
so muss das ADPREP (neben dem Schalter /Forestprep) zusätzlich mit dem Schalter /Domainprep /Gpprep ausgeführt werden.
Bei Nutzung von DFS-R (die neue DFS Replikation). DFS und DFS-R speichern Konfigurationsoptionen im Active Directory. Das DFS (Namespace) Schema gibt es schon, das Replikationsschema ist neu, da bisher FRS (File Replication Service) benutzt wurde, dass ja weiterhin (parallel) für die SYSVOL-Replikation genutzt wird. Das Schemaupdate für DFS ist auch dann notwendig, wenn DFS nur auf Memberservern läuft.
Für das neue Druckermanagement in R2 ist ein Schemaupdate erforderlich. Bei diesem Schemaupdate werden dem Schema neue Objekt-Klassen hinzugefügt
Auch für das "Indentity Management for Unix" ist ein Schemaupdate fällig und auch hier, werden dem Schema neue Objekt-Klassen hinzugefügt.

Wichtig ist, dass man ADPREP von der zweiten R2-CD auf dem Schemamaster ausführt (dabei wird das Schema auf die Version 31 aktualisiert) und nicht von der ersten, denn das ADPREP befindet sich auf beiden CDs.
Siehe auch: Das Geheimnis der Tombstone Lifetime
Auf der ersten R2-CD ist nichts weiter als ein Windows Server 2003 mit integriertem SP1 oder SP2 drauf. Erst mit der zweiten R2-CD werden die R2 Erweiterungen installiert bzw. das System auf R2 erweitert. Die zweite CD macht daraus ein "R2" indem Zusatzkomponenten unter Systemsteuerung - Software eingetragen werden, die man dann für bestimmte Szenarien nachinstallieren kann.
Wenn man im Ordner DOCS auf der zweiten R2-CD schaut, kann man in der dortigen Datei R2SETUP.CHM alle Informationen über R2 nachlesen.

Wer es noch genauer wissen möchte, der schaut sich die Datei "Sch31.ldf" auf der zweiten R2-CD an. >
Möchte man einen Windows Server 2003 R2 Mitgliedsserver in eine 2000 oder 2003 (nicht R2) Domäne hinzufügen, auf dem die oben aufgeführten Punkte
(zwei bis vier) nicht in Frage kommen, so ist keine Schemaaktualisierung notwending und man kann den Mitgliedsserver mit beiden R2-CDs installieren und ihn in die Domäne hinzufügen.

Erster Windows Server 2003 R2 64 Bit Domänencontroller in einer Windows Server 2003 32 Bit Domäne

Falls der erste Windows Server 2003 R2 in der 64 Bit Edition in eine 32 Bit Windows Server 2003 Domäne hinzugefügt werden soll,
so kann diesmal nicht das ADPREP von der zweiten R2-CD verwendet werden. Denn es enthält nicht das ADPREP in
der 32 Bit Version das dazu benötigt wäre. Stattdessen gibt es einen Hotfix,
den man sich beim Microsoft Product Support Service (MS-PSS) kostenlos bestellen kann.
You cannot deploy a Windows Server 2003 R2 x64 Edition-based domain controller in a Windows Server 2003 forest >
Als weitere Möglichkeit kann man auch die 32Bit Windows Server 2003 R2 Trial-Version downloaden und von dort das ADPREP ausführen.
Installing Windows Server 2003 R2 Standard or Enterprise Edition with SP2 (32-bit x86)
>

Erster Windows Server 2003 R2 Domänencontroller in einer SBS 2003 Domäne

Wenn man einen weiteren Domänencontroller mit der Version "Windows Server 2003 R2 Standard/Enterprise" in eine bestehende SBS 2003 oder SBS 2003 R2 Domäne hinzufügen möchte, so muss mit der zweiten CD des "Windows Server 2003 R2 Standard/Enterprise" das Schema der SBS 2003/R2 Domäne erweitert werden.
Dort gilt es ebenfalls, die zweite CD des Windows Server 2003 R2 Standard/Enterprise in den SBS einzulegen und durch Ausführen von ADPREP,
das Schema der SBS-Domäne auf die Version 31 zu aktualisieren.

Hinweis: Ein SBS 2003 R2 ist nicht die gleiche Version, wie ein Windows Server 2003 R2 Standard/Enterprise.
Wenn ein SBS 2003 R2 DC existiert und man einen Windows Server 2003 R2 Standard/Enterprise als zusätzlichen DC der SBS Domäne hinzufügen möchte,
muss ebenfalls das ADPREP mit dem Schalter /Forestprep von der zweiten Windows Server 2003 Standard/Enterprise R2-CD auf dem Schemamaster (SBS) ausgeführt werden.

>

Weitere Informationen:
Active Directory Schema Update
Extending Your Active Directory Schema for New Features in Windows Server 2003 R2
Optimizing File Replication over Limited-Bandwidth Networks using Remote Differential Compression
Error message when you run the Active Directory Installation Wizard: "The version of the Active Directory schema of the source forest is not compatible with the version of Active Directory on this computer"

Weiterhin viel Spass beim Lesen wünscht Yusuf Dikmenoglu.