Replikation checken
Wie beschrieben, findet die Überprüfung der AD-Replikation mit "Repadmin" statt. Das Tool zeigt für den gerade lokalen Domänencontroller oder einen angegebenen Ziel-DC an, wie die Replikation pro Namenskontext läuft – und wann die letzte Replikation klappte. Eine weitere, detaillierte Übersicht über die Replikationslatenz und die vorherigen Replikationsvorgänge erhalten Sie mit dem Kommando in Listing 1.

Ähnlich dem Propagationstest für DFSR können Sie das Windows-AD auf die Ausbreitung von Objektänderungen durch die Replikation testen. Im vorherigen Kommando gibt das "largest delta" schon eine gute Idee diesbezüglich. Wer das in kontrollierter Weise mit mehreren Objekten ausprobieren möchte, kann im AD neue Objekte erstellen und überprüfen, wie lange die Replikation zu entfernten DCs läuft. Das ist auch interessant für Änderungen an der AD-Konfiguration und des Schemas.

Die Propagationszeit ist einfach zu messen: Alle DCs werden sich den gleichen Zeitstempel für "whenCreated" für das neue Objekte notieren, denn "whenCreated" wird repliziert. Das Feld, das DC-lokale Änderungen markiert, ist "whenChanged". Die Differenz aus den beiden Zeitstempeln ergibt die Propagationszeit, vorausgesetzt es werden keine weiteren Änderungen am Objekt vorgenommen.

Das AD bemüht sich um eine möglichst reibungslose Konfliktresolution. Mit mehreren DCs in einem AD-Verbund kann es allerdings schon einmal vorkommen, dass Änderungen an Objekten auf unterschiedlichen DCs zueinander im Konflikt stehen. Meist geht das gut aus – der zuletzt Schreibende gewinnt. Wenn jedoch an zwei DCs im selben Container ein gleichnamig neues Objekt erstellt wird, verkompliziert dies die Konfliktlösung: Das AD benennt eines der Objekte in "<Objektname>CNF:<objectID>" um. Der umbenannte Benutzer kann sich damit nicht anmelden, ein Umbenennen ist notwendig.

Für den Fall, dass ein Objekt auf einem DC in einen Container oder eine OU verschoben, gleichzeitig jener Container oder OU auf einem anderen DC gelöscht wird, hat das Windows-AD einen kleinen Trick vorrätig: Es verschiebt das gerade dort hin geschobene Objekt in den Container "LostAndFound".

Falsche Uhrzeit
Ein Klassiker bei Fehlern im AD, sowohl bei Clients als auch Domänencontrollern selbst, ist eine falsche Uhrzeit. Das Kerberos-Protokoll für die Authentifizierung und Ticketausgabe für Ressourcen nutzt unter anderem Zeitstempel für den Schutz gegen Replay-Attacken. Driften die Uhrzeiten zwischen Clients und DC oder zwischen DCs auseinander, können sich die Partner nicht mehr gegenseitig authentifizieren. Dann funktioniert der Zugriff nicht mehr, ebenso die Replikation oder Gruppenrichtlinien.

Die Standardvorgabe von Windows für Domänenmitglieder und DCs ist, dass alle ihre Zeit mit ihrem DC synchronisieren. Die DCs beziehen die Uhrzeit dabei vom DC mit der Rolle "PDC-Emulator". Oft wird beim Übertragen der PDC-E-FSMO-Rolle von einem DC zu einem anderen vergessen, eine gültige Zeitquelle zu konfigurieren. Für die Überprüfung, ob eine Maschine sich an die Domänenstruktur hält oder einem anderen Zeitserver folgt, verwenden Sie den Befehl in Listing 2. Erhalten Sie für den Registry-Key "Type" den Wert "NTP" zurück, so folgt die Maschine einem anderen Zeitserver. Ist "NT5DS" eingetragen, gibt die Domänenkonfiguration den Takt vor.

Auf virtuellen DCs spielen je nach Konfiguration der VM-Host und die VM-Infrastruktur ebenfalls eine Rolle. VM-Hosts verfügen über die Funktion, ihre Zeit in die VMs, die sie betreiben, hinein zu synchronisieren als Teil des lokalen VM-Managements. Das ist in vielerlei Hinsicht sinnvoll, muss jedoch bekannt sein und bewusst eingesetzt werden. Stimmt die Zeit auf dem VM-Host nicht und synchronisiert dieser diese falsche Uhrzeit in die VM, kann ein RDP-Logon auf die DCs scheitern – neben allen anderen Funktionen.

In einigen Unternehmen existiert eine interne Zeitquelle, die mit dem Internet verbunden ist und die für alle Clients, Server und Appliances genutzt wird. Das ist in Ordnung, solange die Zeit aller Maschinen nicht mehr als fünf Minuten auseinanderdriftet.

Neuinstallation nicht immer vermeidbar
Bleiben alle Versuche erfolglos, einen einzelnen Domänencontroller wieder zur Arbeit zu bewegen, hilft nur das Herunterstufen und die Neuinstallation. Kann der DC generell noch mit den anderen DCs sprechen und einige ## sind weiterhin verfügbar, sollten Sie ein normales Herunterstufen versuchen. Erst wenn das nicht erfolgreich ist, sollte ein hartes Abschalten des DCs, die Neuinstallation des Betriebssystems und anschließend der "metadata cleanup" stattfinden. Dieser entsorgt die allermeisten alten Referenzen des Domänencontrollers aus dem AD. Dann lohnt sich eine Prüfung von "Sites and Services", das NTDSUtil beim Metadata Cleanup nicht aufräumt, sowie ein Blick in DNS und das Löschen der alten DNS-Einträge des vernichteten DCs.

Fazit
DCs bilden die Kernkomponenten in einer Active-Directory-Umgebung. Zwar sind die Controller auf bestimmte Fehlersituationen vorbereitet und wissen damit umzugehen. Doch in manchen Fällen hilft nur ein manuelles Eingreifen. Die passenden Tools unterstützen Sie beim Check. Sollten Sie in absehbarer Zeit dennoch keinen Durchbruch schaffen, bleiben nur das Herabstufen und die Neuinstallation.

ln/dr/Frank Tess

Im ersten Teil des Workshops haben wir uns nach einer Einführung in das Thema die Diagnosemöglichkeiten mit DCDiag angeschaut und erklärt, wie Sie DCs direkt nach der Installation überprüfen. Im zweiten Teil haben wir beschrieben, mit welchen Checks Sie die SYSVOL-Replikation sicherstellen.