Migrazione SYSVOL da FRS a DFSR: verificare ogni DC prima di Eliminated

Che cos’è la migrazione SYSVOL da FRS a DFSR?

Una migrazione SYSVOL da FRS a DFSR cambia il modo in cui i controller di dominio replicano i file usati per i criteri di gruppo e gli script di accesso. L’attività richiede una procedura per l’intero dominio: stabilire lo stato attuale, convalidare la replica su ogni controller di dominio e avanzare solo quando le prove giustificano la fase successiva.

Revisione tecnica: 4 ottobre 2026. I comandi seguenti sono esempi basati sulla documentazione; non sono stati eseguiti su un dominio di produzione.

File Replication Service (FRS) è deprecato, come documentato nelle indicazioni Microsoft sulla deprecazione di FRS. DFS Replication (DFSR) è diventato disponibile per SYSVOL al livello funzionale di dominio Windows Server 2008. La guida attuale alla migrazione di SYSVOL rimane il punto di partenza per il processo supportato.

Considerate questa attività un progetto di configurazione e disponibilità. Un segnale di replica legacy non dimostra un attacco, un controller compromesso o una GPO non funzionante. Allo stesso modo, l’assenza di rilievi non può autorizzare una modifica irreversibile. Stabilite quali prove servono al responsabile del dominio prima di pianificare il lavoro.

Questo progetto deve affiancare la pianificazione dell’aggiornamento dei controller di dominio Windows Server 2016, che tratta sistemi operativi e livelli funzionali. Conservate prove separate per la migrazione SYSVOL: sostituire un DC o esaminare il suo sistema operativo non costituisce un registro dello stato di migrazione di tutti i controller.

Come funziona: direzione globale e convergenza locale

L’emulatore PDC mantiene la direzione di migrazione impostata tramite dfsrmig /setglobalstate. Ogni controller di dominio deve raggiungere il proprio stato locale corrispondente. Un comando che cambia la direzione globale è quindi l’inizio di una fase, non la prova che tutti i controller l’abbiano completata.

Il riferimento Microsoft sugli stati di migrazione SYSVOL descrive queste fasi stabili:

Gli stati locali possono essere transitori mentre il lavoro procede. Mantenete visibili nel registro di migrazione i controller offline, irraggiungibili o ancora in transizione. Non rimuoveteli dall’elenco di accettazione per far sembrare completa la modifica.

Rilevamento: creare un registro degli stati prima di cambiare qualcosa

Leggere lo stato globale sull’emulatore PDC

Eseguite questo comando di consultazione sull’emulatore PDC, come richiesto dal riferimento del comando dfsrmig:

dfsrmig /getglobalstate

Raccogliete poi il rapporto di convergenza dell’intero dominio:

dfsrmig /getmigrationstate

Il primo legge lo stato globale del dominio. Il secondo confronta gli stati locali con quella direzione e segnala i controller che non l’hanno raggiunta. Il riferimento del comando avverte che leggere lo stato globale su un altro controller può produrre informazioni incoerenti a causa della latenza della replica AD.

Interpretazione illustrativa, non output osservato: uno stato globale Prepared con un controller ancora in Start o in uno stato di transizione significa che il controllo di accettazione Prepared resta aperto. Uno stato globale Redirected con tutti gli stati locali corrispondenti soddisfa il controllo dello stato, ma richiede ancora la convalida delle condivisioni e della replica. Uno stato globale Eliminated senza un rapporto di convergenza utilizzabile costituisce una prova incompleta, non un completamento verificato.

Per ogni acquisizione, registrate il dominio, l’identità del PDC, l’inventario dei controller, l’ora di raccolta, il comando e l’output completo. Un controller irraggiungibile richiede un responsabile e un piano di risoluzione. Conservate le acquisizioni precedenti affinché i revisori possano distinguere i progressi da una modifica dell’inventario.

Esaminare le prove della sottoscrizione LDAP e dei servizi

Il provider di etc-collector esaminato tenta una ricerca LDAP nel sottoalbero del DN di base configurato con il filtro seguente, richiedendo cn e conservando al massimo un risultato lato client:

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

