How to Recover DFSR SYSVOL Replication After Event ID 4012 (State 5)

Few Active Directory problems are as misleading as a broken SYSVOL that looks healthy. Users log on, repadmin reports zero failures, and dcdiag passes on the primary domain controller. Meanwhile a second domain controller has been stuck in initial synchronization for days, Group Policy processing throws Event ID 1058, and the DFS Replication log on the primary contains a quiet but decisive Event ID 4012.

This guide walks through a real-world failure pattern: a two-DC domain where the existing domain controller was disconnected from its DFSR partner for far longer than the default MaxOfflineTimeInDays value of 60 days. DFSR correctly decided that the server’s replicated folder was stale and stopped replicating it, which left the second DC with no usable source for SYSVOL. The recovery is an authoritative DFSR SYSVOL restore, performed deliberately, with verification checkpoints at every stage.

All names in this article are generic. DC01 is the existing or primary domain controller, DC02 is the secondary domain controller, and example.local is the Active Directory domain.

When this procedure applies

Not every Event 4012 requires an authoritative SYSVOL restore. The pattern in this article is appropriate when all of the following are true:

• The domain controller you intend to use as the source contains the known-good, current SYSVOL content.
• Another DC cannot complete SYSVOL initial synchronization.
• DFSR has blocked the known-good source because it exceeded MaxOfflineTimeInDays.
• Active Directory replication itself is healthy.

Important: if your environment has additional domain controllers, conflicting SYSVOL versions, uncertain source data, or signs of broader Active Directory corruption, stop and determine the correct authoritative copy before proceeding. An authoritative restore overwrites SYSVOL on every other member with the content of the chosen server. Choosing the wrong source replicates the wrong policies everywhere.

Symptoms

The environment presented roughly like this:

DC01
DFSR SYSVOL state: 5
Event ID 4012
SYSVOL and NETLOGON still shared
AD replication otherwise functional

DC02
DFSR SYSVOL state: 2
Initial synchronization
Unable to complete SYSVOL synchronization
Repeated Group Policy Event ID 1058

The detail that makes this incident confusing is that every common health check on DC01 looked acceptable. repadmin /replsummary and repadmin /showrepl showed successful replication. The following dcdiag run passed on DC01 even though DFSR reported SYSVOL in an error state:

dcdiag /test:replications /test:advertising /test:sysvolcheck /test:netlogons

DC01 also still published both shares:

net share

The truth only appeared when querying DFSR directly through WMI:

Get-CimInstance -Namespace "root\MicrosoftDFS" -ClassName DfsrReplicatedFolderInfo |
Where-Object {$_.ReplicatedFolderName -eq "SYSVOL Share"} |
Select-Object ReplicationGroupName,ReplicatedFolderName,State

On DC01 this returned State 5. On DC02 it returned State 2. DC02 was waiting to pull SYSVOL from a partner that DFSR itself had taken out of service, so it could never finish.

Understanding DFSR SYSVOL states

The State property of DfsrReplicatedFolderInfo is the fastest way to see where each member stands:

The goal of the entire recovery is simple to state: DC01 = State 4 and DC02 = State 4. Every step below either moves a server toward that state or verifies that it got there.

Why AD replication can work while SYSVOL replication is broken

Active Directory and SYSVOL are replicated by two different engines. Directory objects such as users, groups, computer accounts, and the Group Policy container objects in AD are replicated by the directory service itself. The files inside SYSVOL, including each GPO’s gpt.ini, registry.pol files, and logon scripts, are replicated by the DFS Replication service.

That separation is why the two can disagree. repadmin validates directory replication only. A clean repadmin /replsummary tells you nothing about whether DFSR is moving SYSVOL files. Likewise, the presence of the SYSVOL and NETLOGON shares only proves that Netlogon is advertising them, not that their content is replicating.

