We have an active directory server as global catalog and DC, this one has operations master running.

We have a second ADDC Global catalog and exchange server.

I started getting the message below on the main ADDC

Log Name: DFS Replication Source: DFSR Date:
2/1/2014 12:43:22 AM Event ID: 4012 Task Category: None Level:
Error Keywords: Classic User: N/A Computer:
Description: The DFS Replication service stopped replication on the folder with the following local path: C:\Windows\SYSVOL\domain. This server has been disconnected from other partners for 126 days, which is longer than the time allowed by the MaxOfflineTimeInDays parameter (60). 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.

In the exchange server I get this error

The DFS Replication service stopped replication on volume C:. This occurs when a DFSR JET database is not shut down cleanly and Auto Recovery is disabled. To resolve this issue, back up the files in the affected replicated folders, and then use the ResumeReplication WMI method to resume replication. Additional Information: Volume: C: GUID: F18E11A2-980C-11E2-93E8-806E6F6E6963 Recovery Steps 1. Back up the files in all replicated folders on the volume. Failure to do so may result in data loss due to unexpected conflict resolution during the recovery of the replicated folders. 2. To resume the replication for this volume, use the WMI method ResumeReplication of the DfsrVolumeConfig class. For example, from an elevated command prompt, type the following command: wmic /namespace:\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="F18E11A2-980C-11E2-93E8-806E6F6E6963" call ResumeReplication

I tried following this guy here, but I can't seem to find this in ADSI Edit:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name>,OU=Domain Controllers,DC=<domain>
  • When you double-click on the domain controller in ADSIEdite, you don't see "CN=DFSR-LocalSettings"? What folders do you see under the domain controller? – Greg Askew Feb 1 '14 at 15:41
  • Is your AD replication still happening? Why DFSR stopped replication for such a long time in the first place? I recommend to ensure AD replication working before fixing any DFSR issue. Next step is to followed instruction in event log, instead of going for a different KB. – strongline Feb 2 '14 at 18:49

You have three different problems here.

  1. You have one server acting as a Domain Controller and an Exchange server at the same time. This is bad. This isn't the cause of your problem, but you should be aware that this is not how you should have this configured. Exchange and AD should be installed on separate servers that are dedicated to each role.

  2. You had an unexpected shutdown on the Exchange server. This could be a power outage, or any other unclean shutdown. In Server 2008 R2 SP1 and Windows Server 2012, DFS-R will not resume replication automatically on unclean shutdowns. The error message that you've posted tells you the exact command to bring replication of the volume back online. Microsoft has released guidance for when and how to enable auto-recovery so that you don't need to mess with the wmic command each time you have an unclean shutdown. Domain Controllers are one instance where auto-recovery should always be enabled. Do this.

  3. Your Exchange/DC and FSMO-holding DC haven't replicated sysvol in longer than the MaxOfflineTimeInDays threshold - this is called Content Freshness Protection in DFS terminology. You will have to determine which server's SYSVOL share has the most up to date information and use it as the authoritative source for replication and follow this document to resume replication.

In short - restart replication on the Exchange/DC server with the wmic command in the error message. Then, configure auto-recovery to prevent this in the future, then force an authoritative replication of sysvol to get the replication group running again.

  • In terms of number 2, Unexpected shutdowns like power-loss aren't the only situation where the DFS database has a "dirty" shutdown. If the server is under heavy load, and the DFS Service doesn't manage to commit all of it's database to disk within 30 seconds on a regular shutdown, that is still marked as a "dirty" shutdown and will need auto-recovery or reinitialization. This is yet another reason to not have DC and Exchange on the same server too... – camster342 Aug 5 '14 at 0:11

When Server 2008 R2 has an unexpected DFS-R disconnect, it does not automatically start replicating again - as per the 2nd message in your event log.

You can restart replication using the following command:

wmic /namespace:\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="F18E11A2-980C-11E2-93E8-806E6F6E6963" call ResumeReplication

(as printed in the bottom of your 2nd event log message). Also heed attention to the bit where it tells you to back it up in case of an unexpected conflict.

The other option is to do as your first event log message says - open the DFS-R management MMC and remove and re-add the server from the replication group.

  • 1
    Unfortunately, the Domain System Volume is a special case replication group and cannot be managed via the DFS snap-in. – MDMarra Feb 2 '14 at 22:30
  • Oh, right. Well you can always try re-starting I guess... – Mark Henderson Feb 2 '14 at 22:38
  • It's more of a PITA than that - you need to force an authoritative sync of sysvol using adsiedit. It's fun! – MDMarra Feb 2 '14 at 22:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.