Troubleshoot SYSVOL and DFSR Replication Across Domain Controllers

A GPO has directory data in Active Directory and files in SYSVOL. AD replication can be healthy while the files remain different on two DCs. This runbook investigates DFS Replication (DFSR) on Windows Server 2019, 2022, and 2025, beginning with topology and state before any recovery action.

Tools and execution context

Use an elevated administrative workstation with the ActiveDirectory and GroupPolicy modules, plus the DFS management tools for dfsrdiag. Run the local CIM and share checks on each affected DC, or through an authorized PowerShell session. Keep DC01, DC02, and contoso.com consistent after replacing them with your environment.

Do not begin with an authoritative SYSVOL restore

Do not delete the DFSR database, manually copy SYSVOL over a healthy DC, or perform an authoritative/non-authoritative synchronization without a recovery plan and a verified source of good policy files. Those actions can propagate the wrong content. Back up GPOs and retain event evidence before changing DFSR membership.

01

Confirm the Domain Uses DFSR and Map Its DCs

Scope

Record the failing GPO or logon script, affected clients, first failure time, and which DC each client used. Check SYSVOL migration state and the directory replication baseline. The migration commands below report state; they do not change it. An Eliminated migration state indicates SYSVOL has completed the move from FRS to DFSR. If migration is incomplete, use the migration troubleshooting procedure instead of treating the environment as a completed DFSR deployment.

Import-Module ActiveDirectory
Get-ADDomainController -Filter * |
  Select-Object HostName, Site, IPv4Address, IsReadOnly
dfsrmig /getglobalstate
dfsrmig /getmigrationstate
repadmin /replsummary
repadmin /showrepl DC01
repadmin /showrepl DC02

❯ What to Verify

Migration state: Eliminated, with all DCs at the consistent state.
DC names, sites, and recent AD replication failures are identified.
A clean AD replication result does not prove SYSVOL files have converged.

02

Check DFSR Folder State and Share Advertisement

Local DC Health

On each affected DC, inspect the DFSR service and replicated-folder state. State 4 means Normal; 2 means Initial Sync, 3 Auto Recovery, and 5 In Error. Absence of a SYSVOL instance needs investigation rather than being interpreted as zero backlog. Check the SYSVOL and NETLOGON shares and run the targeted DC tests; these tests cover advertisement and share readiness, rather than comparing every replicated file.

# Run locally on each DC.
Get-Service DFSR, Netlogon
Get-CimInstance -Namespace root\microsoftdfs `
  -ClassName DfsrReplicatedFolderInfo |
  Where-Object ReplicatedFolderName -eq 'SYSVOL Share' |
  Select-Object ReplicationGroupName, ReplicatedFolderName, State
Get-SmbShare -Name SYSVOL, NETLOGON -ErrorAction Continue
dcdiag /s:DC01 /test:Advertising /test:SysVolCheck /test:NetLogons /v

❯ What to Verify

ReplicationGroupName  ReplicatedFolderName  State
--------------------  --------------------  -----
Domain System Volume  SYSVOL Share          4

Both required shares exist and the targeted tests pass.

03

Read DFSR Events Around the Failure

Timeline

Read the full event message and its volume, partner, and folder identifiers. Event 2213 can describe a dirty-shutdown recovery that requires an explicit resume action; follow the instructions in that event after protecting the data. Event 4012 indicates content-freshness protection. Event 4614 indicates waiting for initial synchronization, while 4604 records successful SYSVOL initialization. Preserve the ordering: a historical warning followed by successful recovery is different from a current stalled state.

$since = (Get-Date).AddHours(-6)
foreach ($dc in 'DC01', 'DC02') {
  Get-WinEvent -ComputerName $dc -FilterHashtable @{
    LogName = 'DFS Replication'
    StartTime = $since
  } -MaxEvents 150 |
    Select-Object MachineName, TimeCreated, Id, LevelDisplayName, Message
}

❯ What to Verify

Record the earliest relevant error, the folder state at that time,
and whether later events confirm recovery or continued waiting.

Initial synchronization needs a healthy upstream source

A new or recovered DC can wait for a partner that has not completed its own initialization. Check the upstream member and AD replication before restarting the downstream member. Microsoft documents the event sequence in its missing SYSVOL/NETLOGON troubleshooting guide.

04

Measure the Backlog in Both Directions

Convergence

For partners that actually replicate with each other, query both directions and repeat over a known interval. A backlog can be normal during policy changes or after a network outage. A stable or growing backlog during an available replication schedule is more useful evidence than one count. A query error means the check failed; it does not mean the backlog is empty. Keep the test interval long enough to include the site’s configured replication availability.

dfsrdiag backlog /rgname:"Domain System Volume" `
  /rfname:"SYSVOL Share" /smem:DC01 /rmem:DC02
