8.9 Upgrade der Gesamtstruktur auf Active Directory-Domänendienste (AD DS) 2008/2012/R2

Die meisten Leser werden bereits eine Active Directory-Umgebung auf Basis von Windows Server 2003 oder Windows Server 2008 einsetzen, insofern dürfte der Ablauf des Upgrades der Umgebung eine interessante Fragestellung sein.

In den nachfolgenden Abschnitten zeige ich Ihnen Schritt für Schritt die Vorgehensweise.

8.9.1 Schemaerweiterung und Anpassung der Domänen durchführen

Das Schema der Active Directory-Gesamtstruktur muss für die Verwendung von Windows Server 2012/R2-Domänencontrollern erweitert werden – schließlich gibt es neue Klassen und Attribute.

Die Anpassung ist nicht schwierig. Wenn man es professionell machen möchte, sind allerdings ein paar Gedanken zu einem Fallback-Szenario angebracht.

Gesamtstruktur (Forest)

Es wird empfohlen, dass vor der Erweiterung des Schemas alle Domänencontroller mindestens auf dem Stand Windows Server 2003 mit aktuellem Patchlevel sein sollten. Ist dies nicht der Fall, ist zunächst das Einspielen von Service Packs angesagt.

Ansonsten sind im Grunde genommen drei Schritte auszuführen:

• Identifizieren des Schemamasters
• Fallback-Szenario vorbereiten
• Schemaerweiterung vornehmen

Schemamaster identifizieren

Eine Schemaerweiterung für Windows Server 2012 kann auf einem beliebigen Server der Gesamtstruktur durchgeführt werden, es muss weder ein Domänencontroller sein noch der Inhaber der FSMO-Rolle Schemamaster. Trotzdem ist es ganz interessant, den Schemamaster zu kennen, denn er muss zumindest online sein.

Falls Sie nur einen einzigen Domänencontroller haben, ist dieser notwendigerweise der Inhaber dieser Rolle. Man kann weiterhin davon ausgehen, dass der Schemamaster der erste jemals installierte DC ist. In einer größeren gewachsenen Umgebung, in der regelmäßig Hardware ausgetauscht wird (und in der die Dokumentationslage nicht ganz optimal ist), muss man gegebenenfalls feststellen, welches System tatsächlich diese Rolle innehat.

So wird es gemacht:

1. Registrieren Sie auf einem beliebigen Server das Schema-Manager-Snap-In. Dies geschieht durch Eingabe von regsvr32 schmmgmt.dll. Nach ein paar Sekunden müssten Sie die Bestätigung aus Abbildung 8.190 sehen.

   

   Abbildung 8.190 Zunächst muss das Schema-Manager-Snap-In registriert werden.

2. Öffnen Sie die Microsoft Management Console (MMC), und fügen Sie das Snap-In Active Directory-Schema hinzu. Wenn der vorherige Schritt funktioniert hat, müsste es in der Auswahlliste vorhanden sein (Abbildung 8.191).

   

   Abbildung 8.191 In der MMC können Sie nun das Snap-In »Active Directory-Schema« auswählen.

3. Im Kontextmenü des obersten Knotens des Snap-Ins findet sich der Menüpunkt Betriebsmaster. Dieser führt zu einem Anzeigedialog, in dem – wenig überraschend – der derzeitige Schemamaster angezeigt wird (Abbildung 8.192).

   

   Abbildung 8.192 Der aktuelle Schemamaster kann mit dem Snap-In angezeigt werden.

Ein Fallback-Szenario planen und umsetzen

Man kann zwar eigentlich davon ausgehen, dass die Schemaerweiterung problemlos funktionieren wird – als Profi wird man aber nicht allein auf das »Prinzip Hoffnung« setzen, sondern ein Fallback-Szenario einplanen. Das Fallback-Szenario ist dann relativ einfach umzusetzen, wenn Sie mehrere Domänencontroller (mindestens zwei) haben und zumindest einer davon nicht mit zig Zusatzfunktionen überfrachtet ist.

Ein mögliches Szenario sieht wie folgt aus:

