Recover a DFSR SYSVOL replica

Choose the recovery scope first

Use this page when the domain’s SYSVOL already uses DFSR. Check AD replication health first, because DFSR recovery settings travel through AD. Otherwise a file-copy problem and a missing configuration change can look much the same.

Microsoft’s missing-share investigation explains why database deletion and automatic reinitialization are poor first steps. The PDC emulator is a preferred authoritative candidate when its contents are good. Check those contents; holding the FSMO role doesn’t mean it has the files you need.

Preserve each candidate’s content

Back up the existing SYSVOL content on every involved DC before recovery. Include the service-managed PreExisting and ConflictAndDeleted material where relevant. Repeated initial synchronization can purge those retained files. Preserve ACLs, scripts, policy GUID directories, and a record of which DC each copy came from.

GPO directory objects and policy files are separate recovery subjects. Restoring a directory object does not reconstruct a missing script, and copying a policy folder does not reconstruct the GPO’s AD permissions, links, or version history. GPO backup and restore covers policy-level restoration when that is the actual task.

Locate the affected subscription

Use an account with the required directory and DC administration rights. The example assumes two writable DCs: DC1 has the checked good content, and DC2 is the affected member. Run the AD commands from an administrative workstation with the ActiveDirectory module, explicitly against DC1:

Import-Module ActiveDirectory
$configDc = 'DC1.contoso.com'
$computer = Get-ADComputer -Identity 'DC2' -Server $configDc
$subscription = 'CN=SYSVOL Subscription,CN=Domain System Volume,' +
    'CN=DFSR-LocalSettings,' + $computer.DistinguishedName
Get-ADObject -Identity $subscription -Server $configDc `
    -Properties 'msDFSR-Enabled','msDFSR-options' |
    Select-Object DistinguishedName,'msDFSR-Enabled','msDFSR-options'

Using the actual computer DN accommodates a moved DC computer object. Verify the returned subscription before changing it. dfsrdiag requires the DFSR management tools; local service and event commands below run on the named DC, elevated.

Reinitialize only DC2

The following sequence changes DC2’s SYSVOL subscription. Keep DC1’s healthy subscription unchanged.

1. Set DC2’s msDFSR-Enabled to FALSE.
2. Replicate that domain-NC change to DC2 and verify the attribute there.
3. On DC2 run dfsrdiag PollAD; wait for 4114.
4. Set the same attribute to TRUE.
5. Replicate and verify it on DC2 again, then run dfsrdiag PollAD there.
6. Expect 4614, followed by 4604 when initialization completes.

This is Microsoft’s nonauthoritative SYSVOL sequence. A concrete write for step 1 is:

Set-ADObject -Identity $subscription -Server $configDc `
    -Replace @{'msDFSR-Enabled' = $false}

The step 4 write uses $true. Between writes, request the domain partition from DC1 to DC2, then confirm DC2’s own view:

repadmin /replicate DC2 DC1 "DC=contoso,DC=com"

Get-ADObject -Identity $subscription -Server 'DC2.contoso.com' `
    -Properties 'msDFSR-Enabled' |
    Select-Object DistinguishedName,'msDFSR-Enabled'

A write to DC1 followed by PollAD on DC2 won’t work if DC2 hasn’t received the AD change. Wait for 4114 between disabling and enabling; writing both values before the service reads the first can skip the transition.

When the whole domain needs an authoritative copy

This changes all participating DCs and affects DFSR service availability. First inventory the domain, decide what will happen to unavailable DCs, and check the restored SYSVOL data. Stopping DFSR also affects any other DFSR replicated folders on that DC.

Follow the authoritative procedure in order, checking each phase before moving on:

Choose exactly one authoritative member. If you make DC1 authoritative but leave the other active DCs untouched, competing data can reappear. Setting Options 1 alone won’t do the recovery. If only one member is unhealthy, use the smaller nonauthoritative operation.

Read event gates as a sequence

4614 without a later 4604 means the member is still waiting for initial synchronization. Check its configured source, source state, connectivity, and backlog. 4114 confirms the subscription stopped replicating; that’s expected during the disable phase. 4602 identifies authoritative/primary initialization. Check the event’s message, instance and time so you don’t mistake an old event for this recovery.

For 2213, back up affected folders and use the volume-specific ResumeReplication operation described in that event and the 2213 guide. For 4012, content freshness has stopped an outdated folder; inspect MaxOfflineTimeInDays and select a valid source/reinitialization plan. Raising the limit does not establish which data is correct.

Recover preserved files into a separate destination

Where the DFSR module and relevant manifests are available, inspect retained files with Get-DfsrPreservedFiles. A deliberate recovery can copy all retained versions into a separate recovery directory:

Restore-DfsrPreservedFiles `
    -Path 'C:\Windows\SYSVOL\domain\DfsrPrivate\ConflictAndDeletedManifest.xml' `
    -RestoreToPath 'C:\Recovered-SYSVOL' -RestoreAllVersions -CopyFiles -WhatIf

Replace the sample with the actual replicated-folder path and its preserved manifest; migrated domains may use a different tree such as SYSVOL_DFSR. This example is a preview. Preserve the manifest and associated files before restoring. -CopyFiles preserves source material; omitting it can move files and remove retained versions. See the preserved-file command reference.

Run the share, state, backlog, and content checks, then test Group Policy processing on representative clients. Initialization completing doesn’t tell you the policies work for those clients.