# Event ID 4012 DFSR: Replicated Folder Offline Too Long (Fix)

Source: https://srvscripts.com/guides/event-id-4012-dfsr/
Updated: 2026-10-07
Publisher: srvScripts (https://srvscripts.com/)

**Short answer:** DFSR event 4012 means content freshness protection has stopped replication of a folder. This member was disconnected longer than `MaxOfflineTimeInDays` (60 days by default on Windows Server 2012 and later), so its copy is treated as stale. Do not just raise the limit; that can bring deleted files back and overwrite newer data. Back up the folder, fix whatever stopped replication, then run a non-authoritative resync of that member. Use an authoritative sync only when every member is bad.

Commands checked against the official documentation (linked below) on 7 October 2026; not yet run on our lab servers.

## What event ID 4012 means

| Property | Value |
| --- | --- |
| Log | DFS Replication (Applications and Services Logs) |
| Source | DFSR |
| Level | Error |
| Error code in the event | 9061 (The replicated folder has been offline for too long.) |
| Logged on | The member whose copy is stale |

Microsoft has no reference page for this text. The current wording below comes from a Server 2016 event posted on Microsoft Q&A; AskDS shows the older wording:

The DFS Replication service stopped replication on the folder with the following local path: <path>. This server has been disconnected from other partners for <N> days, which is longer than the time allowed by the MaxOfflineTimeInDays parameter (<limit>). DFS Replication considers the data in this folder to be stale, and this server will not replicate the folder until this error is corrected. To resume replication of this folder, use the DFS Management snap-in to remove this server from the replication group, and then add it back to the group. This causes the server to perform an initial synchronization task, which replaces the stale data with fresh data from other members of the replication group.

Additional Information lists Error 9061, Replicated Folder Name, Replicated Folder ID, Replication Group Name, Replication Group ID and Member ID. On a domain controller, the folder is usually `SYSVOL Share` in the `Domain System Volume` group.

### Why you must not just raise MaxOfflineTimeInDays

DFSR records deletions as tombstones and purges them after 60 days. Microsoft’s AskDS team states this period is hard-coded. A member that missed more than 60 days of changes no longer knows about deletions its partners have already forgotten. If it replicates, it can send out files that were deleted on purpose and overwrite newer copies with stale ones. Content freshness exists to stop exactly that. Raising the limit past the real offline time disables the protection for the one server that needs it. Leave it at 60.

## Common causes

AskDS lists what counts as “unable to replicate”:

- The server (often a VM or branch file server) was shut down for more than 60 days.

- The DFS Replication service was stopped or disabled.

- Replication connections were disabled or deleted.

- The replication schedule was set to “no replication”.

Watch for one more case: replication stopped on the volume after an unclean shutdown (event 2213) and nobody resumed it. Once that pause passes 60 days, 4012 follows.

## How to find the cause

On the affected member, read the event and the folder state:

```
Get-WinEvent -FilterHashtable @{LogName='DFS Replication'; Id=4012} -MaxEvents 5 | Format-List TimeCreated, Message

Get-CimInstance -Namespace root/microsoftdfs -ClassName DfsrReplicatedFolderInfo |
  Select-Object ReplicationGroupName, ReplicatedFolderName, State

Get-CimInstance -Namespace root/microsoftdfs -ClassName DfsrMachineConfig | Select-Object MaxOfflineTimeInDays
```

State values from Microsoft’s WMI reference: 0 Uninitialized, 1 Initialized, 2 Initial Sync, 3 Auto Recovery, 4 Normal, 5 In Error. A folder blocked by content freshness shows 5.

Then find why it stopped. Look for an old 2213 and for service stop/start history:

```
Get-WinEvent -FilterHashtable @{LogName='DFS Replication'; Id=2213,4012,4114} -ErrorAction SilentlyContinue |
  Sort-Object TimeCreated | Format-Table TimeCreated, Id, @{n='Message'; e={($_.Message -split "`r?`n")[0]}} -Wrap
Get-Service DFSR | Select-Object Status, StartType
```

**In the console:** Event Viewer > Applications and Services Logs > DFS Replication. In DFS Management (dfsmgmt.msc), check the group’s Connections, Schedule and Membership tabs for disabled items.

**On a DC**, also compare the offline time with the AD tombstone lifetime:

```
(Get-ADObject "CN=Directory Service,CN=Windows NT,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" -Properties tombstoneLifetime).tombstoneLifetime
```

If the DC was offline longer than that, do not reconnect it. Demote it and clean up its metadata instead; see our [DC metadata cleanup guide](/guides/demote-domain-controller-metadata-cleanup/).

## How to fix it

Back up the replicated folder on this member and on a healthy partner first. A resync moves local-only files to PreExisting and locally changed files to ConflictAndDeleted. Copy out anything that only exists on this server before you start.

### Fix the root cause

Start the DFSR service and set it to Automatic, re-enable connections and open the schedule. Otherwise the error returns after the resync.

### Option 1: non-authoritative resync of a normal replicated folder (most cases)

This is the “remove and add back” the event asks for. AskDS does it by disabling and re-enabling the membership. In PowerShell (group RG-Files, folder Projects, stale member FS02):

```
Set-DfsrMembership -GroupName 'RG-Files' -FolderName 'Projects' -ComputerName 'FS02' -DisableMembership $true -Force
Update-DfsrConfigurationFromAD -ComputerName 'FS02'
# wait for event 4114 on FS02 (folder no longer replicated), allowing for AD replication
Set-DfsrMembership -GroupName 'RG-Files' -FolderName 'Projects' -ComputerName 'FS02' -DisableMembership $false -Force
Update-DfsrConfigurationFromAD -ComputerName 'FS02'
```

FS02 then runs initial sync and takes the healthy partner’s data. If an old 2213 is involved, Microsoft (KB 2979937) says to resume the volume with the ResumeReplication method before you re-enable the membership.

### Option 2: non-authoritative resync of SYSVOL on one DC

SYSVOL cannot be edited in DFS Management. Microsoft’s procedure sets `msDFSR-Enabled` to FALSE on the DC’s subscription object, replicates AD, waits for 4114, sets it back to TRUE and waits for 4614 and 4604:

```
$dn = 'CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=DC02,OU=Domain Controllers,DC=contoso,DC=local'
Set-ADObject -Identity $dn -Replace @{'msDFSR-Enabled'=$false}
repadmin /syncall /AdeP
dfsrdiag pollad          # run on DC02, then wait for event 4114
Set-ADObject -Identity $dn -Replace @{'msDFSR-Enabled'=$true}
repadmin /syncall /AdeP
dfsrdiag pollad          # run on DC02, then wait for 4614 and 4604
```

### Option 3: authoritative sync (only when every copy is bad)

If no member has good data, you need an authoritative restore. Pick one member (for SYSVOL, preferably the PDC emulator), restore good data there, and mark it authoritative (`msDFSR-options=1` for SYSVOL). Every other member is then made non-authoritative. For SYSVOL this means stopping DFSR on every DC. Follow Microsoft’s article exactly; a half-done authoritative sync causes conflicts.

## Check that it worked

Rerun the `DfsrReplicatedFolderInfo` query. State should move through 2 (Initial Sync) to 4 (Normal), with no new 4012. Check that the backlog drains, and test with a small file created on a partner:

```
Get-DfsrBacklog -GroupName 'RG-Files' -FolderName 'Projects' -SourceComputerName 'FS01' -DestinationComputerName 'FS02' -Verbose
```

For SYSVOL, look for 4604 and run `dcdiag /test:DFSREvent` on the DC.

### Common problems

- **4012 again weeks later:** the root cause (service, connection, schedule) was not fixed.

- **Users report missing files after resync:** look in the member’s DfsrPrivate\PreExisting and ConflictAndDeleted folders, or your backup.

- **Nothing happens after re-enabling:** AD has not replicated the change yet; run `repadmin /syncall /AdeP` and `Update-DfsrConfigurationFromAD` again.

## Related events

| Event ID | What it means |
| --- | --- |
| 2213 | Replication stopped on a volume after an unclean shutdown; needs admin action to resume. |
| 4114 | The replicated folder is no longer being replicated (after membership disabled). |
| 4614 | SYSVOL initialized and waiting for initial replication (non-authoritative). |
| 4604 | SYSVOL initial synchronization finished. |
| 4602 | SYSVOL initialized as authoritative. |

**Official documentation:** [Force authoritative and non-authoritative sync for DFSR SYSVOL](https://learn.microsoft.com/en-us/troubleshoot/windows-server/group-policy/force-authoritative-non-authoritative-synchronization) · [AskDS: Implementing content freshness protection in DFSR](https://learn.microsoft.com/en-us/archive/blogs/askds/implementing-content-freshness-protection-in-dfsr) · [DfsrReplicatedFolderInfo class (State values)](https://learn.microsoft.com/en-us/previous-versions/windows/desktop/dfsr/dfsrreplicatedfolderinfo) · [Microsoft Q&A: event 4012 text on Server 2016](https://learn.microsoft.com/en-us/answers/questions/872926/dfs-replication-issue-with-event-id-4012-(windows)

**Related:** [DFS Namespaces and Replication: Reliable File Server Setup](/guides/dfs-namespaces-and-replication/) · [dcdiag repadmin Health Check: 7 Critical Tests Explained](/guides/dcdiag-repadmin-dc-health-check/) · [Restore Domain Controller Backups: System State and DSRM Steps](/guides/backup-restore-domain-controller/) · [Domain Controller Metadata Cleanup: Safely Demote or Remove a Dead DC](/guides/demote-domain-controller-metadata-cleanup/)

**See also:** [DFS Replication Backlog: Check It with PowerShell and Fix It](/guides/dfs-replication-backlog-powershell/) · [Event ID 1058: Group Policy Failed to Read gpt.ini (Fix)](/guides/event-id-1058-group-policy/)

## Frequently asked questions

### Can I set MaxOfflineTimeInDays higher to clear event 4012?

Technically yes, but it removes the protection. Deleted files can come back and stale data can overwrite current files. Leave it at 60 and resync the member.

### Does event 4012 fix itself?

No. The original 2008-era wording suggested it would, but Microsoft’s AskDS team says it does not self-correct. Replication stays blocked until you resync.

### Will a non-authoritative resync delete data on the stale server?

It replaces it with the partner’s copy. Files that only existed locally go to PreExisting and local changes go to ConflictAndDeleted, so back up first.

### What is the default MaxOfflineTimeInDays?

60 days on Windows Server 2012 and later. On 2008 and 2008 R2 content freshness was off unless configured.