SYSVOL-Migration von FRS zu DFSR: jeden DC vor Eliminated bestätigen

Was bedeutet die SYSVOL-Migration von FRS zu DFSR?

Eine SYSVOL-Migration von FRS zu DFSR ändert, wie Domänencontroller die Dateien für Gruppenrichtlinien und Anmeldeskripts replizieren. Dafür ist ein domänenweiter Ablaufplan erforderlich: den aktuellen Zustand erfassen, die Replikation auf jedem Domänencontroller validieren und erst dann zur nächsten Phase wechseln, wenn die Nachweise dies erlauben.

Technische Prüfung: 4. Oktober 2026. Die folgenden Befehle sind Beispiele aus der Dokumentation; sie wurden nicht in einer Produktionsdomäne ausgeführt.

File Replication Service (FRS) ist veraltet, wie Microsoft in den Hinweisen zur Abkündigung von FRS dokumentiert. DFS Replication (DFSR) steht für SYSVOL ab der Domänenfunktionsebene Windows Server 2008 zur Verfügung. Der aktuelle Leitfaden zur SYSVOL-Migration bleibt der Ausgangspunkt für das unterstützte Verfahren.

Behandeln Sie dies als Projekt zur Konfiguration und Verfügbarkeit. Ein Signal für ein älteres Replikationsverfahren belegt weder einen Angriff noch einen kompromittierten Controller oder ein fehlerhaftes GPO. Ebenso kann das Ausbleiben von Befunden keine irreversible Änderung freigeben. Legen Sie vor der Terminplanung fest, welche Nachweise der Domänenverantwortliche benötigt.

Dieses Projekt gehört neben Ihre Planung des Upgrades von Windows Server 2016-Domänencontrollern, die Betriebssysteme und Funktionsebenen behandelt. Führen Sie für die SYSVOL-Migration separate Nachweise: Der Austausch eines DC oder die Prüfung seines Betriebssystems dokumentiert nicht den Migrationszustand jedes Controllers.

Funktionsweise: globale Vorgabe und lokale Konvergenz

Der PDC-Emulator hält die über dfsrmig /setglobalstate gesetzte Migrationsvorgabe. Jeder Domänencontroller muss den entsprechenden lokalen Zustand selbst erreichen. Ein Befehl, der die globale Vorgabe ändert, markiert deshalb den Beginn einer Phase und beweist nicht, dass alle Controller sie abgeschlossen haben.

Microsoft beschreibt in der Referenz zu den SYSVOL-Migrationszuständen diese stabilen Phasen:

Während der Durchführung können lokale Zustände Übergangszustände sein. Halten Sie Controller, die offline, nicht erreichbar oder noch im Übergang sind, im Migrationsprotokoll sichtbar. Entfernen Sie sie nicht aus der Abnahmeliste, nur damit die Änderung abgeschlossen erscheint.

Erkennung: vor jeder Änderung die Zustände dokumentieren

Den globalen Zustand auf dem PDC-Emulator abfragen

Führen Sie diesen Abfragebefehl auf dem PDC-Emulator aus, wie es die Befehlsreferenz zu dfsrmig verlangt:

dfsrmig /getglobalstate

Erfassen Sie anschließend den domänenweiten Konvergenzbericht:

dfsrmig /getmigrationstate

Der erste Befehl liest den globalen Zustand der Domäne. Der zweite gleicht die lokalen Zustände mit dieser Vorgabe ab und meldet Controller, die sie noch nicht erreicht haben. Die Befehlsreferenz warnt, dass die Abfrage des globalen Zustands auf einem anderen Controller wegen der AD-Replikationslatenz inkonsistente Informationen liefern kann.

Beispielhafte Interpretation, keine beobachtete Ausgabe: Global Prepared mit einem Controller, der noch Start oder einen Übergangszustand meldet, bedeutet, dass die Prepared-Freigabe noch aussteht. Global Redirected mit übereinstimmenden lokalen Zuständen erfüllt die Zustandsprüfung, erfordert aber weiterhin die Validierung der Freigaben und der Replikation. Global Eliminated ohne verwertbaren Konvergenzbericht ist ein unvollständiger Nachweis und kein verifizierter Abschluss.

Dokumentieren Sie für jede Erfassung die Domäne, die Identität des PDC, das Controller-Inventar, den Erfassungszeitpunkt, den Befehl und die vollständige Ausgabe. Ein nicht erreichbarer Controller benötigt einen Verantwortlichen und einen Lösungsplan. Bewahren Sie frühere Erfassungen auf, damit Prüfer tatsächlichen Fortschritt von einem veränderten Inventar unterscheiden können.

LDAP-Abonnement und Dienstnachweise prüfen

Der untersuchte etc-collector-Provider versucht unterhalb seines konfigurierten Basis-DN eine LDAP-Unterbaumsuche mit dem folgenden Filter. Er fordert cn an und behält clientseitig höchstens ein Ergebnis:

(&(objectClass=nTFRSSubscriber)(name=Domain System Volume (SYSVOL share)))

