DC-Lifecycle: ersetzen, entfernen, wiederherstellen

Ein virtueller Domain Controller wird nach einem misslungenen Update auf den Prüfpunkt von gestern zurückgesetzt. Er läuft, repadmin meldet null Fehler, das Monitoring ist grün — und trotzdem erreichen die Änderungen dieses Servers seine Partner nie wieder. Die Dokumentation nennt es einen stillen Replikationsausfall: Die Partner halten ihren Stand für aktuell, weshalb kein Werkzeug etwas meldet. Dieses Modul behandelt den Lebenszyklus eines Domain Controllers als das, was er ist — eine Folge von Eingriffen, die zum Teil nicht umkehrbar sind: die Reihenfolge neu vor alt, was ein DC außerhalb des Verzeichnisses noch trägt, die geordnete Demotion und ihre Parameter, Metadata-Cleanup nach einem Totalausfall, der Unterschied zwischen autoritativer und nicht autoritativer Wiederherstellung — und warum eine erfolgreiche Sicherung noch nichts über Wiederherstellbarkeit sagt.

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

Warum ein Domain Controller keine gewöhnliche VM ist

Für die meisten Server gilt eine einfache Regel: Wenn etwas kaputt ist, spiel den letzten Stand zurück. Bei einem Domain Controller ist genau das die gefährlichste Handlung im ganzen Betriebshandbuch — und der Grund liegt darin, dass ein DC nicht nur Daten hält, sondern eine Position in einem verteilten System.

Jeder DC führt Buch darüber, was er schon repliziert hat und was seine Partner von ihm kennen. Diese Buchführung ist der Grund, warum Multi-Master-Replikation ohne Endlosschleifen funktioniert — und sie ist auch der Grund, warum ein zurückgespielter Stand das gesamte Verzeichnis beschädigen kann, ohne dass etwas fehlschlägt.

Die Regel, die alles andere trägtEin Domain Controller wird ersetzt, nicht zurückgespielt. Wiederherstellung aus einer Sicherung ist ein eigenes, dokumentiertes Verfahren mit AD-fähigen Werkzeugen — kein Zurückdrehen eines Datenträgerabbilds und kein Zurücksetzen auf einen Prüfpunkt. Wer diese Unterscheidung nicht macht, hat irgendwann ein Verzeichnis, dem niemand mehr ansieht, ob es stimmt.

Der Kreis: hinzufügen, ersetzen, entfernen

Hinzufügen — neuer DC, Replikation nachgewiesen↓Übergeben — Rollen, Global Catalog, DNS-Verweise umziehen↓Entfernen — alten DC geordnet demoten↓Nachweisen — Replikation, Anmeldung und Namensauflösung ohne ihn

Neu kommt vor alt geht

Die Reihenfolge ist keine Empfehlung, sondern eine Absicherung: Solange der alte DC noch läuft, ist jeder Schritt umkehrbar. Wer zuerst entfernt und dann aufbaut, hat für die Dauer der Lücke keinen Rückweg — und arbeitet genau dann unter Zeitdruck, wenn Sorgfalt am wichtigsten wäre.

Ersetzen schlägt AufrüstenEin Domain Controller auf eine neuere Serverversion zu heben ist möglich und trotzdem selten die bessere Wahl. Ein neuer DC mit anschließender Demotion des alten liefert einen frischen, sauber installierten Server, lässt jeden Schritt einzeln prüfen und hat bis zur Demotion einen vollständigen Rückweg. Das In-Place-Upgrade spart eine Installation und kauft dafür ein Betriebssystem mit der gesammelten Konfigurationsgeschichte mehrerer Jahre — samt aller Altlasten, die niemand mehr erklären kann.

Vor der Demotion: was der DC noch mit sich trägt

Ein Domain Controller ist selten nur ein DC. Bevor er verschwindet, gehört inventarisiert, welche Aufgaben an ihm hängen — denn die meisten wandern nicht von selbst.

