USN-Rollback auf Domain Controllern erkennen und beheben
Montagmorgen, 8 Uhr: Ein Kennwort wurde zurückgesetzt, die Anmeldung scheitert trotzdem. Der neue Kollege existiert nur auf einem DC. Und repadmin meldet keinen einzigen Fehler. Willkommen beim USN-Rollback – einem der leisesten Notfälle im Active Directory.
Was passiert bei einem USN-Rollback?
Jeder Domain Controller nummeriert seine eigenen Änderungen fortlaufend mit einer Update Sequence Number (USN). Seine Datenbank trägt außerdem eine eindeutige Kennung, die Invocation ID. Die Replikationspartner merken sich für jeden DC, bis zu welcher USN sie bereits alles erhalten haben.
Wird ein DC am Active Directory vorbei in die Vergangenheit zurückgesetzt, behält er seine alte Invocation ID und vergibt USNs, die seine Partner längst kennen. Die Partner halten jede neue Änderung für „schon erhalten“ und fordern sie gar nicht erst an. Es gibt keinen Abbruch und keine Fehlermeldung. Das Verzeichnis driftet still auseinander.
| Symptom | Ursache |
|---|---|
| Anmeldung scheitert trotz neuem Kennwort | Kennwortänderung erreicht die Partner nie |
| Benutzer, Computer oder Gruppen fehlen auf einzelnen DCs | Neue Objekte replizieren nicht |
| Gruppenmitgliedschaften unterscheiden sich je DC | Änderungen an Mitgliedschaften gehen verloren |
| DNS-Einträge fehlen in AD-integrierten Zonen | DNS-Registrierungen sind ebenfalls AD-Objekte |
| Doppelte SIDs | RIDs werden ein zweites Mal vergeben |
Typische Auslöser
- Ein älterer VM-Snapshot oder Prüfpunkt wird gestartet
- Eine LUN wird per SAN- oder Storage-Snapshot zurückgesetzt
- Ein Image oder eine kopierte VHDX/VMDK wird eingespielt
- Eine Sicherungssoftware ohne AD-Unterstützung stellt die ganze VM wieder her
Get-ADComputer DC1 -Properties msDS-GenerationId | Select-Object Name, msDS-GenerationId
Ist das Attribut leer, liefert der Hypervisor keine VM-Generation-ID. Snapshots dieses DCs sind dann tabu.
Diagnose: Welcher DC ist zurückgerollt?
Bevor irgendetwas geändert wird, muss klar sein, welcher DC betroffen ist und welche Änderungen nur dort existieren. Drei Nachweise kommen infrage.
1. Ereignisse im Protokoll „Directory Service“
Ereignis 2095 meldet, dass ein Partner bereits bestätigte USNs erneut erhalten hat. Ereignis 2103 meldet eine nicht unterstützte Wiederherstellung. 1113 und 1115 zeigen deaktivierte Replikation.
Get-WinEvent -FilterHashtable @{LogName='Directory Service'; Id=2095,2103,1113,1115} |
Select-Object TimeCreated, Id, MachineName, Message | Format-List
2. Quarantäne in der Registry
Erkennt der DC den Rollback, stellt er sich selbst unter Quarantäne: Netlogon wird pausiert, die Replikation abgeschaltet und „Dsa Not Writable“ auf 4 gesetzt.
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' -Name 'Dsa Not Writable' -ErrorAction SilentlyContinue Get-Service Netlogon
3. USN-Vergleich
Der sicherste Nachweis, auch wenn die Ereignisse längst überschrieben sind: Kennen die Partner für einen DC eine höhere USN als dieser DC selbst, ist er zurückgerollt.
(Get-ADRootDSE -Server DC1).highestCommittedUSN repadmin /showutdvec DC2 "DC=contoso,DC=com"
Steht im Vektor von DC2 für DC1 eine höhere USN als highestCommittedUSN auf DC1, und meldet repadmin /showrepl trotzdem keine Fehler, liegt ein USN-Rollback vor.
Beheben: zwei saubere Wege
Zuerst den betroffenen DC isolieren, die FSMO-Rollen mit netdom query fsmo ermitteln und alle Objekte exportieren, die seit dem Rollback-Zeitpunkt auf diesem DC geändert wurden. Diese Liste braucht man später zum Nachziehen.
$seit = Get-Date '2026-10-12 06:00'
Get-ADObject -Server DC1 -Filter {whenChanged -ge $seit} -Properties whenChanged, objectClass |
Select-Object Name, objectClass, whenChanged, DistinguishedName |
Export-Csv C:\ISW\usn-dc1-aenderungen.csv -NoTypeInformation -Encoding UTF8
Methode A – Systemstatus-Sicherung wiederherstellen
Geeignet, wenn eine echte Systemstatus-Sicherung desselben DCs existiert, die vor dem fehlerhaften Rollback entstand. Die Wiederherstellung im DSRM setzt die Invocation ID korrekt zurück, anschließend holt der DC alle fehlenden Änderungen von seinen Partnern.
bcdedit /set safeboot dsrepair shutdown /r /t 0 # im DSRM: wbadmin get versions wbadmin start systemstaterecovery -version:10/11/2026-22:00 bcdedit /deletevalue safeboot
Methode B – herabstufen und neu heraufstufen
Fast immer der bessere Weg, solange ein weiterer gesunder DC läuft: Der zurückgerollte DC fliegt aus dem Verzeichnis und wird frisch aufgebaut.
- Auf dem betroffenen DC erzwungen herabstufen und herunterfahren.
- Auf einem gesunden DC die Metadaten bereinigen, inklusive DNS-Einträgen und Serverobjekt in „Standorte und Dienste“.
- FSMO-Rollen des alten DCs auf einen gesunden DC übernehmen.
- Den Server neu als DC installieren und die Replikation prüfen.
# 1. auf DC1 Uninstall-ADDSDomainController -ForceRemoval -DemoteOperationMasterRole ` -LocalAdministratorPassword (Read-Host 'Lokales Admin-Kennwort' -AsSecureString) # 2. auf DC2 ntdsutil "metadata cleanup" "remove selected server CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=contoso,DC=com" q q # 3. auf DC2 Move-ADDirectoryServerOperationMasterRole -Identity DC2 ` -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster -Force # 4. auf DC1 nach Neustart Install-ADDSDomainController -DomainName contoso.com -InstallDns -Credential (Get-Credential) repadmin /replsummary dcdiag /v /c /e /q
Danach die Objekte aus der Exportliste nachziehen. Kennwörter lassen sich nicht übertragen: Betroffene Benutzer bekommen ein neues. Computer, deren Kennwortwechsel verloren ging, repariert man mit Test-ComputerSecureChannel -Repair.
Fallstricke
Doppelte SIDs. Ein zurückgerollter DC kennt die RIDs nicht mehr, die er nach dem Snapshot bereits vergeben hat. Hält er den RID-Master, kann er sogar ganze RID-Pools doppelt zuteilen. Nach jeder Bereinigung prüfen:
ntdsutil "security account management" "connect to server DC2" "check duplicate SID" q q
Vorbeugen und Compliance
- Täglich eine echte Systemstatus-Sicherung je DC und die Wiederherstellung regelmäßig üben
- Prüfpunkte und Snapshots für DCs deaktivieren, LUNs mit NTDS.dit nie auf Storage-Ebene zurücksetzen
- msDS-GenerationId auf allen virtuellen DCs prüfen
- Ereignisse 2095, 2103, 1113, 1115 und den Wert „Dsa Not Writable“ zentral überwachen
- Den Notfallablauf schriftlich festhalten
Das zahlt direkt auf die Anforderungen ein: BSI IT-Grundschutz APP.2.2 (Active Directory Domain Services), CON.3 (Datensicherungskonzept) und DER.4 (Notfallmanagement) sowie NIS2 Art. 21 Abs. 2 lit. c mit Backup-Management, Wiederherstellung und Aufrechterhaltung des Betriebs.
Fazit
Ein Snapshot ist kein Backup – erst recht nicht bei einem Domain Controller. Wer den Rollback nur entsperrt, hat ihn verteilt. Mit sauberer Diagnose und einem zweiten gesunden DC ist das Problem in 60 bis 120 Minuten pro DC erledigt.
USN-Rollback
Send download link to:
