AD-Diagnosemethodik: vom Symptom zum überprüfbaren Befund

dcdiag läuft grün durch, repadmin meldet keine Fehler — also kein AD-Problem, ab damit ans Netzwerkteam. Der Schluss ist falsch, und zwar aus einem benennbaren Grund: Beide Werkzeuge prüfen die Sicht des Servers auf sich selbst und nie den Weg, den ein Client zu ihm nimmt. Dieses Modul lehrt keine neuen Fachinhalte, sondern das Verfahren, das über DNS, Replikation, Richtlinien und Kerberos hinweg gleich bleibt: die Grenze vor der Vermutung bestimmen, von unten nach oben und von billig nach teuer prüfen, aus jeder Ausgabe genau das lesen, was sie hergibt, jede Hypothese mit einer Gegenprobe versehen — und die Änderung als letzten Schritt klein, einzeln und mit Rückweg halten.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-06

Warum AD-Störungen alle gleich aussehen

„Die Anmeldung dauert ewig.“ „Das Laufwerk ist weg.“ „Ich komme nicht auf die Freigabe.“ Drei Meldungen, die in einer Active-Directory-Umgebung auf mindestens ein Dutzend verschiedene Ursachen zeigen können — Namensauflösung, Standortzuordnung, Replikationslatenz, Richtlinienverarbeitung, Ticket, Berechtigung, Zeit.

Das ist kein Zufall, sondern eine Eigenschaft des Systems: AD ist eine Kette von Abhängigkeiten, und bricht irgendein Glied, meldet der Nutzer immer nur das Ende der Kette. Die eigentliche Arbeit besteht deshalb nicht darin, eine Lösung zu kennen, sondern darin, die Kette schnell auf ein Glied einzugrenzen.

Worum es in diesem Modul gehtNicht um neue Fachinhalte — DNS, Replikation, Richtlinien und Kerberos hast du bereits. Es geht um das Verfahren: In welcher Reihenfolge fragt man, welches Werkzeug beantwortet welche Frage, was beweist eine Ausgabe tatsächlich, und wann darf man etwas ändern. Dieselbe Methode trägt in jeder der bisherigen Domänen.

Die Kette: Signal, Grenze, Hypothese, Befund

Signal — was ist beobachtbar, gemessen statt berichtet↓Grenze — wer ist betroffen, wer nicht; seit wann, seit wann nicht↓Hypothese — welches Glied der Kette erklärt genau diese Grenze↓Ausschluss — welche Beobachtung würde die Hypothese widerlegen↓Befund — belegte Ursache mit Ausgabe, die ein anderer nachvollziehen kann↓Änderung — erst jetzt, im kleinsten Umfang, mit Rückweg

Ändern ist der letzte Schritt, nicht der erste

Die Stufe, die am häufigsten übersprungen wirdDie Grenze. Wer sofort zur Hypothese springt, bearbeitet die erste Idee statt der wahrscheinlichsten. Dabei ist die Grenze fast immer schneller zu ermitteln als jede Vermutung zu prüfen — und sie halbiert den Suchraum in einem Schritt. Betrifft es einen Nutzer oder alle? Einen Standort oder alle? Alte Konten oder neue? Nach jeder dieser Fragen fällt die Hälfte der denkbaren Ursachen weg.

Die Grenze bestimmen: vier Fragen, die immer gehen

Wer?: Ein Nutzer, eine Gruppe, ein Gerätetyp, alle? Betrifft es genau die Konten mit langer Historie, deutet das auf etwas anderes als „alle im Gebäude“.
Wo?: Ein Standort, ein Subnetz, ein Server? Eine Grenze, die exakt an einer Netzgrenze verläuft, zeigt auf Standortzuordnung oder Namensauflösung.
Seit wann?: Und vor allem: Was ist davor passiert? Nicht als Schuldzuweisung, sondern weil eine Änderung eine prüfbare Hypothese liefert.
Womit nicht?: Was funktioniert noch? Der funktionierende Nachbarfall ist die wertvollste Information überhaupt — er grenzt aus, was nicht die Ursache sein kann.