FSMO-Rollen: Kein automatisches Failover. Hält er eine der fünf, muss sie vorher geordnet übertragen werden.
Global Catalog: Ist er der einzige GC eines Standorts, scheitert dort nach seinem Weggang die Anmeldung in einem Forest mit mehreren Domänen.
DNS-Server: Zeigen Clients, DHCP-Bereiche oder andere Server per fester Adresse auf ihn, brechen sie — die Adresse verschwindet mit dem Server.
Anwendungspartitionen: AD-integrierte DNS-Zonen liegen in Anwendungspartitionen. Ist er die letzte Kopie, geht sie mit ihm verloren.
Zeitquelle: Hält er den PDC-Emulator, ist er zugleich die Zeitautorität der Domäne — mit allen Folgen für Kerberos.

Die Prüfung, die man leicht vergisstNicht nur Konfiguration zeigt auf einen Domain Controller, sondern auch Gewohnheit: Skripte, Monitoring-Prüfungen, Anwendungen mit hart eingetragenem Servernamen, Sicherungsaufträge. Diese Verweise stehen in keiner AD-Konsole. Sie fallen erst auf, wenn der Server weg ist — und dann als Störung ohne erkennbaren Zusammenhang.

Die geordnete Demotion

Der reguläre Weg heißt Uninstall-ADDSDomainController und setzt voraus, dass der Server läuft und erreichbar ist. Er räumt hinter sich auf: entfernt sich aus der Replikationstopologie, meldet seine Einträge im DNS ab und hinterlässt keine Metadaten im Verzeichnis.

Vier Parameter lohnen sich zu kennen, weil sie die Fälle abdecken, in denen der Standardablauf nicht genügt:

-DemoteOperationMasterRole: Bestätigt, dass gehaltene FSMO-Rollen im Zuge der Demotion abgegeben werden dürfen.
-RemoveApplicationPartitions: Entfernt Anwendungspartitionen, wenn dieser DC ihre letzte Kopie hält — eine bewusste Bestätigung, dass die Daten weg dürfen.
-LastDomainControllerInDomain: Bestätigt, dass es der letzte DC der Domäne ist. Die Domäne endet damit.
-ForceRemoval: Für den Fall, dass der DC seine Partner nicht mehr erreicht. Er entfernt sich lokal — das Verzeichnis erfährt davon nichts.

Der gefährlichste der vier-ForceRemoval beendet die Rolle auf diesem Server und hinterlässt seine Metadaten im Verzeichnis. Alle anderen DCs versuchen weiterhin, mit einem Partner zu replizieren, den es nicht mehr gibt. Der Parameter ist deshalb kein Ausweg bei Ungeduld, sondern ein Werkzeug für einen konkreten Sonderfall — und er zieht zwingend einen zweiten Arbeitsschritt nach sich.

Wenn der Server nicht mehr kommt: Metadaten bereinigen

Fällt ein Domain Controller endgültig aus — Hardware unrettbar, keine Wiederherstellung möglich —, ist eine reguläre Demotion ausgeschlossen. Sein Abbild im Verzeichnis existiert aber weiter: das Serverobjekt, das Objekt seiner Verzeichnisdienst-Einstellungen, die Verbindungen der Partner zu ihm, seine DNS-Einträge.

Metadata-Cleanup — Das gezielte Entfernen dieser Überreste aus dem Verzeichnis, üblicherweise mit ntdsutil. Erst danach hört das Verzeichnis auf, den verschwundenen Server als Replikationspartner zu erwarten.

Was ohne Bereinigung passiertDie verbliebenen DCs melden dauerhaft Replikationsfehler gegen einen Server, den es nicht mehr gibt. Der eigentliche Schaden ist aber nicht der Fehler, sondern seine Gewöhnung: Ein Monitoring, das seit Monaten dieselbe Meldung zeigt, wird weggeklickt — und wenn dann ein echter Replikationsfehler dazukommt, fällt er in der Dauerwarnung niemandem mehr auf. Nicht bereinigte Metadaten kosten deshalb weniger Verfügbarkeit als Aufmerksamkeit.

Und der Name bleibt belegtSolange die Metadaten stehen, ist auch der Name des alten Servers im Verzeichnis vergeben. Ein Ersatzserver, der wie sein Vorgänger heißen soll — der Normalfall bei einem Hardwaretausch —, scheitert daran. Die Bereinigung gehört deshalb vor den Wiederaufbau, nicht danach.