dfsrdiag backlog /rgname:"Domain System Volume" `
  /rfname:"SYSVOL Share" /smem:DC02 /rmem:DC01
# Repeat later and record counts, errors, and the interval.

❯ What to Verify

Both directional queries complete successfully.
Pending changes drain during the observation window, or a direction remains stalled.
An empty backlog is evidence for this pair and time, not every DC in the domain.

05

Compare One Affected GPO Against Explicit DC Paths

Policy Evidence

Use an affected GPO GUID obtained from Group Policy Management. Read that GPO through each DC and compare its GPT.INI and a specific changed policy or script file through the DC’s explicit SYSVOL path. A domain-based UNC path can use referrals and hide which DC supplied the file. Matching GPT.INI hashes alone do not prove that every file is equal, so include the file that the incident concerns. Never edit either copy as part of this comparison.

Import-Module GroupPolicy
$gpoId = '11111111-2222-3333-4444-555555555555' # Real GPO GUID
foreach ($dc in 'DC01', 'DC02') {
  Get-GPO -Guid $gpoId -Domain contoso.com -Server $dc |
    Format-List DisplayName, Id, UserVersion, ComputerVersion
  $gpt = "\\$dc\SYSVOL\contoso.com\Policies\{$gpoId}\GPT.INI"
  Get-Content -LiteralPath $gpt
  Get-FileHash -LiteralPath $gpt -Algorithm SHA256
}

❯ What to Verify

The directory and SYSVOL versions are compared on the named DCs.
Hashes and contents of the incident's specific files match or expose a difference.

06

Check the Partner Network and Storage Dependencies

Root Cause

Check partner DNS, RPC endpoint mapper connectivity, available disk space, and time synchronization. A successful TCP 135 probe reaches the endpoint mapper; it does not validate the negotiated dynamic RPC port. Correlate DFSR events with firewall logs, DNS answers, and storage errors. Fix the identified network or storage problem before requesting DFSR recovery. For site-related failures, compare schedules and topology with the AD team.

# Run on DC01; repeat from DC02 toward DC01.
Resolve-DnsName DC02.contoso.com
Test-NetConnection DC02.contoso.com -Port 135
Get-Volume | Select-Object DriveLetter, FileSystem, HealthStatus, SizeRemaining, Size
w32tm /query /status
Get-WinEvent -FilterHashtable @{
  LogName = 'System'; StartTime = (Get-Date).AddHours(-6)
} -MaxEvents 100 | Select-Object TimeCreated, ProviderName, Id, Message

❯ What to Verify

The partners resolve to current addresses and the required RPC path is verified.
Storage and time errors are tied to the same incident interval, if present.

07

Apply the Repair That Matches the Observed State

Controlled Recovery

After correcting DNS, storage, permissions, or an approved AD configuration change, request an AD configuration poll on the affected DC. This refreshes DFSR’s view of configuration; it does not force file convergence or bypass content freshness. For a current 2213 recovery, use the event’s volume-specific resume instructions. For 4012 or a verified corrupt/inconsistent SYSVOL, stop and use Microsoft’s dedicated recovery procedure with a selected healthy source, backups, and a domain-wide recovery plan.

# On the affected DC, after the approved prerequisite repair:
dfsrdiag pollad

Get-CimInstance -Namespace root\microsoftdfs `
  -ClassName DfsrReplicatedFolderInfo |
  Where-Object ReplicatedFolderName -eq 'SYSVOL Share' |
  Select-Object ReplicatedFolderName, State

❯ What to Verify

The chosen repair addresses the identified cause.
DFSR returns to Normal and new events show progress rather than repeated failures.

Recovery steps depend on the failure

FRS BurFlags instructions are not DFSR recovery instructions. Follow Microsoft’s authoritative and non-authoritative DFSR SYSVOL synchronization procedure, and do not mix it into routine backlog troubleshooting.

08

Validate Every Affected Site and the Original Client

Closeout

Repeat state, share, backlog, and file comparisons on all affected DCs, not just the repaired member. Test the original client operation after confirming which DC it uses. Refresh Group Policy only on a selected pilot client because the refresh can apply settings immediately. Retain the before/after evidence and add monitoring for stalled initialization, content freshness, persistent backlog, and low free space.

# On the affected pilot client:
nltest /dsgetdc:contoso.com /force
gpupdate /target:computer
gpresult /r /scope computer
# Recheck the specific policy/script and its explicit DC file path.

❯ What to Verify

Shares are advertised, affected partners converge, policy files agree,
and the original client receives the intended policy or logon script.

Primary references

Use Microsoft’s SYSVOL initialization troubleshooting, DFSR migration failures, replicated-folder state reference, and DFSR backlog semantics. Also see the site’s AD replication guide.