Der Vergleichsfall schlägt jede VermutungZwei Systeme, von denen eines funktioniert und eines nicht, beantworten in Minuten, was stundenlanges Nachdenken nicht schafft. Deshalb lohnt die Frage „gibt es einen Fall, der geht?“ noch vor jedem Werkzeug. Und wenn es keinen gibt, ist auch das ein Befund: Dann ist die Ursache weiter oben in der Kette als vermutet.

Werkzeuge und ihre Aussagegrenze

Jedes Werkzeug beantwortet eine Frage. Der häufigste Fehler ist nicht, das falsche zu benutzen, sondern aus einer Ausgabe mehr zu lesen, als sie hergibt.

nltest /dsgetdc:: Beantwortet: Welchen DC wählt dieser Client, und welchen Standort nimmt er an? Beweist nicht, dass die Anmeldung funktioniert.
repadmin /replsummary: Beantwortet: Steht irgendwo Replikation still? Rückstand ist nicht gleich Fehler — über Standortverbindungen ist Rückstand normal.
dcdiag: Beantwortet: Fallen einem DC Probleme an sich selbst auf? Ein grüner Lauf beweist nicht, dass ein Client zurechtkommt.
gpresult /h: Beantwortet: Welche Richtlinien wurden angewendet, welche verweigert und warum? Sagt nichts darüber, ob das so gewollt war.
Ereignisprotokoll: Beantwortet: Was hat der Dienst selbst festgestellt? Nur brauchbar, wenn man den richtigen Lauf isoliert — sonst liest man mehrere Vorgänge übereinander.

Werkzeug-MagieEin Werkzeug auszuführen ist keine Diagnose. Die Ausgabe wird erst zum Befund, wenn du vorher gesagt hast, was du erwartest und was das Ergebnis unterscheidet. Wer dcdiag startet und hofft, dass etwas Rotes erscheint, hat keine Hypothese geprüft, sondern gewürfelt — und interpretiert die erste Warnung als Ursache, obwohl sie seit Monaten dort steht.

Grün ist kein Beweis

Prüfwerkzeuge sind auf die Sicht des Servers gebaut. Sie stellen fest, ob ein Domain Controller seine eigenen Aufgaben erfüllen kann — nicht, ob ein bestimmter Client bei ihm ankommt. Zwischen beidem liegen Namensauflösung, Standortzuordnung, Netzwerkpfad und Client-Konfiguration, und keines davon prüft ein Werkzeug, das auf dem DC läuft.

Die zwei Sichten auseinanderhaltenEin Befund braucht fast immer beide Seiten: eine Aussage vom Dienst (läuft er, repliziert er, meldet er Fehler) und eine Aussage vom Betroffenen (wo landet er, was bekommt er, was fehlt). Wer nur die Serverseite prüft, erklärt regelmäßig für gesund, was für den Nutzer nicht funktioniert — und sucht danach beim Nutzer, obwohl die Grenze dazwischen liegt.

Umgekehrt gilt es auchEine Warnung, die schon vorher da war, ist keine Ursache. Bevor ein Fund die Erklärung wird, gehört die Frage dazu: Seit wann steht das da, und war es gestern auch schon so? Ohne einen Vergleichsstand aus dem Normalbetrieb lässt sich das nicht beantworten — was der eigentliche Wert einer Aufbaudokumentation ist.

Korrelation ist eine Hypothese, keine Ursache

„Seit dem Wartungsfenster gestern geht es nicht mehr.“ Das ist ein wertvoller Hinweis und noch kein Befund. Zeitliche Nähe macht eine Änderung zum ersten Prüfkandidaten — sie beweist nichts. Zwei Fallen stecken darin, und beide kosten regelmäßig Stunden.

Die unsichtbare Änderung. Nicht jede Änderung steht im Change-Protokoll. Ein abgelaufenes Zertifikat, ein voll gelaufenes Volume, ein Konto, dessen Kennwort turnusmäßig rotiert wurde — nichts davon taucht als Änderung auf, wirkt aber wie eine.
Die verzögerte Änderung. Manche Änderungen wirken erst Tage später: eine Richtlinie, die erst bei der nächsten Anmeldung greift, ein Ticket, das erst nach Ablauf neu ausgestellt wird, eine Replikation, die nach Zeitplan läuft. Der Zeitpunkt des Symptoms ist dann nicht der Zeitpunkt der Ursache.