One practical consequence: because a GPO has both an AD component and a SYSVOL component, a broken SYSVOL produces mismatches. A client can learn about a GPO from AD replication, then fail to read the matching files from a DC that never received them. That is exactly what Event 1058 reports.

Identifying Event 4012 and MaxOfflineTimeInDays

Pull the relevant DFSR events from both domain controllers:

Get-WinEvent -LogName "DFS Replication" -MaxEvents 100 |
Where-Object {$_.Id -in 2213,4012,4114,4602,4604,4614,2104,5002,5008} |
Select-Object TimeCreated,Id,LevelDisplayName,Message |
Format-List

On DC01 the key entry was:

Event ID 4012
Error 9061
The replicated folder has been offline for too long.

The event text explains that the server has been disconnected from its partners for longer than MaxOfflineTimeInDays, which defaults to 60 days, and that DFSR therefore considers the replicated data stale. DFSR stops replicating that folder rather than risk reintroducing old content, including deleted or superseded GPO files, into the rest of the domain.

The event IDs worth knowing for this recovery:

The other IDs in the filter (2213, 2104, 5002, 5008) cover dirty database shutdowns, database recovery failures, and partner communication errors. They are included so that an unrelated DFSR problem does not hide behind the 4012 you are focused on. If you see them, investigate them before continuing.

You can read the configured value on any DC without changing anything:

Get-CimInstance -Namespace "root\MicrosoftDFS" -ClassName DfsrMachineConfig |
Select-Object MaxOfflineTimeInDays

Why not just raise MaxOfflineTimeInDays?

A common suggestion online is to raise MaxOfflineTimeInDays to a very large number and restart DFSR. That can bring a stale member back into replication, but it does so by switching off the exact safety check that tripped. The protection exists to stop a very old DFSR database from automatically reintroducing stale data. Raising the limit does not answer the question that actually matters: which server holds the correct SYSVOL?

The safer path is to identify the known-good copy first and then tell DFSR explicitly that it is authoritative. That is what the rest of this guide does.

Selecting the authoritative SYSVOL source

Before touching any DFSR attribute, decide which domain controller holds the SYSVOL content you want every other DC to end up with. In this scenario DC01 was selected because:

• It had historically been the primary DC.
• It held the FSMO roles, including the PDC Emulator.
• Its SYSVOL and NETLOGON shares were active.
• Its SYSVOL contained the expected GPO content, and the affected GPO files were readable.
• Active Directory replication was working.
• DC02 had never completed SYSVOL initial synchronization, so it had no complete copy to offer.

Holding the PDC Emulator role does not automatically make a DC the right SYSVOL source. The Group Policy Management Console targets the PDC Emulator by default, so it is often where recent edits land, but the decision must be based on which DC actually contains the known-good SYSVOL data. If two DCs have diverged and both contain changes you need, reconcile the content first.

Pre-recovery validation

Capture the current state of both DCs. These results are your baseline and will tell you whether anything other than DFSR is wrong.

repadmin /replsummary
repadmin /showrepl

dcdiag /test:replications /test:advertising /test:sysvolcheck /test:netlogons

net share

Get-Service DFSR,Netlogon,DNS,Kdc

Get-CimInstance -Namespace "root\MicrosoftDFS" -ClassName DfsrReplicatedFolderInfo |
Where-Object {$_.ReplicatedFolderName -eq "SYSVOL Share"} |
Select-Object ReplicationGroupName,ReplicatedFolderName,State

Checkpoint: AD replication should show zero failures and DNS, Kdc, and Netlogon should be running. If AD replication is failing, fix that first. The authoritative restore depends on AD replicating the attribute changes you are about to make.

Backing up SYSVOL

Take a copy of the known-good SYSVOL on DC01 before changing anything:

New-Item -ItemType Directory -Path C:\SYSVOL-Backup -Force

robocopy C:\Windows\SYSVOL\domain C:\SYSVOL-Backup\domain /MIR /COPYALL /R:1 /W:1

