So today I just happened to notice that one of our DCs at work didn’t have the latest version of a GPO.

I was creating a new policy using Group Policy Preferences (amazing bit of kit btw – have a look at Alan Burchill’s how to get rid of your logon scripts video here: http://www.grouppolicy.biz/2012/09/teched-2012-video-how-to-get-rid-of-your-logon-scripts-the-easy-and-free-way/), and I was using the Group Policy Results Wizard to see if my changes were being applied to a remote machine – they weren’t.

My first response was to try a gpupdate /force on the machine in question – this didn’t help, but it did make me wonder if this was a AD replication issue.

Back in Group Policy Managment Console, I clicked on our domain and hit ‘detect now’ at the bottom of the screen. Sure enough, it came back with: 1 Domain Controller(s) with replication in progress, listing one of our DCs. Clicking the link under SysVol gave me a box telling me that 2 GPOs were out of date with the baseline controller – one of which was the policy I was editing… yay(!)

Having given the DCS plenty of time to replicate (the next day in this case), I decided to investigate a little further. All of our DCs run Server 2012, and the Forest and Domain Function Levels is set at 2012.

Looking on the server in question, a line in the error logs for DFSR drew my attention:

The DFS replication service stopped replication on volume C:. This occurs when a DFSR JET datavase 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.

Okay – so the server must’ve crashed at some point in the past and caused this error. Not a problem – the error message helpfully gives you the command to run:

wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid=”B4A015E2-A116-11DE-89FB-806E6F6E6963″ call ResumeReplication

After copy pasting the SysVol folder onto my desktop, I tried to run the command in an elevated PowerShell prompt (cos Microsoft love you if you use PowerShell!) and got the following error: Unexpected switch at this level.

Edit: Microsoft have since published an article about this issue – Adam’s comment below explains it – thanks!

According to this article: http://support.microsoft.com/kb/2846759 (about half way down)

Note for PowerShell users: You will need to add single quotations to the WMIC command to run it from PowerShell:

wmic /namespace:\\root\microsoftdfs pathdfsrVolumeConfig where ‘volumeGuid=”F1CF316E-6A40-11E2-A826-00155D41C919″’ call ResumeReplication

Running the command again, but this time in an elevated command prompt window, yields a lovely response stating that replication will occur.

Looking back at the event log, I thought all was sorted until this one popped up:

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 64 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.

Which indicates that this DC has been out of sync since sometime in November last year! We don’t tend to change our policies that often, so I hadn’t noticed this issue before.

Unfortunately, the advice given in the message (to use the DFS management snap in to remove and replace the DFS member) isn’t applicable when you’re trying to replicate the SysVol folder – it doesn’t let you!

Instead, after making sure I had a backup of the SysVol folder, I ran the following:

wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=65

Then re-ran the ResumeReplication call. After a few minutes, I received message ID 4002 from DFSR: The DFS Replication service successfully initialized the replicated folder at local path C:\Windows\SYSVOL\domain. YAY!

Why did this occur? Well in Server 2008 R1 SP1 (and included in 2012), Microsoft introduced a lovely registry key called ‘StopReplicationOnAutoRecovery’ located here: HKLM\System\CurrentControlSet\Services\DFSR\Parameters. When it is set to 1, whenever the server experiences an invalid (dirty) shutdown, DFS replication just stops. No brightly coloured message to tell you this, no message in ADDS, it just stops. Very helpful. Apparently, the reason they’ve done this is to stop files from being lost on downstream servers when upstream servers experience a power loss or whatever. It is up to you as the administrator to resume replication and see which versions of the files is most up to date.

Although this makes much sense, when we’re talking about the SYSVOL folder which doesn’t seem to change much in our case, I’d like it to resume replication automatically. Luckily, there’s an easy way to make this happen!

1. Change the HKLM\System\CurrentControlSet\Services\DFSR\Parameters\StopReplicationOnAutoRecovery registry key to a DWORD value of 0 (or delete it).

2. Run in an elevated command prompt:

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set StopReplicationOnAutoRecovery=FALSE

If you’re running a RODC, you’ll be fairly safe to enable this command, as it will just re-sync the data from the sending server whenever there’s a dirty shutdown. Other implementations of DCs, you may want to proceed with a bit of caution! Remember you can attach tasks to specific events in eventmgr – get it to send you an email or create a file on your desktop?

The Microsoft KB that deals with this is here: http://support.microsoft.com/kb/2663685