Die GegenprobeEine Hypothese wird erst dadurch belastbar, dass du benennst, was sie widerlegen würde. „Wenn es die DNS-Änderung ist, dann müsste ein Client mit altem Resolver noch funktionieren.“ Findet sich dieser Client und funktioniert er nicht, ist die Hypothese tot — und du hast in fünf Minuten mehr gelernt als in einer Stunde Bestätigungssuche.

Und der umgekehrte FehlerEbenso verbreitet ist, eine Änderung auszuschließen, weil sie „damit nichts zu tun hat“. In einem System, in dem Namensauflösung, Zeit und Verzeichnis alles tragen, hat überraschend vieles miteinander zu tun: eine Firewall-Regel, die eine Standortverbindung betrifft; ein Zertifikat, an dem eine Anmeldemethode hängt; ein Speicherplatzproblem auf einem DC. Die brauchbarere Haltung ist, jede zeitlich passende Änderung zu notieren und nach Prüfkosten zu sortieren — statt sie vorab zu bewerten.

Wo AD-Störungen tatsächlich sitzen

Die Kette hat eine übliche Reihenfolge, und sie ist nicht die, in der man normalerweise sucht. Von unten nach oben:

Zeit: Weicht die Uhr zu weit ab, scheitert Kerberos — mit einer Meldung, die nach Konto oder Netz aussieht. Billig zu prüfen, deshalb früh.
Namensauflösung: Zeigt der Betroffene auf den richtigen Resolver, und antwortet dieser auf die Dienstabfragen? Erreichbarkeit auf IP-Ebene beweist hier nichts.
Standortzuordnung: Kennt AD das Subnetz des Betroffenen? Fehlt es, wählt der Locator einen entfernten DC — alles funktioniert, nur langsam.
Verzeichnis: Repliziert der gewählte DC, kennt er den aktuellen Stand? Latenz ist normal, Fehler nicht.
Ticket und Rechte: Trägt das vorhandene Ticket noch einen alten Stand? Gruppenänderungen wirken erst mit einem neuen Ticket.
Anwendung: Zuletzt. Was hier aussieht wie ein Anwendungsfehler, ist überraschend oft eine der Ebenen darunter.

Warum die Reihenfolge von unten nach oben zähltEine defekte Ebene lässt alle darüber liegenden falsch aussehen. Wer oben anfängt, findet dort echte Auffälligkeiten, die aber Folgen und nicht Ursachen sind — und behebt sie, ohne dass sich etwas ändert. Die Reihenfolge ist zugleich nach Prüfkosten sortiert: Die unteren Ebenen kosten Sekunden, die oberen Stunden.

Ändern: klein, umkehrbar, einzeln

Wenn der Befund steht, folgt die Änderung — und dafür gelten drei Regeln, die vor allem verhindern sollen, dass aus einer Störung zwei werden.

Kleinster Umfang. Die Korrektur adressiert genau das belegte Glied. Eine Änderung, die vorsichtshalber noch drei andere Dinge mitregelt, macht das Ergebnis unauswertbar.
Eine nach der anderen. Zwei gleichzeitige Änderungen und ein verschwundenes Symptom ergeben null Erkenntnis — und beim nächsten Mal beginnt die Suche von vorn.
Rückweg benannt. Bevor du änderst, steht fest, wie du es rückgängig machst und woran du merkst, dass du es tun solltest.

Die Maßnahmen, die keine Diagnose ersetzenEinige Eingriffe sehen wie Fehlersuche aus und sind in Wahrheit Symptombeseitigung mit Nebenwirkungen: eine FSMO-Rolle zu erzwingen, eine Replikation von Hand anzustoßen, ein Konto zurückzusetzen, eine Berechtigung zu erweitern, eine Firewall zu öffnen. Jede dieser Maßnahmen kann richtig sein — aber keine davon gehört an den Anfang. Sie verändern den Zustand, den du gerade untersuchst, und mehrere von ihnen sind nicht umkehrbar.