USN-Rollback: der Ausfall, den niemand sieht

Jeder DC führt fortlaufende Änderungsnummern und eine Invocation ID, die seine konkrete Datenbank-Instanz kennzeichnet. Die Partner merken sich, bis zu welcher Nummer sie von ihm alles haben. Wird die Datenbank auf einen früheren Stand zurückgesetzt, ohne dass die Partner davon erfahren, entsteht der gefährlichste Zustand des ganzen Themas.

USN-Rollback — Der Zustand, der entsteht, wenn eine ältere Fassung der Verzeichnisdatenbank zurückgesetzt wird, ohne dass die Replikationspartner es bemerken. Der DC vergibt Nummern erneut, die er schon einmal vergeben hatte — die Partner halten diesen Bereich für bereits empfangen und fordern ihn nie wieder an.

Warum das schlimmer ist als ein AusfallDie Dokumentation nennt es einen stillen Replikationsausfall: Änderungen, die an diesem DC entstehen, erreichen die anderen nie — und weil die Partner ihren Stand für aktuell halten, melden Überwachungs- und Diagnosewerkzeuge wie repadmin keinerlei Fehler. Ein defekter DC fällt auf. Ein zurückgesetzter DC arbeitet scheinbar normal weiter, während neue Konten, geänderte Kennwörter und Gruppenmitgliedschaften an ihm hängenbleiben. Der einzige direkte Hinweis ist das Ereignis 2095 im Verzeichnisdienst-Protokoll.

Die Auslöser sind dabei alles andere als exotisch — sie sind der Alltag jeder Virtualisierungsumgebung: das Starten eines zuvor gesicherten Datenträgerabbilds, das Zurücksetzen auf einen Prüfpunkt, ein Speicher-Snapshot des Datenträgers mit ntds.dit. Alles Handlungen, die bei jedem anderen Server harmlos und richtig sind.

Was die Virtualisierung rettet — und was nicht

Für genau dieses Problem gibt es einen Schutzmechanismus. Moderne Hypervisoren vergeben einer virtuellen Maschine eine Generations-Kennung, die sich ändert, sobald die VM auf einen früheren Zustand zurückgesetzt wird.

Wie der Schutz funktioniertBemerkt der Verzeichnisdienst eine neue Generations-Kennung, verhält er sich laut Dokumentation so, als sei der Domain Controller aus einer Sicherung wiederhergestellt worden: Er erzeugt eine neue Invocation ID. Damit ist die Datenbank-Instanz für die Partner eine andere, sie passen ihre Stände an, und der DC kann gefahrlos wieder replizieren. Aus einer stillen Katastrophe wird ein geordneter Wiedereinstieg.

Die Grenzen, die man kennen mussDer Schutz greift nur, wo er vorhanden ist — er verlangt einen Hypervisor, der die Kennung unterstützt, und ein Gastsystem, das sie auswertet. Er hilft nicht bei einem Zurückspielen auf Ebene des Speichersystems, das die VM gar nicht bemerkt, und nicht bei einem Datenträgerabbild, das außerhalb dieses Mechanismus eingespielt wird. Die Regel bleibt deshalb bestehen: Ein Domain Controller wird mit einem AD-fähigen Verfahren wiederhergestellt, nicht zurückgedreht. Der Schutzmechanismus ist ein Sicherheitsnetz, kein Freibrief.

Sicherung ist nicht Wiederherstellbarkeit

„Wir haben nächtliche Sicherungen, alle erfolgreich.“ Dieser Satz beantwortet die Frage nicht, die zählt. Eine erfolgreiche Sicherung belegt, dass ein Schreibvorgang durchgelaufen ist — nicht, dass sich daraus ein funktionierendes Verzeichnis herstellen lässt.

Ist die Sicherung AD-fähig, also über die dafür vorgesehenen Schnittstellen erstellt — oder ein Abbild des Datenträgers, dessen Rückspielen genau den stillen Ausfall erzeugt?
Ist sie jünger als die Tombstone-Lifetime? Eine ältere Sicherung bringt Objekte zurück, deren Löschung im Verzeichnis nicht mehr bekannt ist.
Wurde die Wiederherstellung je durchgeführt — und wann zuletzt, mit welchem Ergebnis und wie lange hat sie gedauert?
Ist das DSRM-Kennwort dieses Servers bekannt und hinterlegt? Ohne es beginnt die Wiederherstellung mit einem zusätzlichen Problem.

