Windows Server 2022: Domaincontroller reparieren (1)
Das Active Directory ist in den meisten Firmen eine kritische Infrastrukturkomponente. Glücklicherweise ist der Verzeichnisdienst ziemlich resistent. Er schützt sich gegen viele Fehler und potenzielle Störfälle von selbst und der Ausfall einzelner Server führt nicht zum Ausfall des ganzen Verbunds. Doch manchmal müssen Sie als Administrator Hand anlegen und einzelne Domänencontroller oder das ganze AD reparieren. Im ersten Teil schauen wir uns nach einer Einführung in das Thema die Diagnosemöglichkeiten mit DCDiag an und erklären, wie Sie DCs direkt nach der Installation überprüfen.
Die Fehlerbehebung im Active Directory (AD) oder auf einzelnen Domänencontrollern (DCs) kann einige Zeit in Anspruch nehmen. Solange der Fehler nicht kritischer Natur ist, ist das kein Problem. Beeinträchtigt das Problem aber die Benutzerproduktivität, gilt es, schnellstmöglich eine Lösung zu finden. Gerade wenn einzelne DCs Probleme aufweisen, etwa weil die Replikation nicht funktioniert oder fehlerhafte Komponenten in Windows den ordnungsgemäßen Betrieb der AD-Rolle verhindern, kann die Ursachenforschung einige Zeit verschlingen plus zeitraubender Neustarts des Servers oder der VM.
Es kann gerade beim Troubleshooting eines einzelnen DCs sinnvoll sein, sich vorab ein Zeitfenster zu setzen, in dem Sie das Problem lösen möchten, bevor Sie den DC aus dem AD entfernen und einfach neu installieren. Das spart je nach Fehlerfall Zeit. Denn müssen Sie einzelne Komponenten mühsam analysieren, Logfiles durchsuchen und bislang unbekannte Störungsfälle erarbeiten, nimmt das deutlich mehr Zeit in Anspruch als eine saubere Neuinstallation. Diese kommt natürlich nur dann in Frage, wenn mehrere DCs in der Domäne vorhanden sind und das Problem offensichtlich nur auf einem besteht.
Das geht allerdings nur, wenn Sie weder zu DC-Namen noch deren IP-Adressen starke Abhängigkeiten pflegen, die Sie zwingen, den einen defekten DC wirklich wiederherzustellen. Wenn Apps einen bestimmten Server via LDAP erreichen wollen, müssten Sie den ausgefallenen DC durch einen Nachfolger ersetzen, der den gleichen Namen trägt – das wiederum führt zu mehr Komplexität und einigen Aufräumarbeiten in der sowieso schon potenziell hektischen Wiederherstellungsarbeit. Außerdem sollten Sie für eine solide Entscheidungsgrundlage eine Grundanalyse des Problems durchgeführt haben.
Ebenso müssen Sie für solch einen Plan einige Dinge vorbereiten. Zum einen sollten DCs schlank sein und keine weiteren Serverrollen als die AD-Rolle ausführen. Jede weitere Rolle oder zusätzliche Software auf dem Server verlängert und verkompliziert die Neuinstallation. Natürlich müssen die Prozeduren zur Deinstallation und der Neuinstallation eines DCs dokumentiert, erprobt und bekannt sein, damit sich das Vorgehen effizient und fehlerfrei umsetzen lässt. Durch die Neuinstallation sollen Probleme behoben und keine neuen Probleme geschaffen werden.
Als Richtgröße nutzen einige Unternehmen vier Stunden an Troubleshooting-Dauer. Die Schritte werden fortlaufend im Problemticket festgehalten und nach vier Stunden Arbeitszeit eine Entscheidung im Team getroffen. Die Analysezeit kann natürlich für jedes Unternehmen variieren und unterscheidet sich auch in der Größe des AD-Teams – falls es ein dediziertes AD-Team gibt. Unkritische Fehler oder Fehler auf einem DC, der in einem Datenzentrum mit Überkapazität betrieben wird, sind dabei anders zu bewerten als der einzige DC in einer Niederlassung, auf den viele Mitarbeiter angewiesen sind.
Diagnose mit DCDiag
Beim Hochstufen eines Windows-Servers zum Domänencontroller werden neben der AD-Datenbank Kommandozeilenprogramme installiert. Ein umfangreiches Healthcheck-Tool ist "DCDiag". Über die Kommandozeile gestartet, sammelt es einige Daten über das AD und den DC und führt verschiedene Tests aus. Die Liste der verfügbaren Überprüfungen erhalten Sie durch Aufruf der Hilfe mit dcdiag /?. Nicht alle verfügbaren Tests werden auch im normalen Modus durch Aufruf des Tools ausgeführt – so etwa der Test "RegisterInDNS", der die Registrierung der SRV-Records im DNS überprüft. Diesen müssen Sie manuell anfragen.
Fehlgeschlagene Tests erkennen Sie als "failed test" in der Ausgabe – diesen sollten Sie nachgehen. Beim Troubleshooting können Sie dabei in die Falle tappen, dass etwa der Eventlog-Test als "failed" angezeigt wird, obwohl der Verzeichnisdienst bereits in Ordnung ist. Der "Eventlog"-Test überprüft, ob in den letzten 24 Stunden Warnungen und Fehler ausgegeben wurden. Damit erhalten Sie einen ersten Ansatz für die Fehlersuche im Detail.
DCs nach der Installation überprüfen
Wenn DCs nach dem Hochstufen neu starten, benötigten diese je nach Größe der Domäne – Inhalt des SYSVOLs und Verfügbarkeit der anderen DCs – einige Minuten, bis sie betriebsbereit sind. Eine Überprüfung der Betriebsbereitschaft eines neuen DCs, bevor er komplett in den Betrieb übergeht, ergibt immer Sinn. Die erste Anlaufstelle hierfür ist stets das Eventlog. Sowohl für "Directory Services", "DFS Replication" als auch für das "DNSServer"-Log sollten keine Error- oder Warning-Einträge vorliegen. Falls doch, studieren Sie diese genauer. Ebenso lohnt sich ein kurzer Blick in das SYSVOL-Verzeichnis. Sind nach ein paar Minuten die Ordner "\\<Servername>\SYSVOL\<Domain>\Policies" und die darunter aufgereihten Ordner für Gruppenrichtlinien nicht vorhanden, werfen Sie einen Blick auf die SYSVOL-Replikation. In neueren AD-Strukturen handelt es sich dabei um die DFS-Replikation.
Natürlich darf bei neuen DCs die Replikationsprüfung nicht fehlen. Mit repadmin auf der Kommandozeile schauen Sie nach, ob nach dem Neustart des neuen DCs bereits die Replikation aufgenommen wurde und Änderungen eintreffen. Wie Sie repadmin bedienen, zeigen wir Ihnen im weiteren Verlauf des Artikels.
ln/dr/Frank Tess
Im zweiten Teil der Workshopserie beschreiben wir, mit welchen Checks Sie die SYSVOL-Replikation sicherstellen. Im dritten und letzten Teil gehen wir unter anderem darauf ein, wie Sie gängige Fehler wie eine falsche Uhrzeit vermeiden.