Active Directory & USV-Ausfall

Ein Stromausfall ist kein USN-Rollback

Der Active-Directory-Datenbank-Engine (ESE / JET Blue, dieselbe Technologie-Familie wie bei Exchange) liegt eine transaktionale, WAL-artige Architektur zugrunde: Änderungen werden zuerst ins Transaktionsprotokoll geschrieben, bevor sie in die Datenbankdatei (ntds.dit) übernommen werden. Genau dafür ist dieses Design gebaut — beim nächsten Start nach einem harten Abbruch spielt die Engine die Protokolle zurück und stellt einen konsistenten, aktuellen Zustand her. Ein einzelner, sauber isolierter Stromausfall eines Domain Controllers löst dadurch für sich genommen normalerweise keinen USN-Rollback aus.

Ein echter USN-Rollback entsteht durch etwas anderes: wenn ein Domain Controller nach dem Wiederanlauf eine Datenbank vorfindet, deren Update Sequence Number niedriger ist als die, die andere Domain Controller bereits von ihm erhalten und verarbeitet haben. Das passiert typischerweise, wenn eine ältere Sicherung oder ein älterer Snapshot eingespielt wird — nicht durch reinen Stromverlust.

Wenn ein Checkpoint angewendet wird, statt normal zu starten

Der klassische Auslöser für einen echten USN-Rollback bei virtualisierten Domain Controllern ist ein angewendeter Hyper-V-Checkpoint — jemand erstellt vor einer riskanten Änderung einen Snapshot der DC-VM "zur Sicherheit" und stellt ihn später wieder her, ohne den DC danach korrekt zu behandeln. Die VM bootet dann mit einem USN-Stand, der aus Sicht der Replikationspartner in der Vergangenheit liegt — genau das löst die Rollback-Erkennung aus (Ereignis-ID 2095) und deaktiviert die Replikation des betroffenen DC, bis er manuell bereinigt wird.

Windows Server bringt dafür seit Server 2012 einen eingebauten Schutzmechanismus mit: die VM-Generation-ID. Hyper-V ändert diese ID bei jeder Checkpoint-Anwendung, und Active Directory erkennt die Änderung beim nächsten Start — statt eines stillen, gefährlichen Rollbacks löst der DC dann automatisch eine nicht-autoritative Neusynchronisierung aus. Das ist ein echtes Sicherheitsnetz, aber kein Freibrief: Microsofts eigene Empfehlung bleibt, niemals reguläre Hyper-V-Checkpoints auf Domain-Controller-VMs zu verwenden — stattdessen ein VSS-basiertes, App-consistent System-State-Backup (z.B. Windows Server Backup oder ein entsprechendes Drittanbieter-Tool mit AD-VSS-Writer-Unterstützung).

Vier Punkte, die bei einem echten Ausfall zählen

1. Storage-Schreib-Cache ohne Power-Loss-Protection
   Die eigentliche Gefahr liegt nicht in der ESE-Engine, sondern im Speicherpfad darunter: meldet ein RAID-Controller oder eine SSD einen Schreibvorgang bereits als abgeschlossen, obwohl die Daten noch im flüchtigen Cache stehen, hilft auch die beste Transaktionsprotokollierung nichts — die Wiederherstellung setzt auf einem Zustand auf, der so nie physisch geschrieben wurde. Battery-backed oder Flash-backed Write-Cache ist hier die eigentliche Absicherung, nicht die AD-Engine.
2. SYSVOL/DFSR-Journal statt USN-Rollback
   Fällt die Replikation von SYSVOL (Gruppenrichtlinien, Anmeldeskripte) über DFSR aus dem Takt, kann das zu einem "Journal Wrap" führen, der einen nicht-autoritativen Resync erfordert — ein separates Problem von USN-Rollback, aber mit ähnlichen praktischen Folgen (Replikation steht, bis manuell eingegriffen wird).
3. FSMO-Rollen während des Ausfallfensters
   Ist ausgerechnet der PDC-Emulator während eines Ausfalls nicht erreichbar, verzögern sich zeitkritische Vorgänge (Zeitsynchronisation, dringende Passwort-Änderungen), bis er wieder verfügbar ist — ein Verfügbarkeits-, kein Korruptionsproblem.
4. Der Reflex, im Ernstfall einen Snapshot zurückzuspielen
   Der größte praktische Risikofaktor ist oft menschlich: ein DC startet nach einem chaotischen Stromausfall nicht sauber, und in der Eile greift jemand zu einem alten Checkpoint als vermeintlich schnellster Weg zurück in den Betrieb — womit erst das eigentliche Rollback-Risiko aus Abschnitt 02 entsteht. Ein geordneter, vorhersehbarer Abschalt- und Wiederanlaufprozess nimmt genau diesen Zeitdruck heraus.

Vor dem nächsten Stromausfall prüfen

1. Nie reguläre Hyper-V-Checkpoints auf DC-VMs anlegen — auch nicht "kurz zur Sicherheit" vor einem Wartungsfenster. VM-Generation-ID fängt das meiste ab, ist aber ein Sicherheitsnetz, kein Ersatz für die richtige Vorgehensweise.
2. App-consistent Backups statt Snapshots — System-State-Backup mit AD-VSS-Writer-Unterstützung als reguläre Sicherungsmethode für DC-VMs einplanen.
3. Storage-Schreib-Cache prüfen — battery-backed oder flash-backed Cache auf dem RAID-Controller, kein ungesichertes Write-Back ohne Power-Loss-Protection unter den DC-VMs.
4. Mindestens zwei DCs, physisch/stromtechnisch getrennt — idealerweise nicht an derselben USV oder demselben Stromkreis, damit ein einzelner Ausfall nie alle DCs gleichzeitig trifft.
5. Geordnetes Herunterfahren statt hartem Abbruch — der Dienst selbst profitiert weniger von der reinen Absicherung gegen Rollback als von einem schnelleren, saubereren Neustart ohne ESE-Reparaturbedarf und ohne Anlass, in der Eile zu einem Snapshot zu greifen.
6. Zeit-Hierarchie und PDC-Emulator dokumentieren — wissen, welcher DC die PDC-Emulator-Rolle hält und wie lange sein Ausfall tolerierbar ist, bevor zeitkritische Vorgänge im Netz spürbar leiden.