Verify the copy:

Get-ChildItem C:\SYSVOL-Backup\domain

Both Policies and scripts should be present. /COPYALL preserves NTFS permissions, owners, and auditing information, which matters for GPO folders.

If the copy also captured DfsrPrivate, keep it with the backup for evidence and rollback purposes, but do not blindly restore that directory back into SYSVOL during a manual file recovery. It holds DFSR’s internal staging and conflict data, not policy content. Any restoration of SYSVOL content should be handled carefully and limited to Policies and scripts.

Validating the known-good SYSVOL

Confirm that DC01 actually has the content that clients or DC02 are failing to reach. Use the GPO GUID named in the Event 1058 path:

Get-Item "C:\Windows\SYSVOL\domain\Policies\{GPO-GUID}\gpt.ini"

Get-Content "C:\Windows\SYSVOL\domain\Policies\{GPO-GUID}\gpt.ini"

A readable gpt.ini with a sensible version number is evidence that this server is a reasonable source. If the file is missing or unreadable on your intended source, stop and reassess which DC is authoritative.

Authoritative SYSVOL recovery

This section modifies Active Directory DFSR configuration. Perform it only after you have identified the correct SYSVOL source and taken a backup. Work through the steps in order and do not skip the checkpoints.

Step 1: Stop DFSR on both domain controllers

Stop the non-authoritative DC first so it cannot attempt to sync while you work. Setting the startup type to Manual prevents a reboot from restarting DFSR mid-procedure.

On DC02:

Set-Service DFSR -StartupType Manual
Stop-Service DFSR

Then on DC01:

Set-Service DFSR -StartupType Manual
Stop-Service DFSR

Step 2: Modify the SYSVOL Subscription objects in ADSI Edit

Open adsiedit.msc and connect to the Default Naming Context. Navigate to each DC’s subscription object:

DC=example,DC=local
  OU=Domain Controllers
    CN=DC01
      CN=DFSR-LocalSettings
        CN=Domain System Volume
          CN=SYSVOL Subscription

On the authoritative DC (DC01):

msDFSR-Enabled = FALSE
msDFSR-options = 1

On the non-authoritative DC (DC02):

msDFSR-Enabled = FALSE
msDFSR-options = 0   (or leave its existing normal value)

Do not set msDFSR-options = 1 on more than one domain controller. That flag marks the designated primary member. Two primaries means two competing authoritative copies.

Step 3: Replicate the attribute changes

repadmin /syncall /AdeP

Verify:

repadmin /replsummary

Remember that this step validates Active Directory replication of the attribute changes, not SYSVOL file replication. Both DCs need to see the new values before DFSR reads them. If you made the edits on one DC, it is worth opening ADSI Edit against the other DC and confirming the values arrived.

Step 4: Start DFSR on the authoritative DC only

On DC01:

Set-Service DFSR -StartupType Automatic
Start-Service DFSR

If the DFS management tools are installed, force DFSR to read its AD configuration:

dfsrdiag pollad

dfsrdiag ships with the DFS Management tools (Install-WindowsFeature RSAT-DFS-Mgmt-Con). If it is not available, restarting the DFSR service has the same effect of rereading configuration from AD.

Check the log:

Get-WinEvent -LogName "DFS Replication" -MaxEvents 30 |
Where-Object {$_.Id -in 4114,4602,4604,4614,4012} |
Select-Object TimeCreated,Id,LevelDisplayName,Message |
Format-List

Checkpoint: expect Event 4114, confirming that SYSVOL replication is disabled on DC01. If you do not see it, confirm the attribute values replicated to DC01 and poll AD again before continuing.

Step 5: Re-enable the authoritative DC

On DC01’s SYSVOL Subscription object:

msDFSR-Enabled = TRUE
msDFSR-options = 1

Replicate the change:

repadmin /syncall /AdeP

Then run dfsrdiag pollad on DC01, or restart DFSR if dfsrdiag is unavailable.