Der Nachweis, der zähltEin Wiederherstellungstest ist keine Formalie, sondern der einzige Beleg. Er beantwortet außerdem eine Frage, die niemand auf dem Papier beantworten kann: wie lange es dauert. Diese Zahl entscheidet im Ernstfall darüber, ob wiederhergestellt oder neu aufgebaut wird — und wer sie nicht kennt, trifft diese Entscheidung unter Druck mit einer Schätzung.

Die Zahl, die im Ernstfall zähltEin Forest lässt sich aus Sicherungen wiederherstellen, aber das Verfahren ist lang, streng sequenziell und verlangt, dass währenddessen kein anderer Domain Controller mitredet. Wer es nie geübt hat, entdeckt seine Abhängigkeiten mitten darin. Deshalb ist die brauchbarste Kennzahl nicht „wir sichern täglich“, sondern: Wie viele Stunden vergehen zwischen der Entscheidung und der ersten erfolgreichen Anmeldung? Diese Zahl bekommt man nur aus einer Übung — und sie ist regelmäßig ein Vielfaches der Schätzung.

Durchgerechnet: einen Domain Controller ersetzen

DC01 geht, DC03 kommt

Szenario

DC01 läuft auf einer alten Serverversion und hält den PDC-Emulator sowie die einzige Global-Catalog-Rolle des Standorts. Er soll ersetzt werden. DC02 ist gesund und an einem anderen Standort.

Anforderungen

Zu jedem Zeitpunkt ein Rückweg
Kein Zeitfenster ohne lokale Anmeldemöglichkeit
Jeder Schritt mit einem Nachweis

Schritte

Inventarisieren: Welche Rollen, welche Anwendungspartitionen, welche festen Verweise zeigen auf DC01? Die DHCP-Bereiche und Skripte gehören ausdrücklich dazu — sie stehen in keiner AD-Konsole.
`DC03` aufbauen und als Global Catalog aufnehmen. Replikation in beide Richtungen nachweisen, bevor irgendetwas an DC01 verändert wird.
Verweise umziehen: DHCP-Bereiche und alles, was fest auf DC01 zeigt, auf DC03 umstellen — vor der Demotion, damit ein Fehler hier noch folgenlos ist.
Rollen übertragen: Den PDC-Emulator geordnet auf einen gesunden DC übertragen. Übertragen, nicht erzwingen — DC01 lebt ja noch, und das ist der ganze Vorteil dieser Reihenfolge.
Nachweis ohne `DC01`: Den Server für eine definierte Zeit vom Netz nehmen und prüfen, ob Anmeldung, Namensauflösung und Richtlinienverarbeitung am Standort weiterlaufen. Fällt etwas auf, lässt sich DC01 einfach wieder anschließen — der letzte Moment, in dem das gilt.
Demotion mit Uninstall-ADDSDomainController, danach die DNS-Einträge und die Metadaten prüfen. Abschließend repadmin /replsummary ohne Fehler.

Merksatz: Der Wert der Reihenfolge liegt im vorletzten Schritt: Ihn zu überspringen spart eine Stunde und tauscht sie gegen die Gewissheit. Bis zur Demotion ist jeder Fehler eine Unannehmlichkeit — danach ist er ein Vorfall.

Autoritativ oder nicht: zwei völlig verschiedene Wiederherstellungen

Wird ein Domain Controller aus einer Sicherung zurückgeholt, gibt es zwei Betriebsarten — und die Wahl zwischen ihnen entscheidet über das Ergebnis für den gesamten Forest, nicht nur für diesen Server.

Nicht autoritativ: Der Server kommt mit altem Stand zurück und lässt sich von seinen Partnern auf den aktuellen Stand bringen. Der Normalfall — repariert einen Server.
Autoritativ: Bestimmte Objekte werden bewusst als die gültige Fassung markiert und überschreiben den Stand aller anderen DCs. Der Ausnahmefall — repariert Inhalte.