Was ein übergabefähiger Befund enthält

Die meisten Störungen enden nicht mit der Lösung, sondern mit einer Übergabe — an die nächste Schicht, an ein anderes Team, an das Protokoll. Ein Befund, der das nicht übersteht, war die Arbeit nicht wert.

Symptom und Grenze: Wer ist betroffen, wer nicht, seit wann.
Belege: Die tatsächlichen Ausgaben, nicht ihre Zusammenfassung. „DNS ist falsch“ ist keine Aussage; die Abfrage mit ihrer Antwort ist eine.
Ausgeschlossenes: Was wurde geprüft und ist es nicht. Das ist der Teil, den Nachfolgende sonst wiederholen.
Getane Änderungen: Auch die wirkungslosen — sonst sucht der Nächste in einer Umgebung, die nicht mehr die dokumentierte ist.
Offene Frage: Was genau ist als Nächstes zu klären.

Der Punkt, der am häufigsten fehltDie wirkungslosen Änderungen. Sie werden verschwiegen, weil sie nach vergeblicher Arbeit aussehen — und genau sie sind der Grund, warum die nächste Schicht in einem Zustand sucht, den niemand mehr beschrieben hat. Eine rückgängig gemachte Änderung gehört ebenso ins Protokoll wie eine wirksame.

Der Satz, an dem man einen guten Befund erkenntEin übergabefähiger Befund lässt sich in einem Satz sagen, der eine Beobachtung und eine Grenze enthält — nicht eine Vermutung. „Clients im Subnetz 10.20.0.0/16 wählen laut nltest einen Domain Controller der Zentrale, weil das Subnetz keinem Standort zugeordnet ist; Clients im Nachbarsubnetz wählen korrekt lokal.“ Wer das nicht formulieren kann, hat noch keinen Befund, sondern eine Arbeitshypothese — und sollte das auch so übergeben, statt sie als Ursache auszugeben.

Durchgerechnet: eine Meldung, sechs Minuten

Von „geht nicht“ zu einem Befund

Szenario

Ein Ticket meldet: „Anmeldung in der Zweigstelle Nord funktioniert nicht.“ Mehr steht nicht darin. Du hast Zugriff auf einen Rechner vor Ort und auf die Domain Controller.

Anforderungen

In wenigen Minuten von der Meldung zu einer prüfbaren Hypothese
Keine Änderung, bevor der Befund steht

Schritte

Signal schärfen: „Funktioniert nicht“ ist kein Signal. Scheitert die Anmeldung mit einer Meldung, dauert sie nur lange, oder betrifft es erst den Zugriff danach? Diese eine Rückfrage trennt bereits drei völlig verschiedene Fehlerklassen.
Grenze ziehen: Alle in der Zweigstelle oder einzelne? Auch neu angelegte Konten? Funktioniert es an einem anderen Standort mit denselben Konten? Zwei Minuten, die den Suchraum drastisch verkleinern.
Von unten prüfen: Stimmt die Zeit auf dem Client? Auf welchen Resolver zeigt er, und antwortet der auf die Dienstabfragen? Welchen Domain Controller wählt er, und welchen Standort nimmt er dabei an?
Hypothese benennen — mit Gegenprobe: Wählt der Client einen DC der Zentrale, lautet die Hypothese „Subnetz nicht zugeordnet“. Die Gegenprobe: Ein Rechner in einem anderen Subnetz desselben Standorts müsste sich dann gleich verhalten — und ein Blick in die Standortzuordnung müsste die Lücke zeigen.
Befund formulieren: Die Ausgaben sichern, die Lücke benennen, die geplante Änderung auf genau diese Zuordnung begrenzen — und dazuschreiben, dass zwischengespeicherte Zuordnungen noch eine Weile nachwirken, damit niemand nach zwei Minuten ein zweites Mal eingreift.