Dies ist der wörtliche Filter des Providers, als Codebeleg und nicht als direkt ausführbarer LDAP-Clientbefehl dargestellt. In der untersuchten Collector-Revision (42bfefb) sind die Klammern im Namenswert nicht maskiert. Eine lokale Prüfung ausschließlich mit dem Parser der deklarierten Abhängigkeit go-ldap v3.4.12 ergab Filter Compile Error; die Suchanfrage lässt sich mit diesem Filter nicht kodieren. Für diese Prüfung wurde keine LDAP-Abfrage in einer Produktionsumgebung ausgeführt.

Dieser Erfassungsfehler lässt das FRS-Flag im untersuchten Provider auf false. Selbst wenn eine korrigierte Abfrage erfolgreich ein Abonnementobjekt zurückliefert, würde dieses Objekt allein weder alle Controller identifizieren noch feststellen, welcher Dienst SYSVOL aktuell bereitstellt, oder einen Migrationsrest ausschließen.

Dokumentieren Sie auf jedem DC außerdem in Services den Status und die Startkonfiguration von File Replication (NTFRS) und DFS Replication (DFSR). Gleichen Sie diese Beobachtungen mit dem Migrationszustand und der tatsächlichen Freigabezuordnung ab. Ein laufender Dienst allein belegt keine erfolgreiche SYSVOL-Replikation.

Verwenden Sie eine kleine Nachweismatrix anstelle eines einzelnen grünen Häkchens:

Unterscheiden Sie in der betrieblichen Dokumentation Erfassungsfehler von negativen Ergebnissen. Dieser Artikel enthält weder eine Angriffsabfrage noch eine Windows Event ID; die Entscheidung beruht hier auf Migrations- und Replikationsnachweisen.

Abhilfe: dokumentierte Freigabestufen durchlaufen (Remediation)

Schritt 1 — Inventar, Voraussetzungen und Wiederherstellungsbereitschaft

Benennen Sie den Domänenverantwortlichen und den Ausführenden der Änderung. Inventarisieren Sie jeden beschreibbaren DC und RODC, einschließlich entfernter Standorte und vorübergehend ausgeschalteter Systeme. Dokumentieren Sie den PDC-Emulator, die Funktionsebene, die Betriebssystemkompatibilität und den Speicherort von SYSVOL. Prüfen Sie die Voraussetzungen anhand des aktuellen Migrationsleitfadens und der tatsächlich installierten Versionen.

Vor Beginn verlangt Microsofts Verfahren für den Zustand Prepared Prüfungen des Replikationszustands, genügend Speicherplatz für die SYSVOL-Kopie, den laufenden DFS Replication-Dienst mit automatischem Start sowie Systemstatussicherungen. Es empfiehlt außerdem, GPOs und Anmeldeskripts nicht zu ändern, bis alle Controller Redirected erreicht haben.

Dokumentieren Sie die Speicherorte der Sicherungen und die Zuständigkeit für die Wiederherstellung. Vereinbaren Sie, wie eine fehlgeschlagene Prüfung die Änderung unterbricht, wer sie untersucht und welche Nachweise die Fortsetzung erlauben. Die Existenz eines Sicherungsjobs zählt nicht als erfolgreicher Wiederherstellungstest.

Das Verfahren enthält diese getrennten Abfragebeispiele:

net share

repadmin /ReplSum

Führen Sie net share auf jedem DC aus und prüfen Sie die Zuordnungen von SYSVOL und NETLOGON. Prüfen Sie AD-Replikation und SYSVOL-Replikation unabhängig voneinander. Beheben Sie bestehende Fehler vor dem Migrationsbeginn; ein Zustandswechsel darf nicht zum Reparaturversuch für ein ungeklärtes Replikationsproblem werden.

Schritt 2 — Freigabe von Prepared

Beispiel für eine Zustandsänderung: nur nach den anfänglichen Prüfungen und der Änderungsfreigabe verwenden. Auf dem PDC-Emulator:

dfsrmig /setglobalstate 1

Erfassen Sie neue Berichte zum globalen Zustand und zum Migrationszustand. Fahren Sie erst fort, wenn jeder Controller Prepared erreicht hat. Verifizieren Sie die DFSR-Kopie und ihre Replikation gemäß dem Prepared-Verfahren.

Führen Sie für jeden Controller einen ausdrücklichen Abnahmevermerk. Dokumentieren Sie verbleibende Ausnahmen mit der zuständigen Person, nicht als informelle Randnotiz außerhalb des Änderungsprotokolls. Wenn während der Migration ein neuer RODC hinzukommt, konsultieren Sie vor dem Fortfahren die dokumentierte RODC-Behandlung; ergänzen Sie einen Routineablauf nicht um allgemeine Befehle zur Objekterstellung oder -löschung.

Schritt 3 — Freigabe von Redirected

Beispiel für eine Zustandsänderung: nur nach Konvergenz und Zustandsvalidierung von Prepared verwenden. Auf dem PDC-Emulator:

dfsrmig /setglobalstate 2

Das Verfahren für den Zustand Redirected verlangt vor Eliminated konsistente lokale Zustände. Validieren Sie die SYSVOL- und NETLOGON-Zuordnungen auf jedem DC sowie den DFSR-Zustand; bewahren Sie Nachweise zum FRS-Zustand auf, solange eine Rückkehr relevant bleibt.