1. Trennen Sie den Server mit der Schemamaster-Rolle vom Netz.
2. Erzeugen Sie ein Image – ein Image kann am schnellsten wieder zurückgespielt werden.
3. Führen Sie die Schemaerweiterung durch; wohlgemerkt ohne dass der Server Verbindung zum Netz hat.
4. Überprüfen Sie den Zustand des Systems nach der Schemaerweiterung:
   • Schauen Sie in die Ereignisanzeige, ob Meldungen aufgezeichnet worden sind.
   • Überprüfen Sie den Domänencontroller mittels DCdiag.
5. War die Schemaerweiterung erfolgreich, verbinden Sie den Server wieder mit dem Netz. War die Schemaerweiterung nicht erfolgreich, sichern Sie das Image zurück und verbinden den Server dann mit dem Netz.

Durch das Trennen der Netzwerkverbindung erreichen Sie, dass die Änderungen während des Updates direkt auf alle Domänencontroller der Organisation repliziert werden. Wird der Schemamaster nach erfolgreicher Schemaerweiterung wieder an das Netz angeschlossen, werden die Änderungen angewendet, ohne dass Sie das manuell initiieren müssten.

Schemaerweiterung durchführen

Das Durchführen der Schemaerweiterung wird von der Applikation adprep.exe übernommen, die auf der Windows Server 2012-CD im Verzeichnis \support\adprep gespeichert ist (bei früheren Versionen lag sie im Verzeichnis \sources\ ..., ist in der 2012er-Generation aber umgezogen). Der Aufruf lautet adprep.exe /forestprep. Sie werden noch eine Warnung bezüglich der Mindest-Betriebssystem-Version, nämlich Windows 2003-Domänencontroller, bestätigen müssen – und dann läuft der Vorgang (Abbildung 8.193). Die Durchführung dauert einige Minuten. Bis die Schemaerweiterung in einer sehr großen und verteilten Organisation auf allen DCs übernommen worden ist, können durchaus mehrere Stunden vergehen.

Abbildung 8.193 Die Schemaerweiterung mittels »adprep.exe /forestprep«

Domänen

Im nächsten Schritt werden nacheinander alle Domänen angepasst. Die Vorgehensweise ist in etwa die gleiche – mit zwei Unterschieden:

• Sie müssen die Anpassung nicht auf dem jeweiligen Infrastrukturmaster der Domäne durchführen. Dieser Domänencontroller muss aber online sein. Wie Sie diesen ermitteln, sehen Sie in Abbildung 8.194.
• Der Aufruf des Programms lautet adprep.exe /domainprep (Abbildung 8.195). Auf der Abbildung sehen Sie, dass auch direkt eine untergeordnete Domäne vorbereitet wurde.

Abbildung 8.194 Ermitteln der Domänencontrollers mit der Rolle »Infrastrukturmaster«

Abbildung 8.195 Durchführung von »/domainprep«

Auch das zuvor beschriebene Fallback-Szenario funktioniert analog – nur eben mit dem Server, der die Infrastrukturmaster-Rolle der Domäne ausführt.

Vorbereitung der Verwendung von Read-Only-Domänencontrollern (RODC)

Falls Sie beabsichtigen, Read-Only-Domänencontroller (RODC) zu verwenden, müssen Sie noch adprep /rodcprep ausführen. Hierbei werden insbesondere Rechte für die Gruppe Domänencontroller der Organisation ohne Schreibzugriff hinzugefügt.

8.9.2 Windows Server 2012 R2-Domänencontroller installieren

Nachdem Sie die diversen vorbereitenden Maßnahmen mit adprep durchgeführt haben, können Sie den ersten Windows Server 2012 R2-Domänencontroller installieren. Installieren Sie hierzu einen Windows Server 2012 R2, und nehmen Sie ihn in die bestehende Domäne auf. Es muss wohl nicht weiter erwähnt werden, dass feste IP-Adressen und dergleichen mehr bei der Netzwerkkonfiguration eines Servers vorausgesetzt werden.

Wie Sie vermutlich bereits wissen, werden einem Windows Server 2012 R2 eine oder mehrere Rollen zugewiesen, die er ausführen soll. In diesem Fall handelt es sich um die Rolle Active Directory-Domänendienste. Beim Hinzufügen gehen Sie wie folgt vor:

1. Wählen Sie im Server-Manager das Hinzufügen einer neuen Rolle (Abbildung 8.196).

   

   Abbildung 8.196 Das Hinzufügen von Rollen im Server-Manager beginnt hier.