The critical success event is Event ID 4602: the DFS Replication service successfully initialized SYSVOL, and this server is the designated primary member for the replicated folder. In other words, DFSR has accepted DC01’s content as authoritative and cleared the stale condition that produced Event 4012.

Verify the state:

Get-CimInstance -Namespace "root\MicrosoftDFS" -ClassName DfsrReplicatedFolderInfo |
Where-Object {$_.ReplicatedFolderName -eq "SYSVOL Share"} |
Select-Object ReplicationGroupName,ReplicatedFolderName,State

Expected: State = 4.

Checkpoint: do not proceed to DC02 until DC01 has logged Event 4602 and reports State 4. If DC01 is not healthy, DC02 has nothing valid to synchronize from.

Reinitializing the secondary domain controller

With DC01 healthy, DC02 can perform a normal, non-authoritative initial synchronization from it.

On DC02’s SYSVOL Subscription object:

msDFSR-Enabled = TRUE
msDFSR-options = 0

Replicate:

repadmin /syncall /AdeP

Then on DC02:

Set-Service DFSR -StartupType Automatic
Start-Service DFSR

If DFSR does not pick up the change, restart it:

Restart-Service DFSR

Monitor the log on DC02:

Get-WinEvent -LogName "DFS Replication" -MaxEvents 50 |
Where-Object {$_.Id -in 4114,4602,4604,4614,4012} |
Select-Object TimeCreated,Id,LevelDisplayName,Message |
Format-List

You may see Event 4614 first, indicating that SYSVOL is initialized and waiting for initial synchronization. The event that matters is Event ID 4604:

The DFS Replication service successfully initialized the SYSVOL replicated folder.
This member has completed initial synchronization of SYSVOL with its replication partner.

Confirm the state:

Get-CimInstance -Namespace "root\MicrosoftDFS" -ClassName DfsrReplicatedFolderInfo |
Where-Object {$_.ReplicatedFolderName -eq "SYSVOL Share"} |
Select-Object ReplicationGroupName,ReplicatedFolderName,State

Expected: State = 4.

Checkpoint: on a small SYSVOL, 4604 usually arrives within minutes. If DC02 stays at State 2 with no 4604, recheck that DC01 is still at State 4, that the attribute changes replicated, and that the DFSR log on either DC is not reporting partner communication errors such as 5002 or 5008.

Validating DFSR, SYSVOL, and NETLOGON

On each DC, confirm the shares:

net share

Both domain controllers should publish SYSVOL and NETLOGON. A DC that has not finished initial synchronization will not advertise SYSVOL, so DC02 publishing both shares is itself a useful signal.

dcdiag /test:sysvolcheck /test:netlogons

Both tests should pass on both DCs. Then run the broader checks across the enterprise:

dcdiag /e /test:replications /test:sysvolcheck /test:netlogons

repadmin /replsummary

Expected: 0 replication failures.

Confirming Group Policy recovery

The user-visible symptom of the broken SYSVOL was repeated Microsoft-Windows-GroupPolicy Event ID 1058, with Windows unable to read a path like:

\\example.local\SYSVOL\example.local\Policies\{GPO-GUID}\gpt.ini

First confirm the GPO now exists on DC02:

Get-Item "C:\Windows\SYSVOL\domain\Policies\{GPO-GUID}\gpt.ini"

Get-Content "C:\Windows\SYSVOL\domain\Policies\{GPO-GUID}\gpt.ini"

Then force a policy refresh and look only for new 1058 events:

$Start = Get-Date

gpupdate /force

Start-Sleep -Seconds 10

Get-WinEvent -FilterHashtable @{
    LogName='System'
    Id=1058
    StartTime=$Start
} | Select-Object TimeCreated,Id,ProviderName,Message

In this specific test, the following output is a good result:

Get-WinEvent : No events were found that match the specified selection criteria.

