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.
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.
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=4000Und 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.
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.