2. Aus den 17 hinzufügbaren Rollen wählen Sie die Active Directory-Domänendienste (Abbildung 8.197).
3. Kurze Zeit später wird der Assistent die Fertigstellung der Installation melden, allerdings ist die Maschine noch kein Domänencontroller. Die Installation der Rolle ermöglicht zunächst nur, dass man im folgenden Schritt den Assistenten starten kann, um den Server zum DC zu machen (Abbildung 8.198).

Abbildung 8.197 Wählen Sie die Rolle »Active Directory-Domänendienste« zum Hinzufügen aus.

Abbildung 8.198 Nach Abschluss der Installation müssen Sie den Assistenten starten.

Zur eigentlichen Installation der Domänencontroller-Funktionalität rufen Sie aus dem Servermanager heraus den AD-Assistenten auf. Früher ging das über die Kommandozeile mit dem Programm dcpromo.exe, in Server 2012 gibt es das aber nicht mehr. Sie werden nun mittels eines Assistenten durch die Installation des neuen Domänencontrollers geführt. Im Folgenden gebe ich einige Hinweise zum Installationsablauf:

1. Zunächst möchte der Assistent wissen, ob Sie eine vorhandene Domäne erweitern, eine neue Domäne in einer vorhandenen Gesamtstruktur oder eine neue Gesamtstruktur anlegen wollen. Da es bei diesem Beispiel um eine Migration einer bestehenden Domäne geht, wählen Sie natürlich die Einstellung aus Abbildung 8.199.
2. Gleichzeitig wählen Sie die Domäne aus, der der neue Domänencontroller hinzugefügt werden soll.
3. Der Assistent wird die Gesamtstruktur einer kurzen Prüfung unterziehen und gefundene Probleme melden. Beachten Sie, dass das keine »Tiefenanalyse«, sondern eine eher oberflächliche Kontrolle ist, die das Ziel hat, die zur Verfügung stehenden Installationsmöglichkeiten (z. B. Read Only-Domänencontroller) zu bestimmen.

   

   Abbildung 8.199 Ausführung des Assistenten: Zunächst wird festgelegt, dass der Domänencontroller ein zusätzlicher DC einer vorhandenen Domäne sein soll.

4. Im nächsten Schritt wird ermittelt, welchem Standort der Domänencontroller zugeordnet werden soll (Abbildung 8.200). Im Normalfall wird die Auswahl des Standorts anhand der IP-Adresse vorgenommen, was die Voreinstellung ist.
5. Auf der Dialogseite können Sie festlegen, ob der Domänencontroller zusätzlich ein globaler Katalogserver sein soll. Weiterhin können Sie direkt einen DNS-Server installieren lassen.

   Prinzipiell könnten Sie auch entscheiden, dass der DC als schreibgeschützter Domänencontroller (RODC) installiert werden soll.

   Da bei einer Migration der Domäne auf Windows Server 2012 R2-DCs das Ziel darin bestehen dürfte, die alten DCs möglichst zeitnah abzuschalten, macht es Sinn, auf den neuen Domänencontrollern sowohl den DNS-Server zu installieren als auch sie zum globalen Katalogserver zu machen.

6. Notwendig ist weiterhin das Festlegen eines Kennworts für den Wiederherstellungsmodus. Hierbei ist vor allem eines wichtig: die Dokumentation des gewählten Kennworts. Es ist wenig optimal, wenn irgendwann tatsächlich eine Wiederherstellung vorgenommen wird und das Kennwort nicht vorliegt.

   

   Abbildung 8.200 Der DC wird einem Standort zugewiesen. Außerdem wird festgelegt, ob er ein globaler Katalogserver und ein DNS-Server sein soll.

7. Es ist möglich, dass Sie bei der vom Assistenten vorgenommenen Installation des DNS-Servers die Meldung aus Abbildung 8.201 erhalten. Sie besagt, dass die übergeordnete Zone nicht erreichbar ist und somit keine Delegierung erstellt werden kann. Im Fall dieses Beispiels gibt es keine übergeordnete Domäne (ubinf.intra hat keine übergeordnete Domäne), sodass die Fehlermeldung nicht berücksichtigt werden muss.
8. Neu seit Server 2012 ist der auf Abbildung 8.202 gezeigte Dialog. Hier können Sie dediziert den Domänencontroller angeben, der für die erste Replikation verwendet werden soll. Dies hat nichts mit der später vom KCC aufgebauten Replikationstopologie zu tun!

   

   Abbildung 8.201 Diese Warnung bezüglich der DNS-Konfiguration können Sie ignorieren.

   

   Abbildung 8.202 Der Replikationspartner für die Erstreplikation wird bestimmt.

