SYSVOL and Group Policy out of Sync on Server 2012 R2 DCs using DFSR

73 Replies

Recently while making changes to group policy, I noticed a slew of issues between clients not accepting the policy. This eventually led me to the discovery that two of the DCs in this particular environment were not replicating properly and were resulting in inconsistent SYSVOL shares.

Symptoms

On the clients we were seeing the following errors when executing the gpupdate command:

Event Viewer Logs

Log Name: System
Source: Microsoft-Windows-GroupPolicy
Date: 7/25/2014 10:46:45 AM
Event ID: 1096
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: mymachine.mydomain.local
Description:
The processing of Group Policy failed. Windows could not apply the registry-based policy settings for the Group Policy object LDAP://CN=Machine,cn={CF25ED30-3895-4147-8EB7-38789553F6A0},cn=policies,cn=system,DC=mydomain,DC=local. Group Policy settings will not be resolved until this event is resolved. View the event details for more information on the file name and path that caused the failure.

On the DCs we were seeing the following events inside of Event Viewer -> Applications and Service Logs -> DFS Replication

Log Name: DFS Replication
Source: DFSR
Date: 7/25/2014 1:04:30 PM
Event ID: 4612
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: DC02.mydomain.local
Description:
The DFS Replication service initialized SYSVOL at local path C:\Windows\SYSVOL\domain and is waiting to perform initial replication. The replicated folder will remain in the initial synchronization state until it has replicated with its partner DC01.mydomain.local. If the server was in the process of being promoted to a domain controller, the domain controller will not advertise and function as a domain controller until this issue is resolved. This can occur if the specified partner is also in the initial synchronization state, or if sharing violations are encountered on this server or the sync partner. If this event occurred during the migration of SYSVOL from File Replication service (FRS) to DFS Replication, changes will not replicate out until this issue is resolved. This can cause the SYSVOL folder on this server to become out of sync with other domain controllers.

Additional Information:
Replicated Folder Name: SYSVOL Share
Replicated Folder ID: 2276C68D-BC24-46BF-B492-067919163EDA
Replication Group Name: Domain System Volume
Replication Group ID: D50C64AE-0A01-4F97-B838-069F0BCBE369
Member ID: 7ADF2D7C-7947-412C-A619-C0C0D72F6A9C
Read-Only: 0

Log Name: DFS Replication
Source: DFSR
Date: 7/25/2014 1:04:30 PM
Event ID: 5002
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: DC02.mydomain.local
Description:
The DFS Replication service encountered an error communicating with partner DC01 for replication group Domain System Volume.

Partner DNS address: DC01.mydomain.local

Optional data if available:
Partner WINS Address: DC01
Partner IP Address: 192.168.1.5

The service will retry the connection periodically.

Additional Information:
Error: 1753 (There are no more endpoints available from the endpoint mapper.)
Connection ID: D50C64AE-0A01-4F97-B838-069F0BCBE369
Replication Group ID: 4DCE6A8E-6271-48B6-A0D0-5447718B8FAB

Solution

We ended up having to manually preform an authoritive synchronization between the two DCs. As you may know, DFSR no longer uses the same steps as FSR to do an authoritive sync. Below are my notes and expereinces on completing an authoritive DFSR sync. You can find the ofificial notes from Microsoft here: http://support.microsoft.com/kb/2218556/en-us

Logon to your primary DC
Stop the DFS Replication service
1. Click on the Start menu, select Administrative Tools, and then click Services
2. In the Name column, right-click DFS Replication or Netlogon, and then click Stop
Open up ADSI Edit
Open up the Default naming context
Navigate to the following
1. CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name to replicate from>,OU=Domain Controllers,DC=<domain>
Change the following attributes to the following values
1. msDFSR-Enabled=FALSE
  msDFSR-options=1
  
  Both values applied
  1. Note: If you cannot see msDFSR-options, uncheck Show only attributes that have values
