SYSVOL-Replikation hängt im Status 2 (PRE_EXISTING) nach DC-Promo – Durchführung D2/D4 DFSR Restore

Question

SYSVOL-Replikation hängt im Status 2 (PRE_EXISTING) nach DC-Promo – Durchführung D2/D4 DFSR Restore

Gorki Maxim 20

Hallo,

bei der Bereitstellung eines neuen Domain Controllers steckt der DFSR-Initial-Sync des SYSVOL-Ordners fest. Das dcpromo lief sauber durch, aber der Replikationsstatus verharrt dauerhaft im Status State 2 (PRE_EXISTING). Die Gruppenrichtlinien werden folglich nicht auf den neuen DC repliziert und die NETLOGON- sowie SYSVOL-Freigaben fehlen.

Da der Fehler beim initialen Abgleich liegt, möchten wir ein Non-Authoritative Restore (D2) (bzw. falls erforderlich ein Authoritative Restore (D4)) durchführen.

Dazu hätte ich folgende Fragen an die Runde:

D2-Procedure via ADSIEdit/PowerShell: Wie sieht der exakte, sauber strukturierte Ablauf aus, um msDFSR-Enabled bzw. msDFSR-Options korrekt zu setzen und das D2-Flag getriggert zu bekommen?
Datenbank-Integrität & State-Wechsel: Welche konkreten Schritte und Event-IDs (z. B. 4114, 4614, 4604) müssen geprüft werden, damit die DFSR-Datenbank ohne Datenverlust wieder verlässlich in den State 4 (NORMAL) übergeht?

Über ein bewährtes PowerShell-Skript oder eine praxiserprobte Step-by-Step-Anleitung würde ich mich sehr freuen!

0 Kommentare

1 Antwort

Ihre Antwort

Answer 1

Hallo,

der von Ihnen beschriebene Zustand „State 2 (PRE_EXISTING)“ beim initialen DFSR‑Sync des SYSVOL ist ein klassisches Szenario, wenn der neue Domain Controller nach dcpromo zwar korrekt eingebunden ist, aber die DFSR‑Datenbank den SYSVOL‑Inhalt nicht als autoritativ erkennt. In diesem Fall ist ein Non‑Authoritative Restore (D2) das richtige Vorgehen, um den neuen DC dazu zu bringen, die SYSVOL‑Daten von einem funktionierenden Partner zu replizieren. Nur wenn Sie den neuen DC als Quelle für alle anderen erzwingen wollen, wäre ein Authoritative Restore (D4) notwendig.

Der Ablauf für ein D2‑Restore ist wie folgt: Sie setzen über ADSIEdit oder PowerShell das Attribut msDFSR-Options auf den Wert 1 für das betroffene SYSVOL‑Replikationsobjekt. In PowerShell können Sie dies mit dem AD FS‑Modul für DFSR tun, beispielsweise:

powershell

# Beispiel: D2-Flag setzen für SYSVOL
$object = Get-ADObject -LDAPFilter "(cn=SYSVOL Subscription)" -SearchBase "CN=Domain System Volume,CN=DFSR-GlobalSettings,CN=System,DC=<IhreDomäne>,DC=<TLD>" -Properties msDFSR-Options
Set-ADObject -Identity $object -Replace @{msDFSR-Options=1}

Danach stoppen und starten Sie den DFSR‑Dienst (net stop dfsr && net start dfsr). Der Dienst erkennt das D2‑Flag und initialisiert den Non‑Authoritative Restore.

Für die Überwachung sind die Event‑IDs entscheidend:

4114: DFSR stoppt die Replikation für SYSVOL (erwartet beim Setzen des D2).

4614: DFSR beginnt den Initial Sync.

4604: DFSR meldet, dass die Replikation abgeschlossen ist und der State auf „NORMAL“ gewechselt wurde.

Wenn Sie ein D4 durchführen müssen, setzen Sie msDFSR-Options auf 2 und starten den Dienst neu. Damit wird dieser DC als autoritative Quelle markiert, und alle anderen replizieren von ihm.

Wichtig ist, dass Sie nach dem Restore prüfen, ob die Freigaben SYSVOL und NETLOGON wieder vorhanden sind und die Gruppenrichtlinien repliziert werden. Sie können dies mit dfsrdiag pollad erzwingen und mit dfsrdiag replstate den Status kontrollieren.

Damit haben Sie einen sauberen, praxiserprobten Ablauf für D2/D4, inklusive der relevanten Attribute und Event‑IDs, um den DFSR‑Initial‑Sync zuverlässig in den State 4 (NORMAL) zu bringen.

Domic Vo.