9. Im folgenden Dialog geht es um die Auswahl des Speicherorts für die Datenbank, die Logdateien und SYSVOL.

   Vertreter der »reinen Lehre« tendieren dazu, alle Arten von Bewegungsdaten, zu denen man letztendlich auch die AD-Datenbanken zählen kann, eben nicht auf die C-Platte zu legen. In der Praxis kenne ich aber so gut wie keine Installation, bei der diese Active Directory-Dateien nicht auf dem C:-Laufwerk lägen.

   Auch wenn es prinzipiell nicht ganz perfekt ist, lautet die Empfehlung also: Bestätigen Sie die Standardpfade – so ist die Installation auch für jeden sofort verständlich (Abbildung 8.203, links).

Abbildung 8.203 Auswahl des Speicherorts für Datenbanken und des Kennworts für den Wiederherstellungsmodus

Wenn Sie alle Eingaben vorgenommen haben, kann die eigentliche Installation bzw. das Aktivieren der Domänencontrollerfunktionalität beginnen. Dies wird einige Minuten in Anspruch nehmen. Wenn alles glattgelaufen ist, ist der erste Windows Server 2012-Domänencontroller in Ihrer Gesamtstruktur aktiv. Er wird sich nahtlos integrieren, mit den bereits vorhandenen DCs synchronisieren und Anmeldeanfragen bearbeiten.

Die Fortschrittsanzeige ist jetzt etwas »dezenter« gestaltet als in den Vorgängerversionen (siehe den Pfeil in Abbildung 8.204).

Abbildung 8.204 Die eigentliche Installation der Domänencontrollerfunktionalität geschieht ohne weitere Admin-Eingaben.

8.9.3 Kurze Überprüfung

Nach der Installation und bevor Sie mit den nächsten Schritten beginnen, empfiehlt es sich, eine kurze Überprüfung des neuen Domänencontrollers vorzunehmen. Dazu ist natürlich das DCdiag-Werkzeug die erste Wahl. Es wird von der Kommandozeile gestartet und führt eine recht detaillierte Analyse durch.

Daneben gibt es noch weitere Möglichkeiten, um sich schnell zu vergewissern, dass alles in Ordnung ist.

Wenn Sie den Server-Manager öffnen und in den Anzeige- und Konfigurationsbereich einer installierten Rolle wechseln, sehen Sie direkt eine gefilterte Ansicht, die die Ereignisse anzeigt, die im Zusammenhang mit der Rolle aufgetreten sind (Abbildung 8.205).

Die Verwaltungswerkzeuge, wie Active Directory-Benutzer und –Computer, ermöglichen die Auswahl des Domänencontrollers, auf dem gearbeitet wird. Sie können also zunächst prüfen, ob der neue Server in der Liste auftaucht, und ihn gezielt anwählen, um zu kontrollieren, ob die Informationen auch auf den neuen DC repliziert wurden (Abbildung 8.206).

Es ist zwar nicht anzunehmen, dass es hier Probleme geben wird, aber eine kleine Überprüfung kann ja nicht schaden.

Abbildung 8.205 Im Server-Manager werden die zu einer Rolle gehörigen Ereignisse in einer gefilterten Ansicht angezeigt.

Da Sie vermutlich auf dem neuen Windows-Server-2012-Domänencontroller auch den DNS-Server installiert haben, kann eine kleine Kontrolle dort auch nicht schaden. Es gibt drei Punkte, die Sie überprüfen sollten:

• Eine detaillierte Analyse der DNS-Konfiguration können Sie mit dem DCdiag-Werkzeug durchführen. Der Aufruf lautet DCdciag /test:dns.
• Eine Zusammenfassung der DNS-Server-Ereignisse erhalten Sie, wenn Sie die entsprechende Rolle im Server-Manager öffnen (vergleichen Sie auch Abbildung 8.206).

  

  Abbildung 8.206 Bei der Auswahl eines Verzeichnisservers wird der Windows-Server-2012-Domänencontroller ebenfalls zur Auswahl angeboten.

