SYSVOL FRS-to-DFSR Migration Operations: State Gates, Replication, and Safe Completion

SYSVOL carries Group Policy files and domain logon scripts to domain controllers. Older Active Directory domains may still replicate SYSVOL with the File Replication Service (FRS); supported modern designs use Distributed File System Replication (DFSR). The migration is an Active Directory-wide state transition, not a per-controller file-copy operation. It depends on healthy AD replication, SYSVOL contents, DFSR service operation, and every domain controller reaching each migration state. Microsoft’s documented migration is one-way: after the Eliminated state, the domain cannot revert to FRS.

Treat this as a change-control runbook for a domain whose directory and SYSVOL are healthy enough to migrate. Do not use it to repair a broken SYSVOL by forcing state changes. Establish system-state and GPO backups, document the domain controllers and sites, verify replication, assess any offline DC, and schedule enough time for AD and DFSR convergence. A domain controller that is unreachable or stale can hold up progress or leave operators with conflicting views of the migration state.

Confirm prerequisites and baseline health

Inventory every domain controller, operating system version, site, writable/read-only status, SYSVOL share, NETLOGON share, FRS/DFSR service state, and current global migration state. Confirm the domain functional level and other prerequisites against Microsoft’s current migration guide for the exact server versions. Windows Server 2019 and later domain controllers cannot be promoted into a domain that still uses FRS for SYSVOL, so complete the domain migration before that promotion path is required. Keep the scope domain-specific; another domain in the same forest has its own SYSVOL state.

Run read-only checks on the PDC Emulator and representative DCs. Record domain role owner, AD replication summary, SYSVOL/NETLOGON share presence, and the migration state. The following commands help establish a baseline; run them from an elevated administrative session with appropriate tools installed.

Import-Module ActiveDirectory -ErrorAction Stop

Get-ADDomain | Select-Object DNSRoot, PDCEmulator, DomainMode
repadmin.exe /replsummary
dfsrmig.exe /getglobalstate
dfsrmig.exe /getmigrationstate
dcdiag.exe /test:sysvolcheck /test:advertising
net.exe share | Select-String 'SYSVOL|NETLOGON'

These commands report several independent health signals; no single one proves SYSVOL content is identical across the domain. Check DFS Replication event logs, backlog where relevant, GPO reports, and file-level comparison using a supported method. Ensure SYSVOL and NETLOGON are served by the correct replicated paths, and confirm clients can locate healthy DCs in each site. Do not start a migration during unresolved AD replication failures, active FRS/DFSR errors, or a domain-controller recovery.

Understand the migration state machine

The global migration proceeds through Start, Prepared, Redirected, and Eliminated. Start means the domain is still using the existing FRS SYSVOL replication arrangement. Prepared creates and populates the DFSR-replicated SYSVOL replica set while FRS remains the active serving path. Redirected makes DFSR the serving path while retaining the prior FRS data for the supported transition period. Eliminated removes the ability to return to FRS and is the irreversible final state.

For an operational decision, distinguish the requested global state from the state reported by every domain controller. /getglobalstate shows the requested migration state; /getmigrationstate reports whether DCs have reached it. A command can change the desired state while individual DCs are still processing. Do not advance based on the global number alone. Require each controller to reach the current stage, investigate slow or unreachable DCs, and obtain the appropriate approval before moving forward.

Advance to Prepared only after a clean baseline

In a change window, use the documented dfsrmig procedure to request the Prepared state. The command is a forest/domain control-plane write and should be run by an authorized administrator against the correct domain. Record the exact command, operator, timestamp, domain, and PDC Emulator. Then allow Active Directory replication and DFSR polling to converge. Use the migration-state query repeatedly at a cadence consistent with the environment; large or geographically distributed domains may need significantly more time than a lab.

At Prepared, validate that DFSR has initialized and replicated the expected SYSVOL content on all DCs while the active path remains the supported FRS path. Compare the GPO folder and script inventory, investigate DFSR event errors and backlog, and confirm no DC is stuck in a prior state. Do not move to Redirected if one controller is offline, missing content, unable to replicate, or inconsistently reporting state. Restoring a forgotten DC after the domain has moved ahead can require a carefully supported recovery rather than another migration command.

Redirect with a controlled client validation

Only after every DC reaches Prepared and the prepared replica has been validated should the change owner request Redirected using the Microsoft procedure. Then query each controller’s migration state and verify that SYSVOL and NETLOGON are served from the DFSR paths. Test policy retrieval from representative client sites, not only from the PDC Emulator. Run gpresult on an approved test client, verify expected scripts and policy files are accessible, and confirm that Group Policy processing remains healthy.

Inspect both replication health and client behavior during the observation period. A client can continue to use a cached policy or another DC, so a single successful logon is not sufficient. Use site-aware tests and check DC locator behavior. Keep changes to GPOs and logon scripts controlled while the transition is under observation; if the organization must change them, ensure the change owner can distinguish migration effects from policy content changes.

Treat Eliminated as a deliberate irreversible gate

Before requesting Eliminated, require written approval that the domain has operated successfully on DFSR, every DC is healthy and converged, SYSVOL and NETLOGON content is validated, clients in all sites process Group Policy, and recovery backups are current. Reconfirm there are no retired-but-reachable DCs, forgotten branch-office servers, or long-offline controllers that might return with stale state. The post-Eliminated decision is not an ordinary maintenance rollback; FRS is no longer a supported fallback.

After the final transition, verify the global state and every DC’s migration state. Confirm DFSR service and SYSVOL shares, test logon scripts and policy retrieval from multiple sites, and preserve the logs and command outputs. Update the domain recovery plan and server promotion runbook so that future domain controllers follow the DFSR-only requirement. Remove obsolete FRS operational assumptions only after the supported procedure and validation are complete.

Diagnose a stalled transition without forcing it

If a DC remains behind, compare its AD replication health, DNS, site links, DFSR service state, SYSVOL contents, and DFSR event logs with a healthy peer. Verify it can contact the PDC Emulator and other replication partners. dfsrdiag pollad requests the DFSR service to poll AD configuration; it does not repair bad replication or make an unsafe state transition valid. Use it only where the Microsoft troubleshooting guide calls for it, then re-check the actual migration state.

Do not manually share SYSVOL or NETLOGON, set a SYSVOL-ready registry value, delete DFSR databases, or edit migration attributes to make a console appear green. Microsoft explicitly warns against workarounds such as manually sharing SYSVOL or setting SYSVOLREADY=1; these can cause a DC to contact itself for Group Policy while its SYSVOL has not been populated. Such shortcuts can disguise the root issue and make policy recovery harder.

If an authoritative restore or DC recovery overlaps the migration, stop and follow the supported recovery procedure for that server version and migration state. Preserve system-state backups and the AD/DFSR event evidence. Consult current Microsoft guidance and the directory recovery owner before removing or reintroducing a domain controller. A reanimated DC with stale SYSVOL data is not a safe way to restore a missing replica.

Completion evidence and change record

The change record should include the initial baseline, approved global-state transitions, timestamped state query from every DC, AD replication evidence, DFSR health evidence, share and content checks, client tests by site, rollback/recovery constraints, and owner sign-off before the irreversible stage. Record every unavailable DC and its disposition. A clean dfsrmig result does not replace a business-level validation of policy and logon scripts.

The operational goal is not merely to see DFSR in a service list. It is to prove that the directory’s SYSVOL configuration has converged, every supported DC serves expected content, clients consume policy reliably, and the organization understands that Eliminated has no FRS rollback. Keep the migration state in routine AD health reviews so future maintenance does not unexpectedly rediscover this prerequisite.

Related:

Sources: