Eine Domäne, 2 DCs und kein Sysvol oder Netlogon verfügbar

Dies ist mal wieder eine Geschichte aus dem Nähkästchen eines ITlers, der dachte, er hat schon fast alles gesehen. Es sollte mal wieder anders kommen. 

Wir hatten einen neuen Kunden – eine Arztpraxis. Schnell war klar: In der bisherigen IT-Betreuung war in den letzten Jahren einiges aus dem Ruder gelaufen. Der vorhandene Server war über acht Jahre alt, lief noch mit Windows Server 2012 R2, und so war klar: Eine Erneuerung musste her. Im Zuge des Onboardings haben wir alles, was möglich war, auf den aktuellen Stand gebracht. Der Vor-Ort-Termin rückte näher, der neue Server war vorbereitet – zwei VMs, eine davon sollte der neue Domain Controller werden. Und damit begann die Geschichte einer 12-stündigen Odyssee, die mich an den Rand des Verzweiflung brachte.

Wenn SYSVOL einfach nicht will: Eine nervenaufreibende Migration

Eigentlich sollte es ein ganz normaler Domain-Controller-Wechsel werden: Der alte DC-alt (Windows Server 2012 R2) hatte seine besten Tage hinter sich, und der neue DC-neu (Windows Server 2022) war frisch installiert, heraufgestuft und bereit, den Staffelstab zu übernehmen. Doch wie so oft steckt der Teufel im Detail – in diesem Fall in der SYSVOL-Replikation.

Obwohl DC-neu als DC aktiv war und auch alle FSMO-Rollen übernehmen konnte, wurde die SYSVOL-Freigabe nicht bereitgestellt. Gruppenrichtlinien liefen schief, der dfsrmig-Status hing dauerhaft bei "Starten", und dcdiag war voll mit DFS-Warnungen. Ein Blick in die Ereignisanzeige bestätigte den Verdacht: Der Server hatte seit über 3800 Tagen keinen Replikationspartner mehr gesehen – zumindest laut DFS-Replikation.

Ich habe gefühlt jede Lösung aus den letzten 15 Jahren Erfahrung und Forenbeiträgen sowie KI ausprobiert:

• repadmin /syncall /AdeP zur forcierten Replikation – lief ohne Fehler, brachte aber keine Änderung am SYSVOL-Zustand.

• dcdiag zeigte an, dass DC-neu zwar technisch als DC aktiv war, aber weder NETLOGON noch SYSVOL verfügbar machte.

• dfsrdiag SyncNow meldete sich bereitwillig mit Erfolgsmeldungen – ohne spürbare Wirkung.

• dfsrmig /getmigrationstate bestätigte das Dilemma: Der neue DC kam über den Status "Starten" nicht hinaus.

• Ein direkter Eingriff in das AD-Objekt per Set-ADObject sollte den msDFSR-Options-Wert auf 1 setzen, aber das entsprechende Objekt war gar nicht vorhanden.

• Get-ADObject-Abfragen nach „SYSVOL Subscription“ blieben leer – das Objekt war schlicht nicht da, oder nicht da wo es sein sollte.

• Auch ein WMIC-Befehl zur SetState-Änderung (SetState 1) endete mit einem kryptischen „ungültige Klassenmethode“-Fehler – höchstwahrscheinlich ein Sprachproblem in der deutschen Windows-Version.

Als wäre das nicht genug, offenbarte ein Blick in die DFS-Verwaltung noch ein weiteres Problem: Neben DC-alt und DC-neu tauchte dort ein drittes, nicht definiertes SYSVOL-Mitglied auf – deaktiviert, ohne bekannten Pfad oder Status. Ein Zombie-Objekt, vermutlich ein Überbleibsel eines längst vergessenen (oder nie korrekt entfernten) früheren Domain Controllers.

Kurz: Die klassische Methode der SYSVOL-Migration über dfsrmig war in diesem Fall gescheitert. Kein noch so wohlmeinender PowerShell-Befehl konnte die Replikation anstoßen. Die einzige Lösung: Replikationsgruppen aufräumen, das alte Zombie-Mitglied manuell löschen und die SYSVOL-Replikation auf frischem Weg neu starten.

💡 Anleitung: DFS-Replikation (SYSVOL) aufräumen und wiederherstellen nach Jahren ohne Replikation

Plötzlich fällt mir eine Fehlermeldung ins Auge.

Und dann war klar, was hier zu tun war. 

1. Replikation überprüfen:

For /f %i IN ('dsquery server -o rdn') do @echo %i && @(net view \\%i | find "SYSVOL") & echo

2. Status der DFS Replikation herausfinden: 

For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state

Der Status steht dabei für:

0 = Uninitialized
1 = Initialized
2 = Initial Sync
3 = Auto Recovery
4 = Normal
5 = In Error

3. Problem also erkannt, Status stand auf 5 beim alten DC, beim neuen DC auf 2. Wir wollen
also jetzt die Replikation fortsetzen. Daher: 

4. MaxOfflineTimeInDays nach oben setzen: 

For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays

In unserem Fall hier auf 4000. 

wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=4000

Und siehe da, innerhalb von Sekunden läuft nicht nur die Replikation, auch die verschollenen SysVol und Netlogon-Einträge sind auf dem neuen DC vorhanden.

Und was lernen wir daraus?

Ich habe Powershell / AD-Kenntnisse der letzten Jahre aufgefrischt - ich bin fit, wer Hilfe braucht: nur her mit euren Fragen! 😆 Spaß beiseite: Noch genauer vorbereiten, mehr Skripte zum Testen von Domänen entwickeln und in unsere RMM-Systeme einbinden und das Onboarding auf noch tiefere Ebenen stellen. Das wird mir nicht mehr passieren.