• Es macht auf jeden Fall Sinn, auch einmal ganz pragmatisch in das DNS-Konfigurationswerkzeug zu schauen. Überzeugen Sie sich, dass die DNS-Einträge der Zonen, die von Active Directory verwendet werden, bereits repliziert worden sind (Abbildung 8.207).

  

  Abbildung 8.207 Der DNS-Server verfügt bereits über Replikate der Active Directory- integrierten Zonen.

8.9.4 FSMO-Rollen verschieben

Der neue Domänencontroller wird jetzt gemeinsam mit den vorhandenen Windows Server-2003-Maschinen seine Arbeit verrichten. Gegebenenfalls werden Sie noch weitere Windows-Server-2012/R2-Domänencontroller hinzufügen. Sofern das Ziel ist, die vorhandenen Windows-Server-2003-Maschinen abzulösen, müssen zunächst die FSMO-Rollen – sowohl die beiden gesamtstrukturübergreifenden (Schemamaster und Domänennamenmaster) als auch die drei domänenweiten Rollen – verschoben werden.

RID, PDC und Infrastruktur

Sie verschieben die drei Domänen-FSMO-Rollen mit dem Snap-In Active Directory-Benutzer und -Computer. Gehen Sie wie folgt vor:

1. Verbinden Sie sich mit dem Domänencontroller, der die Funktion übernehmen soll.
2. Rufen Sie im Kontextmenü der Domäne den Menüpunkt Betriebsmaster auf (Abbildung 8.208).

   

   Abbildung 8.208 Das Verschieben der Domänen-FSMO-Rollen wird im Snap-In »Active Directory-Benutzer und -Computer« durchgeführt.

3. Wählen Sie die Registerkarte der zu verschiebenden FSMO-Rolle, und klicken Sie todesmutig auf Ändern (Abbildung 8.209).
4. Die erfolgreiche Übertragung der Betriebsmasterfunktion wird augenblicklich bestätigt.

Abbildung 8.209 Die drei FSMO-Rollen müssen einzeln übertragen werden. Diese Meldung bestätigt das erfolgreiche Verschieben.

Schemamaster

Das Verschieben der FSMO-Rolle Schemamaster funktioniert prinzipiell genauso einfach, allerdings werden Sie nach einer Standardinstallation das benötigte Werkzeug nicht vorfinden. Die DLL-Datei für das Schema-Manager-Snap-In ist zwar auf dem Server vorhanden, aber nicht registriert und folglich nicht in der MMC sichtbar und auswählbar.

Bevor Sie also die Schemamaster-FSMO-Rolle verschieben können, müssen Sie das Werkzeug registrieren, was mit dem Konsolenbefehl regsvr32 schmmgmt.dll erledigt wird. Das Ergebnis sehen Sie in Abbildung 8.210.

Wenn Sie das Snap-In aufgerufen haben, müssen Sie sich zunächst mit dem Domänencontroller verbinden, der die Funktion zukünftig übernehmen soll. Das Snap-In wird sich immer mit dem aktuellen Schemamaster verbinden – übrigens im Gegensatz zu anderen Snap-Ins wie ADBuC, die sich, sofern sie auf einem Domänencontroller gestartet werden, mit diesem, ansonsten aber mit einem beliebigen DC verbinden.

Rufen Sie den Menüpunkt Betriebsmaster auf, und verschieben Sie die Rolle durch einen Klick auf Ändern (Abbildung 8.211). Fertig!

Abbildung 8.210 Registrieren Sie das Schema-Management-Snap-In.

Nun wird das Snap-In in der MMC verfügbar sein.

Abbildung 8.211 So schön kann das Übertragen einer FSMO-Rolle sein.

Domänennamen-Master

Die zweite gesamtstrukturübergreifende FSMO-Rolle, nämlich Domänennamen-Master, wird mit dem Snap-In Active Directory-Domänen und -Vertrauensstellungen übertragen. Auch hier gibt es einen Menüpunkt Betriebsmaster, hinter dem sich der altbekannte Dialog verbirgt (Abbildung 8.212).

Abbildung 8.212 Die Domänennamen-Betriebsmaster-Funktion wird im Snap-In »Active Directory-Domänen und -Vertrauensstellungen« übertragen.

Nicht vergessen!

