FRS and SYSVOL migration

FRS is a historical dependency

FRS remains relevant when diagnosing an inherited legacy domain. It is not a choice for a new SYSVOL design. Starting with Windows Server 2019, new DC promotion requires the domain to use DFSR for SYSVOL. An in-place OS upgrade is not a migration strategy; Microsoft documents a specific upgrade/migration failure involving old FRS domains.

Read global and local migration state

Use an elevated command prompt on the domain’s PDC emulator for the global-state check:

dfsrmig /getglobalstate
dfsrmig /getmigrationstate

Global state is the requested migration state. Migration state tells you whether the DCs have reached it. Requesting a state doesn’t mean the migration has completed.

The domain functional level prerequisite is Windows Server 2008 or later. This is a domain-level prerequisite, independent of whether a particular forest-wide feature has been enabled. Use the current migration guide and Dfsrmig reference for the full procedure. The global-state command reads the local AD copy, which is why its documented location matters.

Migration waits on several systems

Migration state is stored in AD, so the configuration has to replicate. Each DC must then read it and finish its local work. The files have to converge too. Repeating a state command won’t skip any of that work.

Before advancing, check every participating DC, AD replication, SYSVOL/NETLOGON access, file consistency, free space, and the expected local state. Keep track of unavailable DCs; they still count even when the rest are ready.

Migration changes the domain. The /setglobalstate operations belong in a planned procedure with backup and phase-specific rollback decisions. Do not paste all three state changes into one script and hope the services catch up between them.

Journal wrap belongs to the FRS troubleshooting vocabulary

FRS follows the NTFS change journal. If the journal rolls past changes before FRS reads them, it can no longer assume its local tracking reflects the volume. Heavy activity anywhere on that volume can contribute; the replicated folder itself may be quiet.

Other old FRS terms worth recognizing are staging, version-vector joins, and morphed directories. These describe FRS’s replication and recovery mechanisms. Their old sizing rules and registry remedies are version-specific and should not be applied to DFSR.

D2 and D4 are not DFSR recovery switches

The old FRS BurFlags procedures distinguish non-authoritative and authoritative initialization. Choosing an authoritative copy asserts which data should survive. Doing that with an empty or stale copy can distribute the wrong result.

DFSR SYSVOL recovery uses a different procedure and different configuration. Reusing FRS registry advice on DFSR does not perform the equivalent recovery. See Microsoft’s DFSR authoritative/non-authoritative synchronization procedure.

Keep the recovery objective explicit

Work out whether you’re recovering missing shares, repairing a replica, completing a migration phase, or replacing an old DC. Those need different procedures. Find a known-good source and save the content before choosing one.

Establish the baseline before Prepared

Inventory every DC, including disconnected branch DCs and RODCs. Verify the domain functional level, healthy directory replication, FRS SYSVOL consistency, SYSVOL/NETLOGON publication, available space for the second copy, and usable recovery data. Save each share’s actual path; migration changes which tree supplies the production share.

Get-ADDomain -Identity 'contoso.com' |
    Select-Object DNSRoot, DomainMode, PDCEmulator

Starts a domain-wide migration phase: after those prerequisites, run on the PDC emulator:

dfsrmig /setglobalstate 1

Then wait for /getmigrationstate to show all DCs at Prepared. In that state, FRS still supplies production SYSVOL while DFSR maintains its prepared copy. Inspect replication, events, and both copies before proceeding. The Prepared-state procedure describes the baseline and verification.

Redirect only after every member is prepared

Changes the tree supplying production SYSVOL:

dfsrmig /setglobalstate 2

Wait for every DC to reach Redirected, then inspect its SYSVOL share path and test policy/script access. DFSR now supplies the production data; the original FRS tree remains during this phase. A script that writes directly to an old local SYSVOL path can now modify the wrong copy, so inspect operational scripts and backup selections too. See the Redirected-state procedure.

Eliminate after the operating checks

At Redirected, validate representative clients and every DC before making the irreversible phase transition. A healthy first site says nothing about a branch DC still in a transition state.

Removes the FRS SYSVOL configuration and rollback route:

dfsrmig /setglobalstate 3

Check that all DCs reach Eliminated, then verify the DFSR production paths and recovery plan. The Eliminated-state procedure lists the completion checks. The command requests the phase; it doesn’t confirm removal has finished everywhere.

Diagnose a member that does not advance

Save the reported local state and DFSR events. Did it receive the AD change, read it, create the folders, and complete initial file synchronization? Check available space and upstream health before changing state again. Preparing, waiting for initial sync, redirecting, and eliminating each point to a different stage of the work.

Before Eliminated, a planned rollback can request a previous stable state, then wait for every DC to complete the rollback. After Eliminated, /setglobalstate 0 does not recreate a supported FRS domain. Microsoft’s migration state model explains those boundaries.

A transition number belongs to a particular state field

Global migration state can be only a stable target. A member’s local progress additionally includes Preparing, Waiting for initial synchronization, Redirecting, Eliminating, Undo redirecting, and Undo preparing. Do not decode a raw msDFSR-Flags value as if it were the registry’s Local State integer: these are different representations. Prefer the tool’s named state and events. The Dfsrmig command description distinguishes requested and local states.

For a stuck member, preserve read-only evidence locally:

reg query "HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating SysVols" /v "Local State"

A domain created using DFSR may not have this key. Check the domain migration state, the DC’s promotion/migration history and its events before treating that as corruption. Don’t manually set a state number to make the report look complete; that skips the work behind the transition.

Rollback also has a data direction. At Redirected, DFSR supplies the active copy; the old FRS tree can be stale. During rollback to Prepared, DFSR copies the DFSR tree’s contents back into the FRS tree on the PDC emulator, and FRS must then replicate them. Simply repointing a share or restarting FRS can expose the old tree. Retain both copies and the actual share paths until rollback verification completes. For journal wrap, joins and folder-name conflicts before migration, use legacy FRS diagnostics.