Questo è il filtro letterale del provider, presentato come prova del codice e non come comando di un client LDAP pronto all’uso. Nella revisione del collector esaminata (42bfefb), le parentesi nel valore del nome non sono sottoposte a escape. Una verifica locale del solo parser con la dipendenza dichiarata go-ldap v3.4.12 ha restituito Filter Compile Error; la richiesta di ricerca non può essere codificata con questo filtro. Per questa revisione non è stata eseguita alcuna query LDAP di produzione.

Questo difetto di raccolta lascia il flag FRS a false nel provider esaminato. Anche dopo che una query corretta restituisse con successo un oggetto di sottoscrizione, quell’oggetto da solo non identificherebbe tutti i controller, non stabilirebbe quale servizio serve attualmente SYSVOL e non escluderebbe un residuo della migrazione.

Su ogni DC, registrate inoltre in Services lo stato e la configurazione di avvio del servizio File Replication (NTFRS) e del servizio DFS Replication (DFSR). Correlate queste osservazioni con lo stato di migrazione e il percorso effettivo delle condivisioni. Un servizio in esecuzione da solo non dimostra che la replica SYSVOL sia corretta.

Usate una piccola matrice delle prove anziché un’unica spunta verde:

Distinguete gli errori di raccolta dai risultati negativi nel registro operativo. Questo articolo non fornisce query di attacco né ID evento Windows; la decisione si basa sulle prove di migrazione e replica.

Correzione: avanzare attraverso controlli documentati (Remediation)

Passaggio 1 — Inventario, prerequisiti e preparazione al ripristino

Designate il responsabile del dominio e l’operatore della modifica. Inventariate tutti i DC scrivibili e i RODC, inclusi i siti remoti e i sistemi temporaneamente offline. Registrate l’emulatore PDC, il livello funzionale, la compatibilità dei sistemi operativi e la posizione di SYSVOL. Confermate i prerequisiti in base alla guida attuale alla migrazione e alle versioni effettivamente installate.

Prima di iniziare, la procedura Microsoft per lo stato Prepared richiede verifiche dell’integrità della replica, spazio sufficiente per la copia SYSVOL, il servizio DFS Replication in esecuzione con avvio automatico e backup dello stato del sistema. Raccomanda inoltre di evitare modifiche alle GPO e agli script di accesso finché tutti i controller non raggiungono Redirected.

Documentate le posizioni dei backup e le responsabilità di ripristino. Concordate come un controllo non riuscito sospende la modifica, chi ne esegue la diagnosi e quali prove consentono di riprendere il lavoro. Non considerate l’esistenza di un processo di backup come una prova di ripristino riuscita.

La procedura include questi esempi separati di consultazione:

net share

repadmin /ReplSum

Eseguite net share su ogni DC ed esaminate i percorsi SYSVOL e NETLOGON. Esaminate la replica AD e la replica SYSVOL separatamente. Risolvete gli errori esistenti prima di iniziare la migrazione; una transizione di stato non deve diventare un tentativo di riparare un problema di replica non spiegato.

Passaggio 2 — Controllo di accettazione Prepared

Esempio che modifica lo stato: usare solo dopo le verifiche iniziali e l’approvazione della modifica. Sull’emulatore PDC:

dfsrmig /setglobalstate 1

Raccogliete nuovi rapporti sullo stato globale e sullo stato di migrazione. Non proseguite finché ogni controller non ha raggiunto Prepared. Verificate la copia DFSR e la sua replica come descritto nella procedura Prepared.

Mantenete una voce di accettazione esplicita per ogni controller. Registrate le eccezioni rimaste con il relativo responsabile, non come un’osservazione informale fuori dal registro della modifica. Se viene introdotto un nuovo RODC durante la migrazione, consultate la gestione documentata dei RODC prima di continuare; non aggiungete comandi generici di creazione o eliminazione di oggetti a una procedura ordinaria.

Passaggio 3 — Controllo di accettazione Redirected

Esempio che modifica lo stato: usare solo dopo la convergenza Prepared e la convalida dell’integrità. Sull’emulatore PDC:

dfsrmig /setglobalstate 2