Vergessen Sie nicht, dass neben den FSMO-Rollen eventuell noch andere Dienste auf den Domänencontrollern laufen könnten. Ein beliebtes Beispiel sind die Zertifikatdienste. Überprüfen Sie also genau, was noch so alles auf den Domänencontrollern läuft. Das klingt trivial, ich kenne aber mehr als einen Fall, in denen die Gesichter nach der Deinstallation und dem Abschalten eines Domänencontrollers ziemlich lang waren.

Was gern und häufig übersehen wird, ist, dass die Domänencontroller im Allgemeinen auch Dienste wie DHCP, DNS und WINS zur Verfügung stellen. Beim Umzug von DNS und WINS müssen die IP-Adressen in den Clients angepasst werden. Finden die Clients keinen DNS-Server mehr, ist das Active Directory komplett unbrauchbar!

8.9.5 Alte Domänencontroller deinstallieren und einheitlichen Modus wählen

Wenn Sie alle Rollen und Dienste von den alten Domänencontrollern entfernt haben, können Sie dort die Domänencontroller-Dienste deinstallieren. Das geht durch einen Aufruf von dcpromo (die alten DCs sind ja 2008er-Systeme, und da nutzt man dcpromo).

Wenn keine Windows Server 2008- bzw. Windows 2003-Server-Domänencontroller vorhanden sind, können Sie die Domänenfunktionsebene und die Gesamtstrukturfunktionsebene heraufstufen. Wie das gemacht wird, ist in Abbildung 8.213 zu sehen.

Abbildung 8.213 Hinter diesen Menüpunkten verbirgt sich das Heraufstufen der Domänenfunktionsebene ...

Abbildung 8.214 ... und der Gesamtstrukturfunktionsebene.

8.9.6 Real-World-Troubleshooting – ein Beispiel

Das Problem eines Buches ist, dass es nicht jede in der Praxis auftretende Fehlersituation beschreiben und einen Lösungsansatz anbieten kann.

Ich möchte Ihnen stellvertretend für viele andere mögliche Probleme die Behandlung einer Fehlersituation exemplarisch vorführen – vielleicht ist das Szenario ja auf die Thematik übertragbar, an der Sie jetzt gerade verzweifeln.

Dieses Beispiel handelt letztendlich davon, was passiert, wenn ein Domänencontroller, zudem einer mit diversen FSMO-Rollen, nicht sauber heruntergestuft worden ist – sei es durch einen aufgetretenen Fehler oder sei es, dass der Administrator ihn einfach abgeschaltet und dann das Computerkonto im Snap-In Active Directory-Benutzer und -Computer gelöscht hat.

Fehler entdecken mit DCdiag und »adprep /rodcprep«

Nach dem Abschluss von Installations- bzw. Migrationsarbeiten empfiehlt es sich natürlich zu überprüfen, ob alle Parameter »im grünen Bereich« sind. Nach der Active Directory-Migration bietet sich beispielsweise eine Überprüfung mit dem Werkzeug DCdiag an. Ein Aufruf dieses Werkzeugs fördert die Fehlersituation aus Abbildung 8.215 zutage: Der Test NCSecDesc wurde nicht bestanden. Eine kurze Überprüfung der Microsoft-Dokumentation wird ergeben, dass diese Fehlermeldung zu erwarten ist:

• Falls kein schreibgeschützter Domänencontroller (RODC) verwendet werden soll, kann sie ignoriert werden.
• Falls ein RODC implementiert werden soll, können Sie die Konfiguration entsprechend anpassen, indem Sie adprep.exe /rodcprep aufrufen.

In dem nachgestellten Fehlerszenario schlägt der Vorgang adprep.exe /rodcprep allerdings zumindest teilweise fehl. Wie in Abbildung 8.216 zu sehen ist, gelingt es adprep nicht, die Partition ForestDnsZones anzupassen – es erscheint die lapidare Fehlermeldung, dass der angegebene Server den Vorgang nicht ausführen kann. Aha, jetzt sind wir deutlich schlauer.

Abbildung 8.215 »DCdiag« fördert einen Fehler zutage.

Abbildung 8.216 Hier hat »adprep /rodcprep« Probleme mit der »ForestDnsZones«-Partition.

