Ein Kollege meldete sich vor kurzem mit einem massivem Problem: Die komplette Domäne, bestehend aus einem Windows Server 2012 R2 und einem Windows Server 2016 jeweils als Domänencontroller (DC), stand still.

Vorausgegangen waren wohl schon längere Zeit (laut Log seit 2017) Schwierigkeiten mit der Replikation zwischen den beiden DCs. Nachdem der Windows Server 2012 R2 auf einen neuen Hyper-V Host verschoben wurde streikte dann der FRS-Dienst und in Folge dann die “sysvol”- und “netlogon”-Freigabe und folglich die komplette Anmeldeinfrastruktur auf beiden Servern. Kurzum: Bei einem derart langem bestehen von Fehlern und dem nun erfolgtem Totalausfall kann man wohl von einem Worst-Case-Szenario sprechen. Die Wiederherstellung einer Datensicherung hätte in diesem Moment nicht viel gebracht.

So nebenbei: Warum die Replikationsfehler vom Monitoring, in diesem Fall N-able, nicht bemerkt wurden befindet sich derzeit in Klärung.

Jedenfalls durch den Tipp eines weiteren Kollegen konnte zumindest auf dem Windows Server 2012 R2 FRS wiederbelebt werden.

Mit Hilfe der “BurFlags” lässt sich der Dienst reinitialisieren. Hierzu setzt man in der Registry unter

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

den Wert von “BurFlags” auf

D2, also known as a nonauthoritative mode restore.
D4, also known as an authoritative mode restore.

Der relevante Beitrag bei Microsoft ist dieser hier:

Microsoft Learn – Use the BurFlags registry key to reinitialize File Replication Service

In diesem Fall sind wir davon ausgegangen das der Windows Server 2012 R2 quasi der Chef ist, da dieser primär verwendet wurde und der “Backup-DC” (Windows Server 2016) wohl noch nie für eine Anmeldung zuständig war. Folglich wurde der Wert “D4” auf dem Windows Server 2012 R2 gesetzt und der FRS-Dienst neu gestartet. Nach kurzer Zeit verschwanden auf diesem Server die Fehlermeldungen im Log und die “sysvol”- und “netlogon”-Freigaben standen wieder zur Verfügung. Eine Anmeldung der Clients war jetzt ebenfalls wieder möglich.

Auf dem Windows Server 2016 wurde der Wert “D2” gesetzt, laut Log versucht dieser nun vom anderen DC zu synchronisieren. Zum Zeitpunkt des Endes unseres Telefonats waren dort allerdings die “sysvol”- und “netlogon”-Freigaben noch nicht wieder verfügbar.

Wie die Geschichte letztlich final ausgehen wird, ist zum jetzigen Zeitpunkt noch nicht abzusehen. Es folgt ein Update, sobald es etwas neues gibt.

Update 17.11.2023

Kleines Update am Rande: Der Admin vom Kunden hatte wohl ca. 3 GB an Daten in die Sysvol-Freigabe gelegt, womöglich war das der Beginn vom Übel. Mein Kollege bekommt das aktuell leider nicht gelöscht, da wohl Rechte fehlen würde. Falls jemand einen Tipp hierzu hat, dann raus damit.

Update 18.11.2023 – 13:53

Nachdem nun der Windows Server 2016-DC heruntergestuft wurde verschwanden die nicht-löschbaren Dateien aus der Sysvol-Freigabe. Es scheint als war die Replikation da richtig “durcheinander”. Übergangsweise bleibt es erstmal bei einem DC, wenn keine weiteren Überraschungen auftauchen erfolgt dann eine Migration zu Windows Server 2019 und es wird dann auch wieder ein 2. DC hinzugefügt. Ich drück’ dem Kollegen jedenfalls die Daumen das es jetzt wieder rund läuft.

Update 18.11.2023 – 15:53

Das war’s leider noch nicht: Leider fehlte plötzlich der Ordner “Policies” in der Sysvol-Freigabe, folglich konnten keine GPOs mehr verarbeitet werden. Der Kollege hat den Ordner jetzt aus der Datensicherung wiederhergestellt. Hilfreich kann zudem folgender Beitrag sein:

Microsoft Learn – How to rebuild the SYSVOL tree and its content in a domain

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.