SYSVOL FRS to DFSR Migration: Confirm Every DC Before Eliminated

What Is SYSVOL FRS to DFSR Migration?

A sysvol frs to dfsr migration changes how domain controllers replicate the files used for Group Policy and sign-in scripts. The task needs a domain-wide runbook: establish the current state, validate replication on every domain controller, and advance only when the evidence supports the next stage.

Technical review: October 4, 2026. Commands below are documentation-based examples; they were not executed against a production domain.

File Replication Service (FRS) is deprecated, as documented in Microsoft's FRS deprecation guidance. DFS Replication (DFSR) became available for SYSVOL at the Windows Server 2008 domain functional level. The current SYSVOL migration guide remains the starting point for the supported process.

Treat this as a configuration and availability project. A legacy replication signal does not establish an attack, a compromised controller, or a broken GPO. Equally, an absence of findings cannot approve an irreversible change. Decide which evidence the domain owner needs before scheduling the work.

This project belongs alongside your Windows Server 2016 domain controller upgrade planning, which covers operating systems and functional levels. Keep separate evidence for the SYSVOL migration: replacing a DC or reviewing its OS is not a record of every controller's migration state.

How It Works: Global Direction and Local Convergence

The PDC emulator holds the migration direction set through dfsrmig /setglobalstate. Each domain controller must reach its own corresponding local state. A command changing the global direction is therefore the beginning of a phase, not proof that every controller has completed it.

Microsoft's SYSVOL migration states reference describes these stable stages:

Local states may be transitional while work proceeds. Keep controllers that are offline, unreachable, or still transitioning visible in the migration record. Do not remove them from the acceptance list just to make the change look complete.

Detection: Build a State Record Before Changing Anything

Read the global state on the PDC emulator

Run this consultation command on the PDC emulator, as required by the dfsrmig command reference:

dfsrmig /getglobalstate

Then collect the domain-wide convergence report:

dfsrmig /getmigrationstate

The first reads the domain's global state. The second checks local states against that direction and reports controllers that have not reached it. The command reference warns that reading global state on another controller can produce inconsistent information because of AD replication latency.

Illustrative interpretation, not observed output: global Prepared with a controller still at Start or a transition state means the Prepared gate remains open. Global Redirected with all local states matching satisfies the state check, but still requires share and replication validation. Global Eliminated without a usable convergence report is incomplete evidence, not a verified completion.

For each capture, record the domain, PDC identity, controller inventory, collection time, command and full output. An unreachable controller needs an owner and a resolution plan. Preserve earlier captures so reviewers can distinguish progress from a changed inventory.

Review the LDAP subscription and service evidence

The inspected etc-collector provider attempts a subtree LDAP search beneath its configured base DN with the following filter, requesting cn and retaining at most one result client-side:

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

This is the provider's literal filter, presented as code evidence rather than a ready-to-run LDAP client command. In the inspected collector revision (42bfefb), the parentheses in the name value are not escaped. A local parser-only check with the declared go-ldap v3.4.12 dependency returned Filter Compile Error; the search request cannot be encoded with this filter. No production LDAP query was executed for this review.

This collection defect leaves the FRS flag false in the inspected provider. Even after a corrected query successfully returns a subscription object, that object alone would not identify all controllers, establish which service currently serves SYSVOL, or rule out a migration remnant.

On each DC, also record the File Replication service (NTFRS) and DFS Replication service (DFSR) status and startup configuration in Services. Correlate those observations with the migration state and actual share mapping. A running service alone cannot establish successful SYSVOL replication.

Use a small evidence matrix instead of a single green check:

Keep collection failures distinct from negative results in your operational record. This article supplies no attack query or Windows Event ID; the decision here is based on migration and replication evidence.

Remediation: Advance Through Documented Gates

Step 1 — Inventory, prerequisites and recovery readiness

Name the domain owner and the change operator. Inventory every writable DC and RODC, including remote sites and temporarily offline systems. Record the PDC emulator, functional level, OS compatibility and the location of SYSVOL. Confirm prerequisites against the current migration guide and the versions actually installed.