Seit man mit Google Blogbeiträge finden kann, haben Fehlersituationen deutlich an Schreckenspotenzial eingebüßt, weil man davon ausgehen kann, dass irgendjemand schon einmal vor demselben Problem gestanden, es gelöst und seine Erkenntnisse veröffentlicht hat. Wenn es allerdings nur eine sehr allgemeine Fehlermeldung gibt, hilft Google verhältnismäßig wenig – ich habe dort jedenfalls zu diesem Problem keine heiße Spur entdecken können.

Der Weg zur Lösung

Wenn im Internet also keine »schnelle Standardlösung« zu finden ist, müssen Sie wohl oder übel selbst forschen. Die hier vorgestellten Schritte und Schlussfolgerungen werden natürlich nicht immer passen, zeigen aber die prinzipielle Herangehensweise.

Aus den Ausgaben von adprep /rodcprep kann man schließen, dass die »Situation« auf allen Active Directory-Partitionen mit Ausnahme von DC=ForestDnsZones,DC=ubinf,DC=intra in Ordnung ist. Eine genauere Betrachtung dieser Partition dürfte sich also lohnen.

Der allererste Schritt besteht darin, zu überlegen, wozu die Partition DC=For-estDnsZones,DC=ubinf,DC=intra überhaupt verwendet wird. Es handelt sich um eine seit Windows Server 2003 vorhandene Applikationspartition, die auf alle DNS-Server in der Gesamtstruktur repliziert ist (sofern diese gleichzeitig Domänencontroller sind, denn nur solche können Active Directory-integrierte Zonen verwenden). In dieser Active Directory-Zone sind etliche Verweise auf Domänen und Funktionen in der Gesamtstruktur gespeichert. Wenn die Partition sich im DNS-Manager öffnen lässt und dort vorhandene Einträge angezeigt werden können, ist sie zumindest vorhanden und im Zugriff (Abbildung 8.217).

Abbildung 8.217 Die Inhalte der »DNSForestZone« im DNS-Verwaltungswerkzeug

Um tiefer in die »Innereien« einer im Active Directory gespeicherten Zone schauen zu können, können Sie beispielsweise den ADSI-Editor verwenden – ein beliebiger anderer LDAP-Browser tut es im Zweifelsfall auch. Einen Überblick darüber, welche Partitionen überhaupt vorhanden sind, erhalten Sie in der Konfigurationspartition. Sie öffnen diese im ADSI-Editor, indem Sie eine Verbindung zum Namenskontext Konfiguration erzeugen (Abbildung 8.218).

Abbildung 8.218 Stellen Sie eine Verbindung mit dem Namenskontext »Konfiguration« her.

Wenn man in der Konfigurationspartition in den Container CN=Partitions navigiert, erhält man einen Überblick über Partitionen, die auf dem Domänencontroller vorhanden sind, der mit dem ADSI-Editor verbunden ist. Dort finden sich standardmäßig fünf Partitionen (Abbildung 8.219):

• CN=Enterprise Schema: Das ist das Schema der Active Directory-Gesamtstruktur.
• CN=Configuration: Dies ist die Partition, die diverse Konfigurationsdaten enthält. Hier finden Sie beispielsweise die Informationen über die in der Gesamtstruktur vorhandenen Standorte. In dieser Partition wird aber beispielsweise auch die Exchange Server-Konfiguration gespeichert, sofern ein Exchange Server in der Organisation vorhanden ist.
• CN=[domänenname]: In dieser Partition werden die domänenspezifischen Objekte gespeichert, also insbesondere Benutzerobjekte, Computerobjekte und dergleichen mehr.
• DC=DomainDnsZones: Diese Partition enthält die DNS-Daten der Active Directory-integrierten DNS-Zonen.
• DC=ForestDnsZones: Diese Partition enthält die zuvor schon erwähnten DNS-Informationen zur Gesamtstruktur.

Abbildung 8.219 Im Container »CN=Partitions« finden Sie eine Liste aller vorhandenen Partitionen. ADSI-Editor kann durch eine Funktion im Kontextmenü eine Verbindung zur Partition (Namenskontext) aufbauen.

Sie öffnen eine Partition, indem Sie den Menüpunkt Neue Verbindung mit dem Namenskontext im Kontextmenü einer Partition auswählen. Sofern Sie den Verzeichnispartitionsnamen (z. B. DC=ForestDnsZones,DC=ubinf,DC=intra) kennen, können Sie die Partition auch ohne diesen Umweg öffnen. Wenn man aber nicht ständig mit ADSI-Editor arbeitet, dürfte die hier beschriebene Vorgehensweise komfortabler sein.