It means no new Event 1058 was logged after forcing Group Policy. Filtering on StartTime matters here, because the System log will still contain the older 1058 entries from before the repair.

Checking Windows Time and time zone configuration

A side issue surfaced during troubleshooting that is worth its own section. DC02 appeared to be roughly three hours behind DC01. At first glance that looks serious, because real clock skew between domain members can break:

• Kerberos authentication
• Domain logons
• Group Policy processing
• Secure channels
• Certificate validation
• Some replication operations

The Windows Time status told a different story:

w32tm /query /status

It showed DC02 successfully synchronized from DC01. The time hierarchy was fine. The actual problem was the time zone:

Get-TimeZone

DC02 was set to Pacific Standard Time instead of the site’s intended Eastern Standard Time. Correcting it:

Set-TimeZone -Id "Eastern Standard Time"

made the displayed time correct while the underlying NTP synchronization stayed exactly as it was. DC02 continued to use DC01 as its Windows Time source.

A time zone mismatch changes how local time is displayed. It does not mean the system clocks are three hours apart in UTC. Kerberos compares UTC time, so a pure time zone error does not cause authentication failures. The same mismatch also explained why replicated SYSVOL file timestamps appeared three hours apart between the two servers even though they represented the same moment.

Before assuming clock skew, compare w32tm /query /status and Get-TimeZone on both servers. If the source and last successful sync look right, check the time zone before touching the time service.

Post-recovery cleanup

Once both DCs are healthy, return the DFSR options on the authoritative DC to normal. msDFSR-options = 1 is only needed during authoritative initialization. After Event 4602 and a successful recovery, it has done its job.

Authoritative DC (DC01):

msDFSR-Enabled = TRUE
msDFSR-options = 0

Secondary DC (DC02):

msDFSR-Enabled = TRUE
msDFSR-options = 0

There is no need to delete the attribute. Setting it to 0 is correct. Replicate the cleanup:

repadmin /syncall /AdeP

Also confirm the DFSR service startup type is back to Automatic on both DCs.

Final validation checklist

• Both DCs report DFSR SYSVOL State 4.
• The authoritative DC logged Event 4602 during recovery.
• The secondary DC logged Event 4604.
• SYSVOL is shared on both DCs.
• NETLOGON is shared on both DCs.
• repadmin /replsummary shows zero failures.
• dcdiag SYSVOL, Netlogon, and Replication tests pass.
• gpupdate /force succeeds.
• No new Group Policy Event 1058 errors appear.
• The Windows Time hierarchy is correct.
• Time zones are correct on every DC.
• msDFSR-Enabled = TRUE on both DCs.
• msDFSR-options = 0 on both DCs after recovery.

Lessons learned

Check DFSR directly. repadmin, a passing dcdiag, and visible SYSVOL shares are not proof that SYSVOL is replicating. The DfsrReplicatedFolderInfo state and the DFS Replication event log are. Add the state query to routine DC health checks so a State 5 is found in days, not months.

Respect MaxOfflineTimeInDays. Event 4012 is DFSR protecting you from stale data. Treat it as a prompt to decide which copy is authoritative, not as a limit to raise and forget.

Decide the source on evidence. FSMO ownership is a useful hint, not a rule. Verify the GPO content on the candidate source before declaring it authoritative.

Back up before you flip flags. A robocopy /COPYALL of SYSVOL takes seconds and gives you a rollback path if the chosen source turns out to be wrong.

Follow the checkpoints. Event 4114, then 4602 and State 4 on the authoritative DC, then 4604 and State 4 on the secondary. If an expected event does not appear, stop and find out why before moving to the next step.

Separate display time from clock time. A multi-hour difference between DCs is more often a time zone setting than real skew. w32tm /query /status answers the question in seconds.

If you run Windows domain controllers on dedicated hardware and want help designing monitoring that catches DFSR state changes early, ARPHost works with teams on server infrastructure and management.