On the ALL other DCs, change the msDFSR-Enabled attribute to False
Force Active Directory replication throughout the domain (ensure all sync resposnes terminate with no errors).
1. repadmin /syncall primary_dc_name /APed
  1. NOTE: Here is a list of what the switches mean
    1. /A: Perform /SyncAll for all NC's held by <Dest DSA> (ignores <Naming Context>)
    2. /P: Push changes outward from home server (default: pull changes)
    3. /e: Enterprise, cross sites (default: only home site)
    4. /d: ID servers by DN in messages (instead of GUID DNS)
Start the DFSR service back up on the authoritive DC
1. Click on the Start menu, select Administrative Tools, and then click Services
2. In the Name column, right-click DFS Replication or Netlogon, and then click Start
Open up event viewer and navigate to Applications and Services Logs -> DFS Replication. Verify you see Event ID 4114.
Navigate back to the following in ADSI
1. 1. CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name to replicate from>,OU=Domain Controllers,DC=<domain>
Set the value of msDFSR-Enabled to TRUE
Execute the following via an elevated command prompt
1. DFSRDIAG POLLAD
  1. NOTE: This is a utility apart of DFS Managment Tools. I completed the guide successfully without running this command, but Microsoft recommends you do run this command.
Force Active Directory replication throughout the domain
1. repadmin /syncall primary_dc_name /APed
Wait a few minutes and you should see Event ID 2002 and 4602
Navigate back to each of your secondary DCs and change the value of msDFSR-Enabled to TRUE
Execute the following via an elevated command prompt
1. DFSRDIAG POLLAD
  1. NOTE: This is a utility apart of DFS Managment Tools. I completed the guide successfully without running this command, but Microsoft recommends you do run this command. Force Active Directory replication throughout the domain
Verify you see Event ID 2002 and 4602 on each of the secondary DCs

At this point, try running a gpupdate on your client. If all has gone well, each of your shared SYSVOL folders on your DCs should contain the same amount of policies and your client should successfully pull down all policies.

73 thoughts on “SYSVOL and Group Policy out of Sync on Server 2012 R2 DCs using DFSR”

Alex August 25, 2014 at 6:18 am

Beautiful article but you need to mention that the DFS Replication service needs to be stopped in advance and then started during the process, you can check with Microsoft article (which failed to mention about that as well but mentioned the steps we need to run the service.)

Reply ↓
1. Jack Post authorAugust 25, 2014 at 8:57 am
  
  Thanks Alex,
  
  I have added in the additional steps to stop/start the DFS Replication service per the Microsoft article.
  
  Jack
  
  Reply ↓
Pingback: GPupdate fails to run on cliens after DFRS replicated DC’s experience a dirty shutdown | syshead
Peter Robinson February 24, 2015 at 9:33 am

Thanks - great article sorted my issue out !

Reply ↓
Vladislav Artukov February 27, 2015 at 12:23 pm

Some time ago they (our "now" clients) migrated from FRS to DFSR without success and frozen this bad configuration. Today I fall in the troubleshooting. And found this article. You are great!

Thank you!

Reply ↓
1. Jack Post authorMarch 2, 2015 at 6:14 pm
  
  Glad to hear this helped Vladislav! 🙂
  
  Reply ↓
Aleksi March 18, 2015 at 3:57 am

Thank you so much! I couldn't have made it without these great step-by-step instructions 🙂

Reply ↓
Yves March 24, 2015 at 6:41 am

Hi Jack, great article! It is better elaborated than the one from Microsoft.
One question though : does the msDFSR-Options value on the primary DC has to stay "1"? In your and Microsoft's article it is not put back to "0". Do you know why that is?

Kind regards. Yves.

Reply ↓
1. Jack Post authorMarch 26, 2015 at 11:05 am
  
  You can remove the value if you want to once done with the article, but it won't hurt letting it stay as 1.
  
  Jack
  
  Reply ↓
  1. Yves March 27, 2015 at 12:29 am
    
    Thanks for your reply, Jack. I was just wondering if leaving the value on 1 meant that all DFS changes have to be applied on that authoritative server from then on. Kind regards. Yves
    
    Reply ↓
    1. Jack Post authorMarch 27, 2015 at 7:30 am
      
      No, that is definitely will not be the case. You can ensure this isn't the intended behavior by creating a new group policy object on your secondary DC and seeing if the sysvol folder replicates it over (which it should).
      
      Jack
      
      Reply ↓