La procedura per lo stato Redirected richiede stati locali coerenti prima di Eliminated. Convalidate i percorsi SYSVOL e NETLOGON su ogni DC e l’integrità di DFSR; conservate le prove dell’integrità di FRS finché il rollback rimane pertinente.

Aggiungete un controllo di accettazione operativa: i client rappresentativi nei siti interessati devono ottenere i criteri e gli script previsti. Registrate i client e i criteri scelti, gli orari di raccolta e i risultati. Si tratta di un’attività di convalida proposta, non dell’affermazione che l’elaborazione lato client sia stata verificata per questo articolo.

Passaggio 4 — Approvare Eliminated separatamente

La procedura per lo stato Eliminated richiede una verifica Redirected riuscita e stati coerenti su tutti i controller. Esaminate la replica AD, conservate i backup negli stati stabili e confermate che il responsabile del dominio accetti la perdita del rollback della migrazione.

Esempio irreversibile che modifica lo stato: non è una raccomandazione immediata per un dominio sconosciuto. Sull’emulatore PDC, solo dopo l’approvazione di quel controllo:

dfsrmig /setglobalstate 3

Raccogliete nuovi rapporti sullo stato globale e sugli stati locali. Verificate nuovamente i percorsi delle condivisioni SYSVOL e NETLOGON, la replica DFSR e l’elaborazione dei criteri. Esaminate gli eventuali usi rimanenti del servizio FRS prima della dismissione: la procedura Microsoft condiziona l’arresto e la disabilitazione di FRS al fatto che serva o meno per scopi diversi da SYSVOL.

Registrate la decisione finale e le prove, incluse le anomalie irrisolte. Non usate la pulizia di un oggetto LDAP come sostituto della verifica a runtime.

Come EtcSec rileva questa configurazione

Il controllo DFSR_NOT_CONFIGURED di EtcSec è implementato in ad/network/dfsr.go di etc-collector. Il suo metodo Detect() valuta le informazioni di dominio raccolte:

Il codice associa il livello 3 a Windows Server 2008. Count è un segnale a livello di dominio, non il numero di DC interessati. Il provider imposta il flag FRS solo quando la sua ricerca LDAP limitata riesce e restituisce un oggetto. Un errore o un risultato vuoto lascia il flag a false senza un indicatore separato di errore di raccolta in questo segnale. Nella revisione esaminata, il filtro malformato descritto sopra segue quel percorso di errore: questo percorso di raccolta lascia UsingNTFRSForSYSVOL a false, quindi Detect() restituisce Count 0 anche se il dominio usa effettivamente FRS.

Un oggetto di sottoscrizione residuo può rimanere dopo la migrazione. Un risultato positivo è quindi un motivo per confrontare LDAP con dfsrmig, le osservazioni dei servizi e le prove sulle condivisioni. Non dimostra né il servizio di replica effettivo né un attacco.

Il rilevatore non legge gli stati globali o locali di dfsrmig, l’integrità di DFSR, la convergenza della replica o i risultati dei criteri lato client. Count 0 non dimostra né che DFSR funzioni correttamente né che la migrazione sia completa. Il testo della raccomandazione è un’indicazione; non significa che siano stati eseguiti un comando di verifica dell’integrità o una migrazione.

Chiudere la modifica con l’igiene del contenuto

Replicare SYSVOL tramite DFSR non rimuove i segreti dai suoi file. Mantenete la revisione dei segreti cPassword delle GPO in SYSVOL come attività separata sul contenuto, con la gestione delle credenziali e la pulizia sotto responsabilità indipendenti dalla modifica della replica.

Conservate un pacchetto finale di prove contenente l’inventario, i backup, lo stato iniziale, i controlli di convergenza e integrità di ogni fase, la decisione Eliminated se adottata e la verifica finale delle condivisioni e dei criteri. Confrontate il risultato del collector con quel pacchetto e documentate eventuali prove LDAP obsolete o limitazioni della raccolta.

La decisione di completamento deve poter essere esaminata da qualcuno che non ha eseguito i comandi. Se rimangono irrisolti un controller, un’osservazione di servizio o un controllo dei criteri, dichiarate esplicitamente tale limitazione e mantenete aperta la corrispondente azione operativa.