Ergänzen Sie eine betriebliche Abnahmeprüfung: Repräsentative Clients an den betroffenen Standorten müssen die erwarteten Richtlinien und Skripts erhalten. Dokumentieren Sie die ausgewählten Clients, Richtlinien, Erfassungszeitpunkte und Ergebnisse. Dies ist eine vorgeschlagene Validierungsaufgabe und keine Behauptung, dass die Clientverarbeitung für diesen Artikel getestet wurde.

Schritt 4 — Eliminated separat freigeben

Das Verfahren für den Zustand Eliminated verlangt die erfolgreiche Verifikation von Redirected und konsistente Zustände auf allen Controllern. Prüfen Sie die AD-Replikation, bewahren Sie Sicherungen an stabilen Zuständen auf und bestätigen Sie, dass der Domänenverantwortliche den Verlust der Rückkehrmöglichkeit im Migrationsverfahren akzeptiert.

Beispiel für eine irreversible Zustandsänderung: keine sofortige Empfehlung für eine unbekannte Domäne. Auf dem PDC-Emulator, erst nach Freigabe dieser Stufe:

dfsrmig /setglobalstate 3

Erfassen Sie neue Berichte zum globalen und zu den lokalen Zuständen. Verifizieren Sie erneut die Zuordnungen der SYSVOL- und NETLOGON-Freigaben, die DFSR-Replikation und die Richtlinienverarbeitung. Prüfen Sie vor der Außerbetriebnahme jede verbleibende Nutzung des FRS-Dienstes: Microsoft macht das Beenden und Deaktivieren von FRS davon abhängig, ob der Dienst andere Aufgaben als SYSVOL erfüllt.

Dokumentieren Sie die abschließende Entscheidung und die Nachweise einschließlich ungeklärter Auffälligkeiten. Ersetzen Sie die Verifikation zur Laufzeit nicht durch die Bereinigung eines LDAP-Objekts.

Wie EtcSec dies erkennt

EtcSecs Prüfung DFSR_NOT_CONFIGURED ist in ad/network/dfsr.go von etc-collector implementiert. Ihre Methode Detect() wertet die erfassten Domäneninformationen aus:

Der Code ordnet Ebene 3 Windows Server 2008 zu. Count ist ein Signal auf Domänenebene und nicht die Anzahl betroffener DCs. Der Provider setzt das FRS-Flag nur, wenn seine begrenzte LDAP-Suche erfolgreich ist und ein Objekt zurückliefert. Ein Fehler oder ein leeres Ergebnis lässt das Flag auf false, ohne separaten Indikator für Erfassungsfehler in diesem Signal. In der untersuchten Revision führt der oben beschriebene fehlerhafte Filter in diesen Fehlerpfad: Dieser Erfassungspfad lässt UsingNTFRSForSYSVOL auf false, sodass Detect() Count 0 zurückgibt, selbst wenn die Domäne tatsächlich FRS verwendet.

Ein verbliebenes Abonnementobjekt kann nach der Migration bestehen bleiben. Deshalb ist ein positives Ergebnis Anlass, LDAP mit dfsrmig, Dienstbeobachtungen und Freigabenachweisen abzugleichen. Es beweist weder den tatsächlich verwendeten Replikationsdienst noch einen Angriff.

Der Detektor liest weder globale noch lokale dfsrmig-Zustände, den DFSR-Zustand, die Replikationskonvergenz oder Ergebnisse der Clientrichtlinienverarbeitung. Count 0 beweist weder eine fehlerfreie DFSR-Replikation noch eine abgeschlossene Migration. Sein Empfehlungstext ist ein Ratschlag; er bedeutet nicht, dass ein Prüfbefehl oder eine Migration ausgeführt wurde.

Die Änderung mit bereinigten Inhalten abschließen

Die SYSVOL-Replikation über DFSR entfernt keine Geheimnisse aus dessen Dateien. Führen Sie die Prüfung von cPassword-Geheimnissen in GPO-SYSVOL als separate Inhaltsaufgabe weiter, mit eigenständiger Zuständigkeit für den Umgang mit Zugangsdaten und die Bereinigung außerhalb der Replikationsänderung.

Bewahren Sie ein abschließendes Nachweispaket auf: Inventar, Sicherungen, Ausgangszustand, Konvergenz- und Zustandsprüfungen jeder Freigabestufe, gegebenenfalls die Eliminated-Entscheidung sowie die abschließende Freigabe- und Richtlinienverifikation. Gleichen Sie das Collector-Ergebnis mit diesem Paket ab und dokumentieren Sie veraltete LDAP-Nachweise oder Erfassungseinschränkungen.

Die Abschlussentscheidung muss für jemanden prüfbar sein, der die Befehle nicht ausgeführt hat. Bleibt ein Controller, eine Dienstbeobachtung oder eine Richtlinienprüfung ungeklärt, benennen Sie diese Einschränkung ausdrücklich und lassen Sie die entsprechende betriebliche Maßnahme offen.