Oliver April 15, 2015 at 3:02 am

Thanks - it worked perfect! Issue: Windows Server 2012 R2 (two Domain Controller).

Reply ↓
Jon April 23, 2015 at 11:56 am

Had multiple issues with replication and updated sysvol policies. This fixed all of them on our 2012 DC's. Thank you so much!

Reply ↓
Rasmus Burkal April 25, 2015 at 1:38 pm

Thanks for the article.

It helped. Had the same issue on different domains some, am mix of windows server 2008 and 2012 and some only windows server 2012.
Finely i fixed the problem..

Thanks, Rasmus

Reply ↓
Adam Stypulkowski April 29, 2015 at 7:55 am

Many Thanks – it worked perfect! Issue: Windows Server 2012 R2 (two Domain Controller).

Reply ↓
Kim July 30, 2015 at 3:26 am

Solved the issue without any problems.
Was two domain controllers, 2008 R2.
Thank you 🙂

Reply ↓
khayal August 17, 2015 at 10:03 am

Hi Jack, thx for this great guide, its help me. but i have one problem. all worked on virtual environment, but not work on Local Network. my 2 DC in Vcenter 5.5, on VM in Vcenter all work great. But in local PC which connected via switch This not work, Gpupdae /force not work(

Reply ↓
1. Jack Post authorMay 30, 2017 at 9:52 pm
  
  You have a typo in gpupdate /force
  
  Jack
  
  Reply ↓
Rene Sonnenschein-Flohr September 1, 2015 at 2:24 pm

Hi Jack.

THANKS a lot.. this helped me out! Now all of the DCs are replicating again! Very nice! 🙂

Regards Rene´

Reply ↓
Piyush Gohil October 6, 2015 at 4:43 am

Hello,
Thank You For Post The Solution. I Try To Many Options But Nothing To Solved And I Try To Read Your Post And Try So Solved My Problem So Again Thank You.

Thanks And Regards,
Piyush Gohil

Reply ↓
Dick October 22, 2015 at 9:43 pm

Great walk thru.

Used this for sysvol and worked. Had to think through the steps and tweak for a replication folder that wouldn't connect. Removing from the replication group didn't do anything, but this worked

If I didn't find this, think I would have to go back to zero with fresh install.

Reply ↓
Kelly November 4, 2015 at 1:45 pm

Excellent instructions. I used them and it works. 5 dc's here that needed their replication fixed. Thanks!

Reply ↓
Sander November 11, 2015 at 1:09 pm

It works perfect for me. But do i have to wait for the 2002 eventid before i can do the next step? In my testlab i have only wait for eventid 4602 and when i see this eventid i make a move to the next step and it works also for me.

Sorry for my bad english 😉

Reply ↓
RSM December 3, 2015 at 4:04 pm

Really nice post.. it helped me alot!!!

Reply ↓
AZ SysAdmin December 3, 2015 at 5:38 pm

Thank you! Thank you! Thank you! I have been hunting this issue for the longest time. Primarily due to the day to day interruptions. However, my physical DC is not replicating thanks to you.

Reply ↓
Martin Lopez December 26, 2015 at 5:32 pm

You Sir are my bloody hero!!! I was struggling with this for the whole day and had one DC out of synch and two others with no SYSVOL folders.

After following your steps to the letter and praying, all four DCs now have a happy SYSVOL synch between them. THANK YOU SO VERY, VERY MUCH!!!!

Reply ↓
James January 5, 2016 at 4:08 pm

Wow that was so easy. Nice write-up. Wish Microsoft could make write-ups like this.

Reply ↓
Simon January 5, 2016 at 7:37 pm

Mate ... you saved my freaking life and have certainly ensured that a high-profile project will come across the line on time. Worked perfectly to get 4 DCs syncing properly!!

Thank you *so* much.

Reply ↓
Bill January 21, 2016 at 7:30 am

I can't get past the repadmin command. I am getting the error DsBindWithCred failed with the status 1722. So I found an article that suggested to reboot the DC's. I was going to go back and reverse the ADEDIT but now the ms-DFSR - ENABLED is missing. WTF?!

UPDATE: After reboot of PDC – the ADSI Edit setting is back…
Also – for clarity – when you mention to change the ADSI settings on ALL DC’s, you mean to do it on the PDC that you are logged into…correct? ….inside the current ADSI Edit window? ...just checking

UPDATE2: after kicking myself for adding a '-' in the server name which was not needed - checking DNS verified that...all ran well. Thanks for listening to my venting. great article

Reply ↓
Pratik Patel February 3, 2016 at 2:49 pm

Thank you so much !!!
I have been tring to sort this out for months. I finally figured out that it was the SYSVOL Issue yesterday.

This guide has saved me so much time

Reply ↓
Erin March 2, 2016 at 4:34 pm

I couldn't have completed this without such an awesome guide. We had been having issues since some duplicate vm's were brought online with the same names and it pretty much broke all replication. I followed this to the letter and now replication is healthy. Thank you for posting it, it's people like yourself sharing knowledge that can make a huge difference for things you just don't see every day.

Reply ↓
Alexandru March 17, 2016 at 2:10 pm

You are the GURU!!! I spent weeks trying to solve this issue and your guide fixed me!!

Reply ↓
dude March 28, 2016 at 12:36 pm

looking for a while for the solution. You nailed it.
thanks a lot.

Reply ↓
HoBRoB April 14, 2016 at 1:03 pm

You saved me a lot of headache, thx a million.

Reply ↓
Adam April 28, 2016 at 3:12 am

This worked perfectly first time to get SYSVOL replication started in our new domain. Thank you so much.

Reply ↓
David Lean August 22, 2016 at 1:35 am

Thanks Jack, you are a champion.
This worked brilliantly for two new Win 2012R2 systems that had never synced (probably due to DNS issues)

Reply ↓
Dusty December 15, 2016 at 9:01 am

Thanks for taking the effort to make this, Jack! It must have taken you a lot of time and effort, and more than anything, initiative! People like you definitely make life easier for amateurs like me!

Reply ↓
Pingback: Migrando o Active Directory para uma nova versão do Windows Server | Eduardo Mozart
Merovingian January 11, 2017 at 4:55 am

Finally!! This has solved my issues!

Thank you very much!

Reply ↓
Pingback: Authenticate From Wrong Domain Controller | Share IT
Sven March 21, 2017 at 8:37 am

You have become my impromptu hero 🙂

Thanks for making it possible for a guy with little in-depth AD-experience to solve this onSite.

Reply ↓
Cenna May 23, 2017 at 10:41 pm

Thank you. Issue solved.

Reply ↓
Hitesh Kumar June 14, 2017 at 2:35 pm

Thank you... My issue got resolved.

Reply ↓
Corbett Enders June 29, 2017 at 2:29 pm

Thank you, this article continues to help many.

Reply ↓
Mahesh M July 23, 2017 at 7:55 am

Issue got Resolved..

Thanks for the update...

Reply ↓
William August 10, 2017 at 3:20 pm

A life-saver

Reply ↓
Teboho September 11, 2017 at 1:47 pm

Works great. Thank you.

Reply ↓
Chris Britton September 13, 2017 at 7:38 am

My God I spent days on this.

Thank you thank you thank you

Reply ↓
Julie Biggs September 27, 2017 at 8:24 am

Great guide. Fixed my sysvol replication problem. Many thanks

Reply ↓
Daniel Rozenzon July 5, 2018 at 7:49 am

Jack,

I have followed the article step by step and solved the DFSR issuses succesfully.
Thank you a lot for this valuable information!

Best regards,

Daniel

Reply ↓
Alan Kaplan July 14, 2018 at 9:05 am

Great article. Following these directions fixed my new 2016 domain controller FRS and missing SYSVOL issues. Thanks!

Reply ↓
Falk Lingner December 14, 2018 at 3:17 am

You are my hero!
I tried for weeks to solve this replication issue and thanks to your instructions everything is up and running again.

Reply ↓
Steve Cooper February 1, 2019 at 5:15 am

Thanks - this sorted out some problems I had! I didn't have your original symptoms, but I knew I had some old GPO still being applied when it said it wasn't, and the GPO status page was saying all SYSVOLs were Inaccessible.

Reply ↓
Carl Davis February 2, 2019 at 6:31 pm

Thank you …. saved my bacon. Great article

Reply ↓
Jake February 13, 2019 at 5:14 am

Solved my issue - thank you! I had to restart the DFS Replication service on the secondary DC's at the end. I'm so glad you create this article as Microsoft's fix for it doesn't have the relevant screenshots.

Reply ↓
Mario March 22, 2019 at 3:04 am

Nice Article!

Maybe you should change "wait a few minutes" to "wait an hour" (40 Minutes @ your site) 😉

Thanks a lot!

Reply ↓
1. Jack Post authorMarch 23, 2019 at 4:34 pm
  
  The amount of time will vary in nature depending on the environment, but good feedback for others 🙂
  
  Reply ↓
Eddie April 25, 2019 at 6:13 pm

Solve me issue for 10 domain controllers at several remote locations. Thanks a million!!

Reply ↓
Mark June 5, 2019 at 8:11 am

This article is still helping the community out after 5 years!
I spent a day troubleshooting SYSVOL replication issues, that was totally broken. Thanks to the time and efforts on your part, I fixed our problem following your detailed instructions.

Thanks!

Reply ↓
Lefteris Mourikis November 20, 2019 at 2:34 pm

Excellent article! Far more detailed and accurate than Microsoft's.

Thank you very much!

Reply ↓
JedimasterSA November 22, 2019 at 8:11 am

Helped me so much!!! Thanks you!!!!!!

Reply ↓
J January 29, 2020 at 8:14 am

Just wanted to say thank - perfect article fixing the problem of replciating between 2008r2 and Win2k19 server.

Reply ↓
AB May 5, 2020 at 6:49 am

Thank you for your article.
I had a sync issue between my 2 DC in my home lab.

Reply ↓
Davide Lorenzato November 3, 2020 at 6:12 am

You are the man!!!
Thank you very much Jack!
Finally this f*****g DC have a replica (2012 foundation -->2019)

Reply ↓
Jens V. December 17, 2020 at 4:10 am

Thank you!

Reply ↓
Chosebin January 23, 2021 at 7:59 pm

Wow, a solution well explained, and that worked at the first try! Thank you! 5***** Support

Reply ↓
Ghost July 14, 2021 at 9:31 am

Thanks a lot Jack, worked like a charm.
Good job

Reply ↓
Richard July 22, 2021 at 3:15 am

Thank you very much.
This happened to me on a fresh new Windows Domain with 2 Server 2019 DCs.
Was pulling my hair (or what's left of it) out and there are some really nasty "solutions" presented on the internet.
This was THE solution and by far the best instructions how to resolve it.

Reply ↓
1. Jack Post authorJuly 22, 2021 at 9:07 pm
  
  Appreciate you responding back this is still useful even in Server 2019! 🙂
  
  Jack
  
  Reply ↓
Mario March 24, 2022 at 9:14 am

Works on Server 2022 as well.

This is the first time I encountered this issue -- what causes it?

Mario

Reply ↓
1. Jack Post authorMarch 24, 2022 at 12:31 pm
  
  Appreciate you sharing the info. Unsure on what causes these items to get out of sync. Could be time, could be bad code, connectivity issues during sync, solar flare?
  
  Reply ↓
  1. Chris April 6, 2023 at 5:35 pm
    
    Here it was the former PDC, which was degraded ~3 years ago but obviously somehow stuck in the sysvol-sync. I guess broken MS code as it was shown with UUID in eventlog, but nowhere shown as sync partner anymore - means I had no chance to remove it.
    
    This one solved it though!
    
    Reply ↓
chris April 6, 2023 at 5:15 pm

Thx so much!
This article was golden (eventhough I adjusted it to do it from the SDC, as I moved the PDC already before noticing that the old PDC(now SDC) was broken on this.

So I followed your instructions adjusted to SDC and it worked. After a short time, I finally got sysvol synced to my PDC.

Regards!

Reply ↓