Active-Directory-Replikation prüfen: von repadmin zur eigentlichen Ursache
Ein Replikationsfehler ist selten ein Replikationsfehler. Er ist ein DNS-Problem, ein Zeitproblem, ein Rechteproblem oder ein Netzproblem, das sich an dieser Stelle zeigt, weil hier alles zusammenläuft.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Fehler wird gesehen und trotzdem nicht bearbeitet
Replikationsfehler haben eine unangenehme Eigenschaft: Sie sind lange folgenlos. Ein Domänencontroller, der seit drei Wochen nicht mehr eingehend repliziert, beantwortet weiterhin Anmeldungen, liefert weiterhin Gruppenrichtlinien aus und fällt in keiner Überwachung auf, die nur die Erreichbarkeit prüft. Bemerkbar macht sich das erst als merkwürdiger Einzelfall: Ein neu angelegtes Konto funktioniert an einem Standort nicht, eine Kennwortänderung greift nicht, eine Gruppenmitgliedschaft wirkt an einem Server anders als am nächsten.
Die zweite Schwierigkeit ist, dass es zu spät sein kann. Gelöschte Objekte werden nach einer bestimmten Zeit endgültig aus der Datenbank entfernt. Hat ein Domänencontroller länger als diese Zeitspanne nicht mehr eingehend repliziert, lässt er sich nicht mehr einfach wieder anschließen, denn er kennt Objekte, die überall sonst bereits vollständig entfernt sind. Ab diesem Punkt ist die Antwort nicht mehr eine Reparatur, sondern ein Rückbau des Servers samt Bereinigung seiner Metadaten.
Die dritte Schwierigkeit liegt in der Diagnose selbst. Microsoft listet als Abhängigkeiten der Replikation die Netzwerkverbindung über die verwendeten Ports und Protokolle, die Namensauflösung über DNS, Authentifizierung und Autorisierung, eine Zeitgenauigkeit von fünf Minuten für Kerberos, die Verzeichnisdatenbank, die Replikationstopologie und die Replikationsmaschinerie. Sieben mögliche Ursachen für eine Fehlermeldung sind zu viele, um sie zu erraten. Deshalb beginnt jede sinnvolle Suche mit dem Text der Meldung und nicht mit einer Theorie.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Befunde, die im Betrieb tatsächlich auftreten
Sechs Meldungen decken den größten Teil dessen ab, was in einer gewachsenen Umgebung an Replikationsproblemen sichtbar wird. Zu jeder steht hier, woran du sie erkennst, was sie in der Regel verursacht und in welcher Reihenfolge du vorgehst.
Symptom
Der Bericht meldet für eine Replikationsbeziehung, dass der Zugriff verweigert wurde. Die Netzwerkverbindung zwischen beiden Servern funktioniert nachweislich, und andere Beziehungen desselben Servers sind unauffällig.
Ursache
Zwischen den beiden Domänencontrollern besteht eine Replikationsbeziehung, aber die Authentifizierung scheitert. Microsoft ordnet diesen Befund den Sicherheitsproblemen zu. Dahinter stecken typischerweise eine zu große Abweichung der Uhren, denn Kerberos verlangt laut Microsoft eine Genauigkeit von fünf Minuten, ein Computerkonto, das nicht mit dem Schlüsselverteilungsdienst zusammenpasst, oder fehlende Berechtigungen auf dem Zielsystem. Auch ein LDAP-Fehler 49 gehört in diese Gruppe.
Lösung
Vergleich zuerst die Uhrzeiten beider Server und prüf, ob sie sich in der Zeithierarchie am PDC-Emulator ihrer Domäne orientieren. Stimmt die Zeit, prüf das Computerkonto des Quellservers und dessen Kennwortstand. Widerstehe der Versuchung, zuerst an der Firewall zu suchen: Wenn eine Replikationsbeziehung besteht und ausgerechnet die Anmeldung scheitert, ist das Netz in der Regel nicht das Problem.
Symptom
Der Bericht meldet, dass die Zeit seit der letzten Replikation mit diesem Server die Tombstone-Frist überschritten hat. Im Verzeichnisdienstprotokoll steht dazu das Ereignis 2042.
Ursache
Ein Domänencontroller hat so lange nicht mehr eingehend vom genannten Quellserver repliziert, dass in der Zwischenzeit Löschungen als Tombstone markiert, repliziert und endgültig aus der Datenbank entfernt worden sind. Der zurückgebliebene Server hält damit Objekte, die es überall sonst nicht mehr gibt. Verwandt sind die Ereignisse 1388 und 1988, die auftreten, wenn solche zurückgebliebenen Objekte tatsächlich repliziert werden oder ein Objekt fehlt.
Lösung
Das ist kein Reparaturfall. Der betroffene Server gehört vom Unternehmensnetz in ein getrenntes Netz, dann wird Active Directory dort erzwungen entfernt oder das Betriebssystem neu aufgesetzt. Anschließend werden die Metadaten des Servers aus dem Verzeichnis entfernt, damit sein Serverobjekt nicht wiederbelebt wird. Microsoft weist darauf hin, dass gelöschte NTDS-Settings-Objekte standardmäßig 14 Tage lang automatisch wiederbelebt werden, wenn die Bereinigung ausbleibt, und dass die Fehlermeldungen dann dauerhaft weiterlaufen.
Symptom
Der Bericht meldet, dass der letzte Versuch mit der Angabe fehlgeschlagen ist, der Zielkontoname sei falsch. Im Protokoll finden sich dazu Ereignisse mit den Kennungen 2087 oder 2088.
Ursache
Microsoft nennt für diesen Befund drei mögliche Wurzeln: Verbindung, Namensauflösung oder Authentifizierung. In der Praxis ist es meistens die Namensauflösung. Domänencontroller finden ihre Replikationspartner über einen auf der GUID basierenden DNS-Namen, und wenn dieser Eintrag fehlt oder auf eine alte Adresse zeigt, entsteht genau diese Meldung. Das Ereignis 2087 steht dabei für eine gescheiterte Auflösung mit anschließend gescheiterter Replikation, 2088 für eine gescheiterte Auflösung, bei der die Replikation trotzdem gelang.
Lösung
Prüf, ob sich der GUID-basierte Name des Quellservers vom Zielserver aus auflösen lässt und ob der Zielserver überhaupt einen DNS-Server befragt, der die Zonen des Verzeichnisdienstes kennt. Häufige Ursachen sind ein Weiterleitungsserver als bevorzugter DNS-Server, veraltete Einträge nach einem Adresswechsel und eine fehlende Delegierung für die Zone mit den Verzeichniseinträgen. Erst wenn die Auflösung nachweislich funktioniert und der Fehler bleibt, lohnt der Blick auf Berechtigungen.
Symptom
Im Bericht erscheint für einen Domänencontroller überhaupt kein eingehender Partner. Im Protokoll steht dazu das Ereignis 1925.
Ursache
Der Domänencontroller konnte keine Replikationsverbindung zu einem anderen Domänencontroller aufbauen. Das ist ein Verbindungsproblem und kein Datenproblem: Es gibt keine Beziehung, über die etwas scheitern könnte. Häufige Ursachen sind ein neu aufgenommener Server, dessen Verbindungsobjekte noch nicht erzeugt wurden, eine geschlossene Firewall und eine Topologie, die den tatsächlichen Netzwegen nicht entspricht.
Lösung
Prüf zuerst, ob der Server die anderen Domänencontroller überhaupt erreicht. Die Replikation nutzt RPC und lässt sich ihren Port dynamisch über den Endpunktzuordner auf Port 135 zuweisen, was in segmentierten Netzen regelmäßig zu Regeln führt, die nur den Zuordner durchlassen. Microsoft beschreibt in einem eigenen Artikel, wie sich der Port für die Verzeichnisreplikation fest zuweisen lässt, was die Firewallregeln erheblich vereinfacht. Danach prüfe die Standort- und Verbindungsobjekte.
Symptom
Im Protokoll steht wiederholt das Ereignis 1311 aus dem Bereich der Topologieerzeugung, und einzelne Standorte replizieren untereinander nicht, obwohl alle Server erreichbar sind.
Ursache
Die im Verzeichnis hinterlegte Replikationskonfiguration bildet die tatsächliche Netzwerktopologie nicht ab. Microsoft nennt das ausdrücklich als eigene Wurzel: Standortverknüpfungen im Verzeichnis müssen echten Weitverkehrs- oder VPN-Verbindungen entsprechen. Wird eine Topologie modelliert, die es im Netz nicht gibt, scheitert jede Replikation, die diesen Weg nehmen soll.
Lösung
Geh die Standortobjekte, die zugehörigen Subnetze und die Standortverknüpfungen durch und halte sie gegen die tatsächliche Netzstruktur. Häufige Befunde sind Subnetze, die keinem Standort zugeordnet sind, Standorte ohne Domänencontroller und Verknüpfungen zwischen Standorten, zwischen denen es gar keine Leitung gibt. Erst wenn das Modell stimmt, kann die Topologieerzeugung sinnvolle Verbindungsobjekte anlegen.
Symptom
Es steht kein Fehler im Bericht, aber Änderungen brauchen zwischen zwei Standorten sehr lange, und die Zusammenfassung zeigt hohe Verzugszeiten.
Ursache
Das ist meistens kein Defekt, sondern die Wirkung des Zeitplans. Microsoft nennt allerdings eine Konstellation, in der daraus ein echtes Problem wird: Sind die Zeitpläne zwischen Standorten zu knapp bemessen, können die Replikationsqueues größer werden, als sich im vorgesehenen Zeitfenster abarbeiten lässt. Einzelne Änderungen bleiben dann liegen, unter Umständen so lange, dass die Tombstone-Frist überschritten wird. Auch eine Verzeichnisdatenbank, die Vorgänge nicht schnell genug verarbeitet, nennt Microsoft als eigene Wurzel.
Lösung
Sieh dir die Zusammenfassung mit Repadmin /Replsum an und sortiere nach der Verzugszeit, dann siehst du, ob es einen einzelnen Partner betrifft oder ein Muster ist. Prüf danach den Zeitplan der betroffenen Standortverknüpfung und das Intervall. Ein manuell angestoßener Abgleich mit repadmin /sync zeigt, ob es überhaupt fließt, erzeugt aber im Bericht den Hinweis, dass die Replikation unterbrochen wurde, und genau das ist laut Microsoft eine informative Meldung und kein Fehler.
Vom Text der Meldung zur richtigen Baustelle
- 01 Zugriff verweigert: Authentifizierung, Kerberos und Uhrzeit, nicht das Netz.
- 02 Zielkontoname ist falsch: meist Namensauflösung, seltener Sicherheit oder Verbindung.
- 03 Keine eingehenden Partner: es gibt gar keine Verbindung, die Topologie ist die Baustelle.
- 04 Tombstone-Frist überschritten: kein Reparaturfall mehr, sondern ein Rückbau.
- 05 Preempted oder posted, waiting: kein Fehler, sondern normaler Betrieb.
Was du einrichtest, damit die Suche jedes Mal gleich abläuft
Sechs Gewohnheiten machen aus einer offenen Suche eine Abarbeitung. Fünf davon kosten einmalig Zeit, die sechste ist eine Entscheidung darüber, wer täglich hinsieht.
Den Gesamtbericht als Ausgangspunkt nehmen, nicht einen einzelnen Server
Microsoft empfiehlt für den Überblick den Aufruf repadmin /showrepl * /csv >showrepl.csv, der die Replikationsbeziehungen aller Domänencontroller der Gesamtstruktur in eine Tabelle schreibt. Der Stern steht dabei für alle Domänencontroller. Für die Ausführung wird Mitgliedschaft in Enterprise Admins verlangt. Wer die Ausgabe ohne Tabellenkalkulation ansehen will, leitet sie mit repadmin /showrepl * /csv | convertfrom-csv | out-gridview in ein Fenster.
Nach zwei Spalten sortieren und den Rest ausblenden
In der Auswertung zählen zwei Spalten. Die Spalte mit dem letzten Erfolg wird von alt nach neu sortiert, dann steht der problematischste Partner oben. Die Spalte mit dem letzten Fehler wird auf alles gefiltert, was nicht null ist. Zusätzlich lohnt es sich, Einträge auszublenden, deren Quellserver den Zusatz für gelöschte Domänencontroller trägt, sonst dominieren Leichen die Liste.
Die Verzugszeiten getrennt betrachten
Neben dem Bericht über die einzelnen Beziehungen gibt es die zusammengefasste Sicht mit Repadmin /Replsum, die sich nach der Verzugszeit sortieren und auf Fehler beschränken lässt. Microsoft empfiehlt genau diese Zusammenfassung für die erste Bestandsaufnahme, etwa vor einer Änderung an der Funktionsebene. Sie beantwortet die Frage, ob es ein Einzelproblem ist oder ein Muster über mehrere Standorte.
Das Verzeichnisdienstprotokoll als zweite Quelle nutzen
Die meisten Replikationsprobleme werden als Ereignis im Verzeichnisdienstprotokoll gemeldet, oft mit einem Hinweis auf die konkrete Einschränkung. Microsoft nennt dafür eine Reihe wiederkehrender Kennungen, unter anderem 1311 und 1925 aus dem Bereich der Topologieerzeugung sowie 1388, 1988 und 2042 rund um zurückgebliebene Objekte und 2087 und 2088 für gescheiterte Namensauflösung.
Absichtliche Unterbrechungen vorher ausschließen
Bevor du eine Meldung untersuchst, kläre, ob der betreffende Server überhaupt am Netz sein sollte. Microsoft nennt genau diesen Punkt als ersten Schritt: Ein Domänencontroller, der an einem Zwischenstandort vorbereitet wurde und auf seinen Transport wartet, erzeugt fortlaufend Fehler. Für diesen Fall lautet die Empfehlung, den Rechner zunächst als Mitgliedsserver auszuliefern und ihn erst am Zielort über Install from Media aufzunehmen.
Täglich hinsehen statt anlassbezogen
Microsoft formuliert das als allgemeine Vorgehensweise: die Replikationsgesundheit täglich überwachen oder den Status täglich über repadmin abrufen und gemeldete Fehler zeitnah beheben. Der Grund ist die Frist, ab der ein zurückgebliebener Domänencontroller nicht mehr reparierbar ist. Wer erst nachsieht, wenn Benutzer sich melden, hat diese Frist unter Umständen bereits verstreichen lassen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was ein sauberer Replikationsbericht nebenbei beweist
Microsoft formuliert einen Umkehrschluss, der die Replikationsprüfung so wertvoll macht: Wenn die Replikation fehlerfrei läuft, weißt du, dass die Domänencontroller online sind, und du weißt gleichzeitig, dass die DNS-Infrastruktur, das Kerberos-Protokoll, der Zeitdienst, RPC und die Netzwerkverbindung funktionieren. Ein grüner Bericht ist deshalb keine Einzelprüfung, sondern eine Sammelprüfung über die tragenden Abhängigkeiten des Verzeichnisdienstes.
Umgekehrt gilt genauso: Ein Replikationsfehler ist fast nie ein Fehler der Replikation. Microsoft listet die Wurzeln in einer festen Reihenfolge auf, nachdem absichtliche Unterbrechungen und Hardwareausfälle ausgeschlossen sind. Es bleiben die Netzwerkverbindung, die Namensauflösung, Authentifizierung und Autorisierung, die Verzeichnisdatenbank, die Replikationsmaschinerie und die Topologie. Der Text der Meldung ordnet den Befund einer dieser Gruppen zu, und das ist der halbe Weg zur Lösung.
Aus dieser Beobachtung folgt eine Empfehlung für die Überwachung. Wer nur prüft, ob ein Domänencontroller erreichbar ist und ob seine Dienste laufen, sieht einen Server, der seit Wochen nicht mehr repliziert, bis zuletzt als gesund an. Der Replikationsstatus gehört deshalb in dieselbe Übersicht wie die Verfügbarkeit, und zwar mit Blick auf den Zeitpunkt des letzten Erfolgs und nicht nur auf die Frage, ob gerade ein Fehler ansteht.
Welche Meldungen kein Fehler sind
Zwei Einträge im Bericht sehen nach einem Problem aus und sind keines. Die Meldung, dass die Replikation unterbrochen wurde, entsteht, wenn ein laufender eingehender Abgleich von einer höher priorisierten Anfrage abgelöst wurde, etwa von einer Anforderung, die jemand von Hand angestoßen hat. Microsoft bezeichnet das ausdrücklich als informative Meldung, die den normalen Betrieb anzeigt.
Ebenso harmlos ist der Hinweis, dass eine Replikationsanfrage abgesetzt wurde und auf Antwort gewartet wird. Er bedeutet schlicht, dass aus dieser Quelle gerade repliziert wird. Wer diese beiden Einträge als Störung behandelt, verbringt Zeit mit der Untersuchung eines funktionierenden Vorgangs und verliert dabei die Aufmerksamkeit für die Einträge, die tatsächlich zählen.
Bei der Auswertung des Berichts lohnt es sich deshalb, die Spalte mit dem letzten Fehler als Filter zu benutzen und alles auszublenden, was dort den Wert null trägt. Ergänzend gehören die Zeilen ausgeblendet, deren Quellserver den Zusatz für gelöschte Domänencontroller trägt, denn dabei handelt es sich um Objekte abgebauter Server. Was danach übrig bleibt, ist die Arbeitsliste, und sie ist in einer gesunden Umgebung sehr kurz.
Wann eine Reparatur keine mehr ist
Es gibt einen Punkt, ab dem ein zurückgebliebener Domänencontroller nicht mehr repariert, sondern nur noch entfernt werden kann. Er ist erreicht, wenn der Server länger als die Tombstone-Frist nicht mehr eingehend repliziert hat. In dieser Zeit sind anderswo Löschungen endgültig verarbeitet worden, und der Server kennt Objekte, die es nirgendwo sonst mehr gibt. Schließt man ihn wieder an, verteilt er diese zurückgebliebenen Objekte, und genau davor warnen die Ereignisse 1388 und 1988.
Der dokumentierte Weg ist unbequem, aber eindeutig: Der Server wird vom Unternehmensnetz in ein getrenntes Netz gebracht, dort wird Active Directory erzwungen entfernt oder das Betriebssystem neu aufgesetzt, und anschließend werden die Metadaten des Servers aus dem Verzeichnis entfernt. Der letzte Schritt ist der, den viele auslassen, und er ist der wichtigste. Ohne ihn werden gelöschte NTDS-Settings-Objekte laut Microsoft standardmäßig 14 Tage lang automatisch wiederbelebt, und die Fehlermeldungen laufen weiter.
Dieselbe Reihenfolge gilt auch für den allgemeinen Fall, in dem sich ein Replikationsproblem mit keinem bekannten Mittel lösen lässt. Microsoft beschreibt als Ausweg, Active Directory vom Server zu entfernen und neu zu installieren, und falls das im laufenden Netzbetrieb nicht möglich ist, die erzwungene Entfernung im Verzeichnisdienst-Wiederherstellungsmodus mit anschließender Metadatenbereinigung oder gleich den Neuaufbau des Servers. Ein Domänencontroller ist kein Einzelstück, und der Neuaufbau ist oft der schnellere Weg als eine offene Fehlersuche.
Werkzeuge und wo sie herkommen
Repadmin ist Teil der Remoteserver-Verwaltungstools und damit auf einem Domänencontroller ohnehin vorhanden. Auf einem Arbeitsplatzrechner kommt es über die entsprechende optionale Funktion dazu. Für die Ausführung des Gesamtberichts über alle Domänencontroller der Gesamtstruktur wird Mitgliedschaft in Enterprise Admins verlangt, was in vielen Häusern der eigentliche organisatorische Engpass ist.
Neben repadmin steht dcdiag zur Verfügung, das eine Reihe von Prüfungen gegen einen Domänencontroller ausführt und mit dem Schalter für einzelne Tests gezielt eingegrenzt werden kann. Der Nutzen liegt weniger in der Replikationsprüfung selbst, denn dafür ist repadmin genauer, sondern in den umliegenden Prüfungen: Namensauflösung, Dienste, Anmeldung und die Frage, ob der Server sich selbst für gesund hält. Beide Werkzeuge werden zusammen mit den Verwaltungswerkzeugen der Serverrolle installiert.
Für den schnellen Blick ohne Werkzeugkette gibt es zwei Wege, die Microsoft nennt. Der erste ist die Umleitung der Berichtsausgabe in ein interaktives Fenster über convertfrom-csv und out-gridview, was das Sortieren und Filtern ohne Tabellenkalkulation erlaubt. Der zweite ist ein von Microsoft bereitgestelltes Unterstützungswerkzeug mit grafischer Oberfläche, das Replikationsfehler erkennt und einordnet. Für die tägliche Sichtprüfung ist der erste Weg meistens der schnellere.
Dazu passende Kurse
Wenn die Diagnose bei euch bisher aus Ausprobieren besteht, geben dir Kurse zur Fehlersuche im Verzeichnisdienst eine feste Reihenfolge an die Hand.
Weil hinter fast jedem Replikationsfehler DNS, Kerberos oder das Netz steckt, gehören Trainings zu Namensauflösung, Zeit und Netzdiensten zur selben Baustelle.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Danke an Trainer Sven, welcher ein sehr detailliertes und fachliches KnowHow besitzt.
Ich beziehe mich hier nur auf die Nachschlung durch Herrn Marco Jachmann. Herr Jachmann ist überaus kompetent und hat alle Inhalte professionell vermittelt.
Sehr sehr gut aufbereitete Nachschulung mit genau dem notwendigen Engagement und der erforderlichen Vorbereitung innerhalb von 48 Stunden.
Häufige Fragen
Wie prüfen wir die Replikation in der ganzen Gesamtstruktur auf einmal?
Warum meldet ein Server Zugriff verweigert, obwohl das Netz nachweislich funktioniert?
Kann ein Domänencontroller nach längerer Trennung einfach wieder ans Netz?
Welche Ereigniskennungen lohnen sich in der Überwachung?
Was bedeutet der Eintrag, dass die Replikation unterbrochen wurde?
Wie oft sollten wir die Replikation prüfen?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Windows Server-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Replikationsfehler an einer echten Umgebung nachstellen
Im Aufbaukurs zu den Active Directory Domänendiensten bei cmt arbeitest du mit repadmin, dcdiag und dem Verzeichnisdienstprotokoll an Störungen, die vorher absichtlich erzeugt wurden, und siehst dabei, wie sich die Befunde voneinander unterscheiden.
Passt dazu
- Neuen Domain Controller in eine bestehende Domäne aufnehmen
- Namensauflösung im Windows-Netz schlägt fehl: DNS Schritt für Schritt eingrenzen
- FSMO-Rollen verschieben und im Ausfall übernehmen
- Domänen- und Gesamtstruktur-Funktionsebene anheben: Voraussetzungen und Reihenfolge