Merksatz: Bis zu diesem Punkt wurde nichts verändert und trotzdem fast alles entschieden. Die Zeit ging in Fragen, nicht in Werkzeuge — und der Befund ist übergabefähig, auch wenn die Schicht vorher endet.

Die erste Viertelstunde: eine konkrete Reihenfolge

Methode ist gut, eine abrufbare Reihenfolge ist besser — gerade um drei Uhr nachts. Die folgende Kette folgt der Regel „von unten nach oben und von billig nach teuer“ und lässt sich für die meisten AD-Störungen unverändert abarbeiten.

Auf dem betroffenen Client: w32tm /query /status — stimmt die Zeit und woher kommt sie? Ein Versatz erklärt Kerberos-Fehler, die nach allem Möglichen aussehen.
: ipconfig /all — auf welchen Resolver zeigt der Client wirklich? Nicht auf welchen er zeigen sollte.
: nslookup -type=srv _ldap._tcp.dc._msdcs.<domäne> — antwortet dieser Resolver auf die Dienstabfrage?
: nltest /dsgetdc:<domäne> — welchen DC wählt der Client, und welchen Standort nimmt er an?
: klist tickets — gibt es überhaupt Tickets, und für welche Dienste?
Auf dem gewählten DC: repadmin /replsummary — Fehlerzähler über null? Rückstand allein ist kein Befund.
: dcdiag /test:dns — fallen dem DC eigene Namensprobleme auf?
: net share — stehen SYSVOL und NETLOGON bereit? Ohne sie wird keine Richtlinie verarbeitet.

Warum diese Reihenfolge und keine andereJeder Schritt kostet Sekunden und schließt eine ganze Fehlerklasse aus. Vor allem aber steht der Client zuerst — dort entsteht das Symptom, und dort liegen die Antworten auf „wo lande ich eigentlich“. Wer auf dem Domain Controller beginnt, prüft ein System, das mit hoher Wahrscheinlichkeit gesund ist, und verbraucht die erste Viertelstunde mit einer Bestätigung.

Sichern, nicht nur ansehenLeite die Ausgaben mit, statt sie nur zu lesen. Nach der Korrektur ist der Vorher-Zustand nicht mehr herstellbar — und genau der ist es, den eine Übergabe, ein Protokoll oder die Frage „war das schon immer so?“ später braucht. Zwei Minuten Mitschnitt ersparen im Zweifel die zweite Fehlersuche.

Prüf dich selbst, bevor es zählt

Kurzcheck

Ein Monitoring-Alarm meldet Replikationsfehler zwischen zwei Domain Controllern. Ein Kollege will sofort die FSMO-Rollen auf den gesunden DC erzwingen, „damit der Betrieb weiterläuft“. Was hältst du dagegen?

Nichts — bei Replikationsfehlern ist das Erzwingen der Rollen die vorgesehene Sofortmaßnahme.
Ein Replikationsfehler belegt keinen Ausfall des Rolleninhabers — und ein Erzwingen ist nicht umkehrbar.
Der Vorschlag ist zu langsam; zuerst sollten beide Domain Controller neu gestartet werden, um den Fehler zu klären.

Treffer. Richtig. Es fehlt der Befund: Erst muss feststehen, ob der DC überhaupt weg ist. Ein erzwungener Rollenwechsel bedeutet, dass der alte Inhaber nie wieder ans Netz darf — eine Entscheidung, die man nicht auf Verdacht trifft.

Damit steht das Verfahren: Signal, Grenze, Hypothese, Ausschluss, Befund, Änderung — die Grenze vor der Vermutung, die Prüfung von unten nach oben, jedes Werkzeug für genau eine Frage, keine Ausgabe als Beweis für mehr als sie zeigt, und die Änderung klein, einzeln und mit Rückweg.

Gleich im CheckIn den folgenden Übungen ordnest du Belegketten, grenzt eine Störung ein und entscheidest mehrfach, ob eine vorgeschlagene Maßnahme durch die vorliegende Beweislage überhaupt gedeckt ist.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität12 Primärquellen · zuletzt geprüft: 2026-09-06