SYSVOL-Beschädigung: Wenn Gruppenrichtlinien sterben, aber Active Directory kerngesund ist

Dienstagmorgen, das Ticketaufkommen explodiert: Anmeldeskripte laufen nicht, gemappte Laufwerke fehlen, die Default Domain Policy ist leer. Und das Verstörende daran – Active Directory meldet, dass alles in Ordnung ist. Dieser Artikel erklärt, warum das kein Widerspruch ist, wie Sie SYSVOL-Beschädigung sauber diagnostizieren und mit welcher Methode Sie in 30–60 Minuten wieder produktiv sind.

Die meisten AD-Notfälle, die ich in der Praxis sehe, sind keine spektakulären Datenbankcrashs. Es sind stille Ausfälle einer einzelnen Schicht – und SYSVOL-Beschädigung gehört zu den unterschätztesten davon. Der Grund: Sie tarnt sich als „AD-Problem“, obwohl die AD-Datenbank völlig intakt ist.

Zwei Schichten, ein Missverständnis: GPC vs. GPT

Eine Gruppenrichtlinie besteht aus zwei Teilen, die an völlig verschiedenen Orten liegen und getrennt repliziert werden:

Bei einer SYSVOL-Beschädigung ist die GPC gesund – jedes GPO-Objekt existiert in AD – aber die GPT fehlt oder ist ungültig. Die Richtlinie hat ihren „Steckbrief“ noch, aber ihren „Inhalt“ verloren. Ergebnis: gpresult /r zeigt leere oder fehlerhafte GPOs, und Anmeldeskripte laufen ins Leere.

Zuerst diagnostizieren, dann anfassen

Der häufigste Fehler ist der Aktionismus: einfach „irgendetwas wiederherstellen“. Vorher muss klar sein, welcher DC die saubere Kopie hat und in welchem DFSR-Zustand jeder DC steckt.

# DFSR-Replikationszustand und Dienst
dfsrdiag ReplicationState
Get-Service DFSR | Select-Object Name, Status

# DFSR-Ereignisse auf Fehler prüfen
Get-WinEvent -LogName 'DFS Replication' -MaxEvents 30 |
    Where-Object {$_.Level -le 3} |
    Select-Object TimeCreated, Id, Message | Format-List

# GPO-Ordner der DCs vergleichen
(Get-ChildItem 'C:\Windows\SYSVOL\sysvol\lab.local\Policies' -Directory).Count
(Get-ChildItem '\\DC-02\SYSVOL\isw.local\Policies' -Directory).Count

Die entscheidenden Ereignis-IDs im DFSR-Protokoll:

Der teuerste Irrtum: BurFlags ist tot

Wer nach einer alten Anleitung googelt, landet unweigerlich beim BurFlags-Registry-Trick mit den Werten D2 und D4. Und wartet dann vergeblich, dass etwas passiert. Der Grund ist einfach und wird selten klar gesagt:

Das Objekt liegt unter:

CN=SYSVOL Subscription,CN=Domain System Volume,
CN=DFSR-LocalSettings,CN=<Server>,OU=Domain Controllers,DC=isw,DC=local

Methode B: der schnelle Weg, wenn ein DC gesund ist

Hat ein zweiter DC ein sauberes SYSVOL, brauchen Sie keine Sicherung. Sie machen den beschädigten DC nicht-autoritativ und lassen ihn frisch vom gesunden Partner laden – schneller, sicherer und ohne DSRM. Der Trick: msDFSR-Enabled auf FALSE, dann wieder auf TRUE, ohne msDFSR-Options zu setzen.

$dc01 = "CN=SYSVOL Subscription,CN=Domain System Volume," +
        "CN=DFSR-LocalSettings,CN=DC-01,OU=Domain Controllers,DC=isw,DC=local"

# 1) Deaktivieren – DC-01 verwirft seine beschädigte Kopie
Stop-Service DFSR -Force
Set-ADObject -Identity $dc01 -Replace @{'msDFSR-Enabled'=$false}
repadmin /syncall /APed ; dfsrdiag PollAD
# Auf Ereignis 4114 warten

# 2) Wieder aktivieren – DC-01 lädt frisch von DC-02
Set-ADObject -Identity $dc01 -Replace @{'msDFSR-Enabled'=$true}
repadmin /syncall /APed ; dfsrdiag PollAD
Start-Service DFSR
# Erwartet: 4614 (Start), dann 4604 (fertig)

Die gefährlichste Abkürzung – und warum sie im Labor beide DCs zerstörte

Im Netz kursiert der Rat, bei DFSR-Problemen einfach die DFSR-Datenbank unter C:\System Volume Information\DFSR zu löschen. Das erzwingt zwar einen Neuaufbau – aber beim Start kann DFSR die lokalen Löschungen zuerst nach außen replizieren, bevor es neu lädt. Genau das ist mir im Testlabor passiert: Der gesunde DC fiel von 19 auf 16 GPO-Ordner. Aus einem beschädigten DC wurden zwei.

Die Lehre daraus ist zugleich die Daseinsberechtigung des Backups: Läuft DFSR und Sie löschen Dateien, werden diese Löschungen nach dem nächsten DFSR-Start an alle Partner verteilt. Deshalb existiert Methode A – für den Moment, in dem kein gesunder DC mehr übrig ist.

Verifizieren, nicht hoffen

Eine Wiederherstellung ist erst abgeschlossen, wenn drei Dinge stimmen: die GPO-Anzahl in SYSVOL entspricht der in AD, msDFSR-Options steht wieder auf 0 (das setzt DFSR selbst zurück), und NETLOGON ist erreichbar.

$adGpoCount    = (Get-GPO -All).Count
$sysvolGpoCount = (Get-ChildItem 'C:\Windows\SYSVOL\sysvol\lab.local\Policies' -Directory).Count
Write-Host "AD-GPOs: $adGpoCount | SYSVOL-GPT-Ordner: $sysvolGpoCount"

gpupdate /force ; gpresult /r
Test-Path '\\isw.local\NETLOGON'   # Erwartet: True

Fazit

SYSVOL-Beschädigung ist kein Weltuntergang – die RTO liegt bei 30–60 Minuten, sofern Sie die Reihenfolge kennen: erst diagnostizieren, dann die richtige Methode wählen, den BurFlags-Reflex unterdrücken und niemals im Panikmodus die DFSR-Datenbank löschen. Zwei Voraussetzungen entscheiden über Erfolg oder Katastrophe: mindestens ein gesunder DC oder eine getestete Systemstatus-Sicherung. Beides sollten Sie nicht dem Zufall überlassen.

Alle Befehle in einer isolierten Laborumgebung getestet. © 2026 IT-Service Walter · isw-adtools.de · der-windows-papst.de