Before starting, Microsoft's Prepared-state procedure calls for replication health checks, sufficient space for the SYSVOL copy, the DFS Replication service running with automatic startup, and system-state backups. It also recommends avoiding GPO and sign-in-script changes until all controllers reach Redirected.

Document the backup locations and recovery ownership. Agree how a failed check pauses the change, who diagnoses it, and what evidence allows work to resume. Do not count the existence of a backup job as a successful recovery test.

The procedure includes these separate consultation examples:

net share

repadmin /ReplSum

Run net share on each DC and inspect SYSVOL and NETLOGON mappings. Review AD replication and SYSVOL replication independently. Resolve existing failures before starting migration; a state transition should not become an attempted repair for an unexplained replication problem.

Step 2 — Prepared gate

State-changing example: use only after the initial checks and change approval. On the PDC emulator:

dfsrmig /setglobalstate 1

Collect fresh global and migration-state reports. Do not proceed until every controller has reached Prepared. Verify the DFSR copy and its replication as described in the Prepared procedure.

Keep an explicit acceptance entry per controller. Record remaining exceptions with the responsible person, not as an informal note outside the change record. If a new RODC is introduced during migration, consult the documented RODC handling before continuing; do not add generic object-creation or deletion commands to a routine runbook.

Step 3 — Redirected gate

State-changing example: use only after Prepared convergence and health validation. On the PDC emulator:

dfsrmig /setglobalstate 2

The Redirected-state procedure requires consistent local states before Eliminated. Validate the SYSVOL and NETLOGON mappings on every DC and DFSR health; retain FRS health evidence while rollback remains relevant.

Add an operational acceptance check: representative clients in the affected sites must obtain the expected policies and scripts. Record the chosen clients, policies, collection times and results. This is a proposed validation task, not a claim that client processing was tested for this article.

Step 4 — Approve Eliminated separately

The Eliminated-state procedure requires successful Redirected verification and consistent states on all controllers. Review AD replication, preserve backups at stable states, and confirm that the domain owner accepts the loss of migration rollback.

Irreversible state-changing example: not an immediate recommendation for an unknown domain. On the PDC emulator, only after that gate is approved:

dfsrmig /setglobalstate 3

Collect fresh global and local-state reports. Verify SYSVOL and NETLOGON share mappings, DFSR replication and policy processing again. Review any remaining FRS service use before retirement: Microsoft's procedure conditions stopping and disabling FRS on whether it serves purposes other than SYSVOL.

Record the final decision and evidence, including unresolved anomalies. Do not turn an LDAP object cleanup into a substitute for runtime verification.

How EtcSec Detects This

EtcSec's DFSR_NOT_CONFIGURED check is implemented in etc-collector's ad/network/dfsr.go. Its Detect() evaluates the collected domain information:

The code maps level 3 to Windows Server 2008. Count is a domain-level signal, not the number of affected DCs. The provider sets the FRS flag only when its limited LDAP search succeeds and returns an object. An error or empty result leaves the flag false without a separate collection-error indicator in this signal. In the inspected revision, the malformed filter described above takes that error path: this collection path leaves UsingNTFRSForSYSVOL false, so Detect() returns Count 0 even if the domain actually uses FRS.

A residual subscription object can remain after migration. Therefore, a positive result is a reason to reconcile LDAP with dfsrmig, service observations and share evidence. It is not proof of the effective replication service or an attack.

The detector reads neither global nor local dfsrmig states, DFSR health, replication convergence nor client policy results. Count 0 proves neither healthy DFSR nor a completed migration. Its recommendation text is advice; it does not mean a health command or migration was executed.

Close the Change With Content Hygiene

Replicating SYSVOL through DFSR does not remove secrets from its files. Keep the GPO SYSVOL cPassword secrets review as a separate content task, with credential handling and cleanup owned independently of the replication change.

Retain a final evidence package containing the inventory, backups, initial state, each gate's convergence and health checks, the Eliminated decision if taken, and the final share and policy verification. Reconcile the collector result with that package and document any stale LDAP evidence or collection limitation.

The completion decision should be reviewable by someone who did not operate the commands. If a controller, service observation or policy check remains unresolved, state that limitation explicitly and keep the corresponding operational action open.