Die Frage, die die Wahl entscheidetIst ein Server kaputt oder sind Daten verloren? Ein defekter DC braucht eine nicht autoritative Wiederherstellung — oder, meistens billiger, einen Neuaufbau. Versehentlich gelöschte Objekte brauchen den autoritativen Weg, und der ist gefährlich: Er überschreibt bei falschem Umfang auch Änderungen, die nach dem Sicherungszeitpunkt legitim entstanden sind. Wer den Umfang nicht genau eingrenzt, stellt gemeinsam mit dem Gelöschten auch alte Kennwörter und alte Gruppenmitgliedschaften wieder her.

Und der bessere Weg für gelöschte ObjekteFür versehentliche Löschungen ist die Wiederherstellung aus einer Sicherung fast nie das richtige Werkzeug. Der AD-Papierkorb hält gelöschte Objekte samt ihrer Attribute für eine konfigurierte Zeit vor und gibt sie ohne Ausfallzeit und ohne Neustart zurück. Die Voraussetzung dafür ist allerdings, dass er vorher aktiviert wurde — nachträglich hilft er für bereits gelöschte Objekte nicht.

Der Change vor dem Eingriff

Die Handgriffe dieses Moduls unterscheiden sich in einem Punkt von fast allem anderen im Betrieb: Mehrere davon sind nicht umkehrbar. Das ändert, was eine Freigabe leisten muss — sie ist hier keine Formalie, sondern der letzte Punkt, an dem jemand die Reihenfolge prüft.

Umkehrbar: Einen DC hinzufügen, eine Rolle geordnet übertragen, einen Global Catalog ergänzen. Bei Fehlern zurückdrehbar.
Aufwendig umkehrbar: Eine Demotion — der Server lässt sich erneut promoten, aber nicht in seinen vorherigen Zustand zurückversetzen.
Nicht umkehrbar: Eine erzwungene Rollenübernahme, ein Metadata-Cleanup, eine autoritative Wiederherstellung, das Anheben einer Funktionsebene.

Was in der Freigabe stehen mussFür jeden Eingriff der dritten Zeile gehören drei Angaben in den Change: Was genau wird unumkehrbar, welche Beobachtung rechtfertigt den Schritt, und was ist der Plan, wenn er nicht das erwartete Ergebnis bringt. Der dritte Punkt ist der, der am häufigsten fehlt — und der einzige, der im Ernstfall noch hilft, weil die ersten beiden dann schon Geschichte sind.

Prüf dich selbst, bevor es zählt

Kurzcheck

Nach einem fehlgeschlagenen Update setzt ein Kollege einen virtuellen Domain Controller auf den Prüfpunkt von gestern zurück. Der Server startet, alles wirkt normal, repadmin meldet keine Fehler. Wie bewertest du die Lage?

Unauffällig — dass repadmin keine Fehler meldet, belegt eine funktionierende Replikation.
Prüfen, ob Ereignis 2095 protokolliert wurde — ohne unterstützte Generations-Kennung droht ein stiller Replikationsausfall.
Problematisch, aber selbstheilend: Beim nächsten Replikationszyklus gleicht der DC seinen Rückstand automatisch aus.

Treffer. Richtig. Entweder hat der Hypervisor die Generations-Kennung geliefert und der Dienst hat eine neue Invocation ID erzeugt — dann ist es geordnet. Oder nicht, dann liegt ein USN-Rollback vor, den nur dieses Ereignis anzeigt.

Damit stehen die Achsen: ersetzen statt zurückspielen, die Reihenfolge neu vor alt, die Inventur dessen, was ein DC noch trägt, die geordnete Demotion und ihre Parameter, Metadata-Cleanup nach einem Totalausfall, der USN-Rollback als stiller Ausfall samt Ereignis 2095, die Generations-Kennung als Sicherheitsnetz mit Grenzen — und der Wiederherstellungstest als einziger Beleg für Wiederherstellbarkeit.

Gleich im CheckIn den folgenden Übungen ordnest du eine Ablösesequenz, entscheidest über eine erzwungene Entfernung und beurteilst, was eine erfolgreiche Sicherung tatsächlich beweist.

Jetzt anwenden

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

Zum Modul →

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