Der Read-Only Domänencontroller ist ein DC der für Standorte konzipiert wurde, die keine physikalische Sicherheit dem DC und somit
auch der Domäne bzw. Gesamtstruktur bieten können. Wie es im Namen bereits zu lesen ist, handelt es sich dabei um einen DC der
ausschließlich nur eine Leseberechtigung auf die Active Directory-Daten hat. Falls Änderungen im Active Directory durchgeführt werden sollen,
leitet der RODC diesen Vorgang auf einen beschreibbaren DC weiter. Das gilt auch für Aktualisierungen im DNS.
Zusätzlich stellt die einseitige (unidirektionale) Replikation eine weitere Sicherheitsfunktion dar. Auf dem RODC findet nur eine
eingehende (Inbound)-Replikation statt. Es wird nichts vom RODC zu einem beschreibbaren DC repliziert. Die einseitige Replikation
wird für die Active Directory-Domain Services und für die DFS-Replikation des SYSVOL-Verzeichnisses angewendet.
Weitere Details zum RODC werden in diesem Artikel erläutert:
Read-Only Domain Controller (RODC)
Die Voraussetzungen um den ersten RODC in der Domäne zu installieren
-
Der Modus für die Gesamtstruktur muss sich mindestens auf Windows Server 2003 oder höher befinden,
damit die Linked Value Replikation (LVR) zur Verfügung steht.
-
Der RODC kann sich die Domänenpartition ausschließlich von einem beschreibbaren Windows Server 2008
oder Windows Server 2008 R2 Domänencontroller replizieren. Daher muss sich bereits ein beschreibbarer
Windows Server 2008/2008 R2/Core/Core R2 Domänencontroller in der Domäne befinden. Wenn das nicht der Fall wäre,
würde die Option zum erstellen eines RODC an entsprechender Stelle nicht zur Verfügung stehen.
-
Das Active Directory Preparation Tool (ADPREP) muss mit dem Parameter /RODCPREP ausgeführt worden sein.
Dabei werden die Berechtigungen (Security Descriptor, SD) von allen DNS-Anwendungsverzeichnispartitionen (DomainDNSZones und ForestDNSZones) in der Gesamtstruktur aktualisiert. Der Befehl muss mit Organisations-Administrator Rechten durchgeführt werden und kann auf irgendeinem DC ausgeführt werden. Dieser DC muss auch nicht der Träger der FSMO-Rollen sein. Beim Ausführen von ADPREP /Rodcprep werden die einzelnen Infrastrukturmaster der Domänen kontaktiert, um die Berechtigungen der 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"
-
Wird für die bereitgestellte Installation zuerst das RODC-Computerkonto in der OU Domain Controllers im AD DS erstellt,
darf der zukünftige RODC nicht bereits Mitglied der Domäne sein.
Die Installation eines RODC auf einem Windows Server 2008 (Vollinstallation) durch den DCPROMO-Assistenten
Der Read-Only Domänencontroller kann auf mehrere Varianten bereitgestellt werden.
Die eine Variante wäre die Installation des RODCs durch das Ausführen des DCPROMO-Assistenten. Dies kann von einem
Domänen- bzw. Organisations-Administrator durchgeführt werden. Dabei kann der Server entweder ein standalone- oder
Mitgliedsserver sein. Nach der Betriebssysteminstallation kann der Administrator direkt das DCPROMO aufrufen und somit
den Server zum RODC stufen. Die Installation gestaltet sich nicht sonderlich anders als die Installation eines beschreibbaren DCs.
Es ist lediglich darauf zu achten, dass beim ausführen des DCPROMO-Assistenten die Option
Schreibgeschützter Domänencontroller (RODC) auf der Seite der Domänencontrolleroptionen ausgewählt wird.
Empfehlenswert wäre es, nach dem Aufruf von DCPROMO die Option Installation im erweiterten Modus verwenden auszuwählen.
Ich empfehle diese Option bei jeder DC-Installation zu aktivieren. Erst durch den erweiterten Modus erscheint die zusätzliche
Auswahl (bei einer RODC-Installation) Richtlinie für Kennwortreplikation angeben (Password Replication Policy, kurz PRP),
in der festgelegt werden kann welche Kennwörter auf den RODC repliziert werden dürfen und welche verwehrt bleiben.
Die Replikation der Kennwörter von einzelnen Benutzern, Gruppenmitgliedern oder Computern können auf dem RODC zugelassen
bzw. verwehrt werden. Dabei bleiben standardmäßig die Kennwörter administrativer Konten dem RODC verwehrt.
Wenn dabei ein Benutzerkonto in der abgelehnten- sowie zulässigen RODC-Kennwortreplikationsgruppe Mitglied ist,
so hat die abgelehnte Gruppe Vorrang!
Die Konfiguration der Kennwort-Replikation kann natürlich auch im Nachhinein jederzeit geändert und muss nicht unbedingt während
der Installation festgelegt werden. Weitere Optionen die erst mit aktivieren des erweiterten Installationsmodus erscheinen, wäre die
IFM-Option und die Auswahl eines Quelldomänencontrollers mit dem die Replikation über das Netzwerk durchgeführt werden soll.
Die Installation eines RODC auf einem Windows Server 2008 Core
Der RODC kann ebenfalls auf einer Installation des Windows Server Core bereitgestellt werden. Da das Heraufstufen zu einem
RO-/DC auf einem Windows Server Core nicht wie gewohnt über die GUI des DCPROMO-Assistenten durchgeführt werden kann,
ist der Administrator gezwungen die Installation, entweder durch die einzelne Eingabe der Parameter in der Kommandozeile
(DCPROMO /unattend /ReplicaOrNewDomain=ReadOnlyReplica…) oder mit einer Antwortdatei durchzuführen.
Eine Beispiel-Antwortdatei zum Heraufstufen eines RODCs befindet sich am Ende dieses Artikels:
Windows Server 2008 Core
Die bereitgestellte Installation eines RODC
Eine andere Variante wäre die Installation eines RODCs in zwei Schritten durchzuführen. Dabei erstellt ein Domänen- bzw.
Organisations-Administrator im ersten Schritt zuerst das RODC-Computerkonto im Active Directory und bekommt dabei die Möglichkeit,
die vor Ort Installation sowie die Verwaltung des RODCs entweder von einem Domänen-Administrator durchführen zu lassen
oder an einen Benutzer oder besser einer Benutzergruppe dieses Privileg zu delegieren. Zur leichteren Administration sollte
eine Benutzergruppe angegeben werden. Die Delegierung an dieser Stelle hat den positiven Nebeneffekt, dass der Benutzer
oder die Gruppe denen dieses Recht delegiert wurde, gleichzeitig auch der lokale Administrator des Systems ist. Die Änderungen
am System, sei es Treiberaktualisierungen, Softwareinstallationen oder Hardwaretausch kann von nun an von einem normalen Benutzer
durchgeführt werden, der keine Rechte auf das Active Directory hat. In den vorherigen Server-Versionen stellte genau dieses
Szenario in verteilten Umgebungen oftmals ein Problem dar. Im zweiten Schritt wird durch das Ausführen von DCPROMO auf dem
Server die RODC-Installation endgültig abgeschlossen.
Die Vorgehensweise für die bereitgestellte Variante wäre folgende
-
In der MMC Active Directory-Benutzer und -Computer ist auf einem beschreibbaren Windows Server 2008 Domänencontroller,
mit einem Rechtsklick auf der OU Domain Controllers die Option Konto für schreibgeschützten Domänencontroller vorbereiten… auszuwählen.
-
Auf der Willkommensseite gilt es die Option Installation im erweiterten Modus verwenden zu aktivieren.
-
-
Als nächstes werden die Anmeldeinformationen eines Domänen- oder Organisations-Administrators benötigt. Wenn man auf dem
System, auf der man das RODC-Computerkonto erstellt als Domänen-Administrator angemeldet ist, reichen die aktuellen
Anmeldeinformationen aus und es müssen keine alternativen Anmeldeinformationen eingegeben werden. Ansonsten werden
alternative Anmeldeinformationen benötigt. Wenn die angegebenen Anmeldeinformationen nicht über die benötigten Rechte verfügen,
folgt eine Warnung mit dem Hinweis, dass das angegebene Benutzerkonto in keines der genannten Gruppen Mitglied ist. Es ist zwar
trotzdem möglich mit dem Assistenten fortzufahren, aber spätestens nach der Zusammenfassung erscheint erneut der Hinweis,
dass die eingegeben Anmeldeinformationen nicht ausreichen. Aber auch hier bekommt man dann die Option,
ein berechtigtes Benutzerkonto einzugeben.
-
Auf der nächsten Seite muss der Computername des zukünftigen RODCs eingetragen werden. Des Weiteren wird der Hinweis angezeigt,
dass der Computername an dieser Stelle vergeben werden muss. Weiterhin wird darauf hingewiesen, dass der Server erst mit Ausführen
von DCPROMO zur Domäne hinzugefügt werden darf. Falls der Server zu diesem Zeitpunkt bereits Mitglied der Domäne wäre,
würde an dieser Stelle eine Fehlermeldung erscheinen:
-
Nun muss der Standort ausgewählt werden, an dem der RODC eingesetzt werden soll.
-
Im darauffolgenden Schritt ist die Auswahl der zusätzlichen Domänencontrolleroptionen zu treffen. Es stehen insgesamt drei Optionen
zur Auswahl, wobei die letzte Option Schreibgeschützter Domänencontroller (RODC) aktiviert und ausgegraut ist. Die beiden anderen
Optionen wären DNS-Server und Globaler Katalog (was vorteilhaft wäre diese aktiviert zu lassen).
-
An dem nächsten Punkt angelangt, kann man die Richtlinie für die Kennwortreplikation bearbeiten. Die Kennwortreplikation beeinflusst
das Anmeldeverhalten eines Benutzers bei nicht erreichen eines beschreibbaren DCs.
Der genaue Vorgang wird auf diesen Seiten erklärt:
Appendix B: How the Authentication Process Works with RODCs
Password Replication Policy
Wichtig an dieser Stelle wäre zu erwähnen, möchte man das der RODC einen Benutzer (oder Dienstkonto) eigenständig authentifiziert,
ohne das ein beschreibbarer DC kontaktiert werden soll (z.B. wenn die WAN-Verbindung unterbrochen ist), so muss neben dem Kennwort
des Benutzerobjekts noch das Computerkontokennwort an dem sich der Benutzer anmeldet, bereits auf den RODC repliziert worden sein.
Natürlich müssen die betroffenen Benutzer- sowie Computerkonten vorher in der Richtlinie für die Kennwortreplikation zugelassen werden.
Falls das Kennwort eines Benutzers (und/oder Computerkontos, an dem sich der Benutzer anmeldet) nicht auf den RODC repliziert wurde
und es entsteht eine WAN-Störung, kann sich der Benutzer zu diesem Zeitpunkt lediglich mit seinen zwischengespeicherten
Benutzerinformationen (cached Credentials) anmelden. Das kann der Benutzer wiederum nur, wenn er sich vorher einmal von
dem Computer aus, erfolgreich an der Domäne authentifiziert hat.
Der RODC trägt sich bekanntermaßen als Key Distribution Center (KDC) im Active Directory für seinen Standort ein und somit kann der
RODC dem Client das Ticket-Granting Ticket (TGT) ausstellen.
Die Replikation der Kennwörter lässt sich manuell anstoßen. Zum einen ist das mit Repadmin möglich. Der Befehl dazu lautet:
Repadmin /Rodcpwdrepl <RODC*> <beschreibbarer DC> <DN des Benutzerkontos> <DN des Clients>
Repadmin /rodcpwdrepl
Zum anderen lässt sich die Replikation der Kennwörter auch über die grafische Oberfläche realisieren. Dazu gilt es in der MMC
Active Directory-Benutzer und -Computer die Eigenschaften des RODC-Computerkontos zu öffnen. Dort im Reiter
Kennwortreplikationsrichtlinie ist die Option Erweitert auszuwählen. In der erweiterten Kennwortreplikation hat man nun die
Möglichkeit über die Auswahl von Kennwörter auffüllen… die entsprechenden Kennwörter sofort zu replizieren.
-
Der Assistent fragt als nächstes nach einem Benutzer oder einer Gruppe, die das Recht delegiert bekommen sollen den RODC
fertig zu installieren (durch Ausführen von DCPROMO). Zudem wird darauf hingewiesen das die angegeben Konten über lokale
Administratorberechtigungen verfügen. Erfolgt an dieser Stelle keine Eingabe, so kann die Installation des RODCs ausschließlich
von einem Domänen- oder Organisations-Administrator abgeschlossen werden.
Erneut der Hinweis; Die hier angegebenen Konten bekommen keine weiteren Rechte auf das AD!
-
Es folgt die Zusammenfassung in der die gewählten Einstellungen überprüft werden können.
-
Anschließend wird mit Fertig Stellen der Vorgang zum erstellen des RODC-Computerkontos abgeschlossen.
Zum Fertigstellen der RODC-Installation ist es als letzten Schritt notwendig, an dem zukünftigen RODC den DCPROMO-Assistenten auszuführen.
Die Vorgehensweise wäre folgende:
-
Mit dem Befehl Dcpromo /UseExistingAccount:Attach gilt es unter Start - Ausführen den DCPROMO-Assistenten aufzurufen.
-
Falls man die Installation mit Hilfe einer Install from Media (IFM) -Sicherung durchführen möchte, sollte die Option
Installation im erweiterten Modus verwenden aktiviert werden. Auch wenn man explizit einen DC auswählen möchte
von dem die Replikation erfolgen soll, ist der erweiterte Modus zu aktivieren.
-
Im nächsten Schritt muss die Domäne angegeben werden zu der der RODC hinzugefügt werden soll. Zusätzlich sind die
alternativen Benutzerinformationen eines Benutzers anzugeben, der beim erstellen des RODC-Computerkontos das Recht der
Installation delegiert bekommen hat (siehe oben Punkt 9). Natürlich kann hier auch der Domänen-Administrator angegeben werden.
-
Danach muss das bereits erstellte RODC-Computerkonto ausgewählt werden.
-
Wurde der erweiterte Modus auf der Willkommensseite ausgewählt, kann an dieser Stelle eine Sicherung angegeben werden.
-
Falls keine Sicherung angegeben wird, kann als nächstes ein Quelldomänencontroller ausgewählt werden,
von dem aus die Replikation ausgeführt wird.
-
Auf der nächsten Seite kann der Pfad zur Active Directory-Datenbank, den Protokolldateien und dem SYSVOL-Verzeichnis konfiguriert werden.
-
Dann muss ein Kennwort für den Wiederherstellungsmodus für Verzeichnisdienste vergeben werden.
-
Zum Schluss erfolgt die Zusammenfassung der Einstellungen die vorgenommen wurden, bevor es dann mit der Installation beginnt.
Die Verwaltung des RODC
Die Information wer den RODC lokal administrieren darf wird im Active Directory, genauer, im Attribut managedBy das sich im RODC-Computerkonto
befindet gespeichert. Ist es notwendig die lokale Verwaltung des RODCs an einen anderen Benutzer bzw. Benutzergruppe zu delegieren, so kann
diese Einstellung in den Eigenschaften des RODC-Computerkontos, im Reiter Verwaltet von vorgenommen werden.
Oder es wird im Reiter Attribut-Editor der Distinguished Name des Benutzers (oder der Benutzergruppe) direkt im
Attribut managedBy eingetragen, der zukünftig den RODC verwalten soll.
Zusätzlich wird in der Registry auf dem RODC im folgenden Pfad:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\RODCROLES
im Schlüssel RepairAdmin die SID des Benutzers/der Benutzergruppe gespeichert, die im Attribut managedBy eingetragen wurde.
Eine andere Variante einen lokalen Administrator zu definieren wäre über die beiden Kommandozeilentools DSMGMT.exe oder NTDSUTIL.exe.
Dadurch können auch feinere Rechte gesetzt werden, in dem z.B. der Domänen-Benutzer in die Gruppe der Sicherungs-Operatoren
oder Server-Operatoren auf dem RODC hinzugefügt wird.
Dieses erreicht man durch folgende Vorgehensweise:
- Start - Ausführen - DSMGMT.exe oder NTDSUTIL.exe (die Eingabe der folgenden Befehle gelten sowohl für DSMGMT als auch für NTDSUTIL)
- Local Roles
- Add <DOMÄNE>\<Domänen-Benutzer> Server-Operatoren
Mit Show Role Server-Operatoren können die Mitglieder dieser Gruppe angezeigt werden.
Wenn ein Benutzer über diese Methode zu einer Gruppe hinzugefügt wurde, wird im o.g. Registry-Pfad ein weiterer
Schlüssel erstellt, das als Wert die SID des Benutzers enthält. Der Schlüssel trägt als Namen das letzte Oktett der Well-Known SID von der
entsprechenden Gruppe, in der der Benutzer hinzugefügt wurde. Wird z.B. ein Benutzer zu der Builtin-Gruppe Server-Operatoren hinzugefügt,
so lautet der Name des erstellten Schlüssels 549. Wird hingegen der Benutzer zu der Builtin-Gruppe Konten-Operatoren hinzugefügt,
so trägt der Schlüssel den Namen 548.
Well-known security identifiers in Windows operating systems
Wird der Benutzer mit dem Befehl Remove <DOMÄNE>\<Domänen-Benutzer> <Gruppe>
aus der Gruppe entfernt, bleibt der erstellte Schlüssel zwar bestehen, jedoch wird der als Wert eingetragene SID entfernt.
Weitere Informationen:
Read-Only Domain Controllers and Account Lockouts
Performing a Staged RODC Installation
Applications That Are Known to Work with RODCs
Als Microsoft mit Windows 2000 das Active Directory in der ersten Version einführte, waren damals die Ansprüche an dem
Verzeichnisdienst andere als heute. Insbesondere was die Active Directory-Replikation oder das Replikationsaufkommen angeht,
hatte man seinerzeit noch eine andere (geringere) Vorstellung darüber. Es kristallisierte sich heraus, dass sich dieses Verhalten
noch verbessern lässt. Denn sowohl unter Windows 2000 als auch Windows Server 2003 (abhängig vom Gesamtstrukturfunktionsmodus)
werden sämtliche Werte eines mehrwertigen (multi-valued) Attributs auch dann repliziert, wenn lediglich ein einziger Wert geändert wurde.
In einem mehrwertigen bzw. multi-valued Attribut werden, wie es der Name bereits verrät, mehrere Werte in einem Attribut gespeichert.
In Windows 2000 findet dabei ausschließlich eine Replikation auf Attribut-Ebene und nicht auf der Wert-Ebene (per Value) statt.
Die Replikation auf Attribut-Ebene hat den Nachteil, dass zum einen ein dadurch überflüssig hohes Replikationsaufkommen
entsteht und zum anderen, dass Risiko eines Replikationskonflikts sich erhöht. Bekanntermaßen findet im Active Directory
eine Multimaster-Replikation statt was soviel bedeutet, dass auf jedem Domänencontroller zur gleichen Zeit eine Änderung
durchgeführt werden kann, die dann durch die AD-Replikation auf die anderen DCs repliziert wird.
Wenn nun bei diesem Replikationsverhalten zur gleichen Zeit auf verschiedenen DCs einer Domäne, der Wert des gleichen
Attributs verändert wird, würde ein Replikationskonflikt entstehen und somit eines der Änderungen verworfen werden.
Wie sich das Active Directory im Falle eines Replikationskonflikts verhält, wird im folgenden Artikel erläutert:
Active Directory-Replikationskonflikt
Das Verhalten trifft natürlich nur dann zu, wenn sich mindestens zwei Domänencontroller in der Domäne befinden.
Ansonsten würde keine Replikation stattfinden  .
Das oft zitierte Beispiel das man zu diesem Thema liest, wären Gruppenmitgliedschaften, was nachfolgend noch
genauer erläutert wird. Das Beispiel mit den Gruppenmitgliedschaften bietet sich deshalb an, da es sich zum einen
um ein mehrwertiges Attribut (Member) handelt und zum anderen in der Praxis darin viele Werte gespeichert werden.
Denn in größeren Unternehmen stößt man genau an diesem Punkt auf Probleme.
Als Beispiel nehmen wir an, es existiert eine Benutzergruppe mit 4.950 Benutzern. Das mehrwertige Attribut Member des
Gruppenobjekts enthält somit 4.950 Einträge. Im Attribut Member sind die Distinguished Names der einzelnen Mitglieder aufgelistet.
Das können Einträge von Benutzern, anderen Gruppen oder Computern sein. Im Benutzerobjekt hingegen befinden sich die
Einträge der Gruppenmitgliedschaften im mehrwertigen Attribut MemberOf. Wenn nun dieser Benutzergruppe ein weiterer Benutzer
hinzugefügt wird, werden alle 4.951 Einträge im Attribut Member auf die anderen DCs repliziert und nicht nur der einzig
hinzugekommene Eintrag. Schließlich wird auf Attribut- und nicht auf der Wert-Ebene repliziert.
In einem anderen Beispiel gehen wir davon aus, dass eine Benutzergruppe simultan auf zwei DCs verändert wird.
Es existiert eine GruppeA mit den Benutzern: User1 und User2. Administrator1 fügt der GruppeA einen neuen Benutzer User5
hinzu und zeitgleich fügt Administrator2 auf einem anderen DC User9 hinzu. Somit kommt es zu einem Replikationskonflikt,
wobei eines der Änderungen verworfen wird.
Das Member- und MemberOf-Attribut stellen zusammen ein Linked-Attribut (verknüpftes Attribut) Paar dar.
Linked-Attribute stellen eine besondere Beziehung im Active Directory zueinander dar, denn sie bestehen aus zwei Attributen,
dem Forward- sowie Back-Link. Verändert der Administrator im Forward-Link einen Wert, aktualisiert das Active Directory
automatisch den Back-Link. Das beinhaltet natürlich auch das Löschen von Werten.
Das Member-Attribut im Gruppenobjekt ist ein Forward-Link und das Attribut MemberOf eines Benutzerobjekts stellt den Back-Link dar.
Back-Links werden von jedem DC selbst verwaltet und können auch nicht vom Administrator bearbeitet werden. Es ist ein sogenanntes
system-only Attribut und wird auch nicht auf andere DCs repliziert. Ein Back-Link und sein Wert werden zum Zeitpunkt der Abfrage generiert.
Solche Attribute tragen den Namen "constructed". Der Administrator kann nur den Forward-Link, in dem Fall dass
Member-Attribut eines Gruppenobjekts das auf andere DCs repliziert wird bearbeiten.
Neben dem unnötigen Replikationsaufkommen unter Windows 2000 kommt noch hinzu, dass eine Benutzergruppe mit mehr
als 5.000 Mitgliedern nicht unterstützt wird. Diese Grenze von 5.000 kommt daher, weil eine Aktualisierung im Active Directory
in einem einzigen Vorgang durchgeführt werden muss und eben dabei ca. 5.000 Werte aktualisiert werden können.
Anders ausgedrückt, die Active Directory Jet Database Engine kann lediglich mit einer bestimmten Anzahl an Werten
während eines Schreibvorgangs bzw. eines Replikationszyklus umgehen.
In größeren Umgebungen kann aber diese Grenze von 5.000 Mitgliedern pro Benutzergruppe ein Problem darstellen.
Der Weg diese Barriere zu umgehen wäre mit Gruppenverschachtelungen zu arbeiten.
Daraufhin wurde im Windows Server 2003 dieses Verhalten verbessert. Microsoft hat die sogenannte Linked-Value Replikation
(zu Deutsch, verknüpfte Wertreplikation) eingeführt. Mit dieser Funktion wird nur noch der geänderte Wert eines
mehrwertigen Attributs repliziert, aber nicht mehr die unveränderten Werte. Die AD-Replikation findet nun auf der Wert-Ebene statt.
Diese neue Funktion trägt sowohl zur effizienteren Replikation, als auch der Konfliktvermeidung eines mehrwertigen Attributs bei.
Bei der LVR-Replikation werden bei einem Objekt zuerst die nicht verknüpften Attribute (non-Linked Attributs) und anschließend
die verknüpften Attribute (Linked Attributes) repliziert.
Im oben genannten ersten Beispiel mit den 4951 Mitgliedern einer Benutzergruppe, würde durch die LVR-Replikation lediglich
der geänderte Wert (der hinzugekommene Benutzer) repliziert werden und nicht mehr alle Werte. Auch unter Windows NT
würde der PDC lediglich den veränderten Wert zum BDC übertragen.
Im zweiten Beispiel wären die Benutzer: User1, User2, User5 und User9 nach der LVR-Replikation in der GruppeA.
Die Linked Value Replikation ist aber erst verfügbar, wenn sich der Gesamtstrukturfunktionsmodus auf Windows Server 2003 Interim
oder Windows Server 2003 befindet. Nur dann kommt die verbesserte Replikationstechnik zum Einsatz.
Somit wird auch die künstliche Grenze von 5.000 Mitgliedern pro Benutzergruppe aufgehoben.
Eine Gruppe im Gesamtstrukturfunktionsmodus Windows Server 2003 kann im sieben stelligen Bereich Mitglieder enthalten.
Allerdings ist die unterstützte Anzahl der Änderungen die innerhalb eines Schreibvorgangs durchgeführt werden können 5.000.
Denn wenn z.B. per Skript oder Management-Tool eine Gruppe mit weit mehr als 5.000 Mitgliedern erstellt wird, läuft man Gefahr
einen „out of version store“-Fehler zu erhalten. Daher sollte beim automatisierten einrichten von Gruppen darauf geachtet werden,
diesen Wert nicht zu überschreiten.
Als Bestätigung, dass nach dem Heraufstufen der Gesamtstruktur auf Windows Server 2003 nun die LVR-Replikation eingesetzt wird,
findet man im Verzeichnisdienstprotokoll aller Domänencontroller in der Gesamtstruktur die EventID 1695.
Leider profitieren aber die bereits bestehenden Werte in einem mehrwertigen Attribut nach dem Heraufstufen der Gesamtstruktur
nicht von der LVR-Replikation. Lediglich neu hinzugekommene Werte in diesem Modus nutzen den Vorteil der LVR-Replikation.
Überprüfen lässt sich das mit dem Tool Repadmin, das sich in den Windows Support Tools befindet.
Gibt man in einer Kommandozeile den folgenden Befehl ein: Repadmin /showobjmeta <DC-Name> <DN der Gruppe>
erscheint eine Ausgabe die wie folgt aussieht:
Entscheidend dabei ist die Spalte Type. Der Eintrag LEGACY zeigt, dass dieser Wert vor dem Heraufstufen der Gesamtstruktur bereits existierte.
Somit profitiert dieser Wert nicht von der LVR-Replikation.
Im nächsten Schritt wird der bestehenden Gruppe ein weiterer Benutzer hinzugefügt.
Es ist zu erkennen, dass in der Spalte Type bei User11 der Status sich auf PRESENT befindet. Da dieser Eintrag im
Gesamtstrukturfunktionsmodus Windows Server 2003 hinzugefügt wurde, profitiert der Wert auch von der LVR-Replikation.
Ein weiterer Status wäre ABSENT. Dieser Eintrag wird angezeigt, wenn ein Mitglied im Gesamtstrukturfunktionsmodus
Windows Server 2003 zu einer Gruppe hinzugefügt und entfernt wurde.
Wenn ein Benutzerobjekt aus dem Active Directory gelöscht wird, ist die Wiederherstellung samt Gruppenmitgliedschaften
eine heikle Angelegenheit. Wenn es sich aber um eine Windows Server 2003 SP1 Umgebung handelt, erleichtert einem das
NTDSUTIL bei der Wiederherstellung der Informationen von Gruppenmitgliedschaften das Leben. Denn die Wiederherstellung
von Gruppenmitgliedschaften basiert auf LDAP Data Interchange Format (LDIF) Dateien. Der genaue Vorgang wird im folgenden Artikel beschrieben.
How to restore deleted user accounts and their group memberships in Active Directory
Damit alle Werte eines mehrwertigen Attributs von der LVR-Replikation profitieren, ist es notwendig alle Werte neu zu schreiben.
Dazu müssen die Werte zuerst entfernt und anschließend erneut hinzugefügt werden.
Neben skriptbasierten Lösungen kann einem das LDIFDE behilflich sein oder aber die im Windows Server 2003
enthaltenen Tools DSGET und DSMOD. Mit diesem Befehl werden alle Werte neu geschrieben:
Dsget group <DN der Gruppe> -members | Dsmod group <DN der Gruppe> -chmbr
Active Directory - Abfrage
Anschließend werden mit der Abfrage von Repadmin, alle Werte im Attribut Member mit dem Status PRESENT angezeigt.
Weitere Informationen:
Verknüpfte Attribute
How to raise domain and forest functional levels in Windows Server 2003
Group Objects (Windows)
Microsoft Windows 2000 Scripting Guide - Modifying Multivalued Attributes
Enumerating Groups That Contain Many Members (Windows)
Seit Windows Server 2003 ist es möglich einen Server mit Hilfe einer Systemstatus-Sicherung (System State) von einem
bestehenden Domänencontroller (DC), durch die Install from Media (IFM) Funktion, zu einem zusätzlichen DC hochzustufen.
Diese Art des Heraufstufens zu einem DC bietet sich in den Fällen an, in denen ein Server an einem entfernten Standort zum
DC heraufgestuft werden soll und vor Ort nur eine geringe Bandbreite zur Verfügung steht. Damit dann eben nicht die gesamte
Active Directory-Datenbank (NTDS.dit) über die schmale Leitung repliziert werden muss, kann das Volumen der Replizierung Dank
der Sicherung gering gehalten werden. Es werden lediglich die Änderungen die seit der Sicherung stattgefunden haben über
die Leitung repliziert. Dadurch hat die IFM-Funktion zum einen den Vorteil, dass weniger Netzwerkressourcen in Anspruch
genommen und zum anderen, dass der Domänencontroller früher bereitgestellt werden kann.
So kann nun ein Server in der Zentrale installiert und an den Standort verschickt werden, ohne ihn vorher zum DC zu stufen.
Damit wäre sichergestellt, dass auf dem Weg zum Ziel-Ort der DC (und somit die Domäne bzw. Gesamtstruktur)
nicht kompromittiert werden kann. Auf einem anderen Weg kann dann das Sicherungsmedium auf dem die
Systemstatus-Sicherung enthalten ist, getrennt vom Server verschickt werden.
Ganz wichtig ist aber, wenn das Sicherungsmedium auf dem sich die Systemstatus-Sicherung befindet an einen
anderen Ort versandt werden sollte (auf welchem Weg auch immer), ist die gleiche Sicherheit zu gewährleisten,
wie bei einem Transport eines DCs. Denn in der Systemstatus-Sicherung befinden sich unter anderem sämtliche
Kennwörter der Domäne sowie die Objekt-SIDs.
Nach dem Heraufstufen müssen zusätzliche Aufgaben weiterhin ausgeführt werden, wie z.B. den DNS Dienst zu installieren.
Einen zusätzlichen DC in die Domäne hinzufügen
IFM unter Windows Server 2003
Diese Art des Heraufstufens zu einem DC, ist nur bei einem zusätzlichen Domänencontroller einer bereits existierenden Domäne möglich!
Die Sicherung des Systemstatus muss von einem Windows Server 2003 DC aus der gleichen Domäne stammen.
Dabei kann eine Sicherung von einem bestehenden Windows 2000 DC nicht als Grundlage dienen!
Des Weiteren wird die IFM-Funktion bei Nutzung einer Sicherung eines 32Bit DCs, dass als Grundlage für das Heraufstufen
eines 64Bit Servers dienen soll nicht unterstützt. Das gleiche gilt auch im umgekehrten Fall.
Zum Sichern des Systemstatus eignet sich das im Betriebssystem enthaltene Sicherungsprogramm NTBACKUP.
Mit dem Sichern des Systemstatus werden die folgenden Elemente gesichert:
- Active Directory (NTDS.dit)
- Systemstart Dateien
- COM+ Datenbank zur Registrierung von Klassen
- Registry
- SYSVOL
- Falls eine CA auf dem DC installiert wäre, dann auch diese
In der Praxis ist es für den Administrator hilfreich, wenn er bereits im Dateinamen der Sicherungsdatei erkennen kann,
welche Informationen in der Sicherung enthalten sind. Im Dateinamen könnte sich z.B. der FQDN, SP-Stand, GC und das Datum
des gesicherten DCs befinden. Wichtig ist das Datum, denn die Sicherung darf nur solange verwendet werden,
bis die Tombstone Lifetime (TSL) ausläuft. Die Tombstone Lifetime beträgt in den meisten Umgebungen 60 Tage.
Erst wenn beim Erstellen einer Gesamtstruktur, der erste DC ein Windows Server 2003 SP1 ist, beträgt die TSL 180 Tage.
Es ist darauf zu achten das beim Heraufstufen mit der IFM-Funktion, der Ziel-Server auf dem gleichen Service Pack-Stand
wie der Quell-DC ist. Damit der neue Server zu einem zusätzlichen DC gestuft werden kann, benötigt er zum Zeitpunkt der
Ausführung von DCPROMO eine bestehende Namensauflösung. Dazu ist ein bestehender DNS-Server in den TCP/IP-Einstellungen
einzutragen, der natürlich während dem Heraufstufen erreichbar sein muss. Es ist wohl naheliegend das der Server eine Verbindung
zu der Domäne dem er hinzugefügt werden soll haben muss, damit er unter anderem den Träger der FSMO-Rollen (z.B. RID-Master)
erreichen kann.
Sollen die bestehenden Anwendungsverzeichnispartitionen wie es z.B. DomainDNSZones oder ForestDNSZones darstellen,
ebenfalls mit der IFM-Funktion bereitgestellt werden, muss der Quell-DC mindestens das Service Pack 1 installiert haben.
Zusätzlich muss sich der Gesamtstrukturfunktionsmodus auf Windows Server 2003 befinden.
Wenn auf dem neuen DC auch der globale Katalog (GC) aktiviert werden soll, können die Daten eines GCs ebenfalls mit der
IFM-Funktion bereitgestellt werden. Dazu muss auf dem Quell-DC auf dem die Sicherung durchgeführt werden soll,
ebenfalls der GC aktiviert sein.
Die Sicherungsdatei in der die Systemstatus-Sicherung enthalten ist, muss wiederhergestellt werden. Ein simples Hineinkopieren
der Sicherungsdatei auf ein lokales Laufwerk reicht nicht aus. Die wiederhergestellten Systemstatusdateien könnte man auf eine
CD/DVD oder auf einen USB-Stick/HDD kopieren. Anschließend kann beim Ausführen des Active Directory-Assistenten DCPROMO
auf das entsprechende Medium verwiesen werden. Wichtig ist, dass es sich dabei um ein lokales Laufwerk handelt.
Das Auswählen der Systemstatusdateien über die Angabe eines UNC-Pfads oder ein verbundenes Netzlaufwerk, wird nicht unterstützt.
Sollen die Systemstatusdateien auf dem Ziel-Server wiederhergestellt werden, ist darauf zu achten die Wiederherstellung
in ein alternatives Verzeichnis und keinesfalls an den ursprünglichen Bereich durchzuführen. Nach dem Heraufstufen sollte
dieses temporäre Verzeichnis gelöscht werden. Wenn stattdessen die Dateien an ihren Ursprungsort wiederhergestellt werden,
können das System und das AD irreparable Schäden annehmen. Denn mit Rücksichern der Systemstatusdateien wird auch die
Registry wiederhergestellt, in der bekanntlich nicht nur Hardware- sowie Treiberinformationen enthalten sind, sondern auch der Computername.
Auf dem Ziel-Server muss das Dcpromo mit dem Parameter /ADV (für Advanced) zum Heraufstufen aufgerufen werden.
Erst mit diesem Befehl ist es möglich, eine Sicherung anzugeben.
Die einzelnen Schritte unter Windows Server 2003, können in diesem Artikel nachgelesen werden:
How to use the Install from Media feature to promote Windows Server 2003-based domain controllers
IFM unter Windows Server 2008
Die IFM-Option ist weiterhin auch unter Windows Server 2008 verfügbar. Wobei nun unter Windows Server 2008 der
erweiterte Schalter /ADV (der weiterhin funktioniert) in den Dcpromo-Assistenten eingebaut wurde. Direkt beim Aufruf von Dcpromo
lässt sich auf der Willkommens-Seite die Option Installation im erweiterten Modus verwenden aktivieren.
Während unter Windows Server 2003 eine Sicherung des Systemstatus z.B. mit Ntbackup erstellt werden muss, wird das nun
unter Windows Server 2008 mit NTDSUTIL erledigt. Denn das Ntbackup existiert nicht mehr unter Windows Server 2008.
Zum erstellen einer Sicherung gilt es folgende Schritte durchzuführen:
-
In einer Kommandozeile oder über Start-Ausführen gilt es zuerst NTDSUTIL zu starten.
-
Als nächstes muss die NTDS-Instanz aktiviert werden.
Dieses erreicht man durch die Eingabe von Activate Instance NTDS.
-
Mit Eingabe von IFM gilt es auf die Install from Media-Ebene zu gelangen.
-
Dort angelangt, kann nun die IFM-Sicherung erstellt werden.
-
Erstellt man die IFM-Sicherung auf einem beschreibbaren DC, so können Sicherungsmedien für einen beschreibbaren
DC oder für einen RODC erstellt werden. Man kann dabei wählen, ob jeweils das SYSVOL-Verzeichnis mit gesichert
werden soll oder nicht.
-
Wird hingegen die IFM-Sicherung auf einem RODC erstellt, kann ausschließlich das Sicherungsmedium für einen RODC erstellt
werden und nicht für einen beschreibbaren DC. In der erstellten IFM-Sicherung werden dabei alle replizierten Kennwörter entfernt.
-
Auf einem Server Core können die gleichen IFM-Sicherungen erstellt werden, wie auf einem beschreibbaren DC.
Wird das SYSVOL-Verzeichnis nicht mit gesichert, wird es beim Heraufstufen eines DCs über die Leitung repliziert.
Unter Windows Server 2008 ist es jetzt möglich, IFM-Sicherungen auf einem 32Bit System zu erstellen, um diese als Grundlage
auf einem 64Bit System zu nutzen. Im umgekehrten Fall ist das ebenfalls möglich. Eine IFM-Sicherung die auf einem 64Bit System
erstellt wurde, kann auf einem 32Bit System verwendet werden.
Beim Erstellen eines Sicherungsmediums kommt die Volume Shadow Copy Service (VSS) Technologie zum Einsatz.
Im laufenden Betrieb wird ein Snapshot von der Active Directory-Datenbank erstellt und anschließend offline defragmentiert.
Die IFM-Sicherung die auf einem beschreibbaren DC erstellt wurde, kann zum Heraufstufen eines beschreibbaren DC,
RODC oder für eine Active Directory Lightweight Directory Services (AD LDS, ehemals ADAM) Instanz verwendet werden.
Weitere Informationen:
Error message when you try to create a RODC IFM in Windows Server 2008 if an earlier IFM procedure was canceled or has closed unexpectedly: “Could not initialize the Jet engine: Jet Error -1216”
… please fasten your Seat Belts. We are ready.for.take.off.
So langsam geht es zum Endspurt.
Es ist noch knapp einen Monat Zeit, um sich für den bisher größten Event den Microsoft in Deutschland veranstaltet anzumelden.
Wer also dabei sein möchte – was ich jedem nur ans Herz legen kann – der sollte sich diesen Launch nicht entgehen lassen.
Vom 19. bis 21. Februar 2008 findet in Frankfurt am Main der Launch zu Windows Server 2008, SQL Server 2008 sowie Visual Studio 2008 statt.
In der frühen Planungsphase hatten sich die Veranstalter das insgeheime Ziel gesetzt, dass berühmt berüchtigte TechED IT-Forum
in der Besucheranzahl zu toppen. Die Antwort darauf folgt von Michael Korp (Technical Evangelist, Microsoft).
Zitat:
Ein Ziel haben wir inzwischen erreicht: Der Launch hat schon mehr angemeldete Teilnehmer
als die im Schwerpunkt europäische Veranstaltung TechEd IT-Forum.
http://blogs.technet.com/mkorp/archive/2008/01/07/ein-frohes-neues-jahr.aspx
Neben den hochkarätigen Vorträgen werde ich mit einer Armada an MVP-Kollegen als Ask the Expert (ATE) dabei sein.
Wer mir neben Active Directory-Fragen, weitere Fragen zum Windows Server 2008 oder gar mich persönlich kennenlernen möchte,
der kann mich am ATE-Stand treffen. Ich würde mich auf ein Treffen freuen.
Da der Launch quasi vor meiner Haustür stattfindet, werde ich an allen drei Tagen vor Ort sein.
Parallel findet die Deutsche Sharepoint Konferenz 2008 statt.
Egal für welche Konferenz man sich entscheidet, die Anmeldung erfolgt über diese Seite (solange noch Plätze frei sind):
http://www.microsoft.com/germany/aktionen/ready-for-take-off/default.aspx
Wir sehen uns in Frankfurt am Main.
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 /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.
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
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|