Die DC=ForestDnsZones-Partition wird sich auch in ADSI-Editor problemlos öffnen lassen. Jetzt stellt sich die Frage, was zu dem Fehler führt, sodass adprep /rodcprep keine Änderungen durchführen kann. Hier die Überlegungen:

• Im Grunde genommen fügt adprep /rodcprep an einigen Stellen im AD Leserechte für die Gruppe Domänencontroller der Organisation ohne Schreibzugriff hinzu.
• Die Fehlermeldung besagte, dass der »angegebene Server den angeforderten Vorgang nicht ausführen kann« (siehe Abbildung 8.216). Wenn Sie tief in Ihrem Active Directory-Wissen kramen, werden Sie sich entsinnen, dass einige Änderungsoperationen nur von einem bestimmten Server, nämlich dem Inhaber der jeweiligen FSMO-Rolle, durchgeführt werden können.
• Etliche Konfigurationseinstellungen zur Partition finden Sie in dem dort enthaltenen Objekt CN=Infrastructure.
• Ein Attribut des Infrastructure-Objekts ist fSMORoleOwner, dessen Wert Sie nun kontrollieren sollten.

Wie Sie in Abbildung 8.220 erkennen, ist der Wert des Attributs fSMORoleOwner zumindest »merkwürdig«. Eigentlich wird dort der Name eines Servers angegeben, und der momentane Wert verweist definitiv nicht auf einen vorhandenen Domänencontroller. Vergleicht man diesen Wert mit dem Wert eines Attributs in einer »heilen« Partition, muss es beispielsweise so aussehen:

CN=NTDS Settings,CN=UBINFDC10,CN=Servers,CN=RGS,CN=Sites,CN=Configuration,DC=ubinf, 
DC=intra

Abbildung 8.220 In diesem Fall ist das Attribut »fSMORoleOwner« problematisch.

Trägt man einen korrekten Wert für das Attribut ein, also beispielsweise CN=NTDS Settings,CN=UBINFDC10,CN=Servers,CN=RGS,CN=Sites,CN=Configuration,DC=ubinf,DC=intra, dürfte das Problem behoben sein. Ein nochmaliger Durchlauf von adprep /rodcprep nimmt die Anpassungen an der Partition vor. Wenn Sie DCdiag erneut ausführen, wird das ursprünglich bemängelte Problem nicht mehr angezeigt (Abbildung 8.221).

Abbildung 8.221 Jetzt klappt’s auch mit »adprep /rodcprep«.

Erklärung

Der »problematische Wert« des Attributs fSMORoleOwner enthält unter anderem die Buchstaben DEL, gefolgt von einer ID (siehe Abbildung 8.220, was sich verdächtig nach einem gelöschten Objekt (DELeted) anhört. In der Tat tauchen Fehler dieser Art mit schöner Regelmäßigkeit auf, und zwar unter anderem dann, wenn ein Domänencontroller nicht »sauber«, also mittels dcpromo, aus dem Active Directory entfernt worden ist. Wie hier zu sehen ist, bleibt ein Verweis auf das gelöschte Objekt erhalten, auf das natürlich zum Ändern von Einstellungen nicht zugegriffen werden kann. Selbstverständlich ist die Partition auf allen Domänencontrollern, auf die sie repliziert wird, im Zugriff, aber Änderungen, die nur auf dem Inhaber der FSMO-Rolle durchgeführt werden, scheitern, weil der Verweis zu dem entsprechenden Server »kaputt« ist.

Active Directory ist so komplex, dass die Arbeit auf »Low-Level-Ebene« weder besonders simpel ist noch besonders viel Spaß macht. Sie ist aber hin und wieder unvermeidlich, weil beispielsweise der Inhaber der FSMO-Rolle für die DnsForestZones-Partition nicht mit einem grafischen Werkzeug konfiguriert werden kann.

Dies kann natürlich nur ein exemplarisches Beispiel sein. Als Active Directory-Administrator werden/müssen/sollten Sie mit der Zeit ein Gespür dafür bekommen, wo man »hineinschauen« muss, wenn tatsächlich mehr oder weniger mysteriöse Fehler auftreten, obwohl in den grafischen Administrationswerkzeugen alles bestens aussieht.

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.