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

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:

gpupdate - processing of group policy failed - registry-based policy settings

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

  1. Logon to your primary DC
  2. Stop the DFS Replication service
    1. Click on the Start menu, select Administrative Tools, and then click ServicesServices
    2. In the Name column, right-click DFS Replication or Netlogon, and then click Stop
  3. Open up ADSI Edit
    Server Manager - ADSI Edit
  4. Open up the Default naming context
    ADSI Edit - Connection Settings - Default naming context
  5. 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>
      ADSI Edit - Default Naming Context - Domain Controllers - DC01 - DFSR-LocalSettings - Domain System Volume
  6. Change the following attributes to the following values
    1. msDFSR-Enabled=FALSE
      msDFSR-options=1
      ADSI Edit - Default Naming Context - Domain Controllers - DC01 - DFSR-LocalSettings - Domain System Volume - msDFSR-Enabled - False
      ADSI Edit - Default Naming Context - Domain Controllers - DC01 - DFSR-LocalSettings - Domain System Volume - msDFSR-Options - 1
      Both values applied
      ADSI Edit - Default Naming Context - Domain Controllers - DC01 - DFSR-LocalSettings - Domain System Volume - msDFSR-Options - msDFSR-Enabled

      1. Note: If you cannot see msDFSR-options, uncheck Show only attributes that have values
        ADSI Edit - Default Naming Context - Domain Controllers - DC01 - DFSR-LocalSettings - Domain System Volume - Show only attributes that have values
  7. On the ALL other DCs, change the msDFSR-Enabled attribute to False
    ADSI Edit - Default Naming Context - Domain Controllers - DC01 - DFSR-LocalSettings - Domain System Volume - msDFSR-Enabled - False
  8. Force Active Directory replication throughout the domain (ensure all sync resposnes terminate with no errors).
    1. repadmin /syncall primary_dc_name /APed
      repadmin -syncall -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)
  9. Start the DFSR service back up on the authoritive DC
    1. Click on the Start menu, select Administrative Tools, and then click Services
      Services
    2. In the Name column, right-click DFS Replication or Netlogon, and then click Start
  10. Open up event viewer and navigate to Applications and Services Logs -> DFS Replication.  Verify you see Event ID 4114.
    Event Viewer - Applications and Services Logs - DFS Replication - Event 4114
  11. Navigate back to the following in ADSI
      1. CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<the server name to replicate from>,OU=Domain Controllers,DC=<domain>
        ADSI Edit - Default Naming Context - Domain Controllers - DC01 - DFSR-LocalSettings - Domain System Volume
  12. Set the value of msDFSR-Enabled to TRUE
    ADSI Edit - Default Naming Context - Domain Controllers - DC01 - DFSR-LocalSettings - Domain System Volume - msDFSR-Enabled - True
  13. 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.
  14. Force Active Directory replication throughout the domain
    1. repadmin /syncall primary_dc_name /APed
      repadmin -syncall -aped
  15. Wait a few minutes and you should see Event ID 2002 and 4602
    Event Viewer - Applications and Services Logs - DFS Replication - Event 4602 - Event 2002
  16. Navigate back to each of your secondary DCs and change the value of msDFSR-Enabled to TRUE
    ADSI Edit - Default Naming Context - Domain Controllers - DC01 - DFSR-LocalSettings - Domain System Volume - msDFSR-Enabled - True
  17. 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
  18. Verify you see Event ID 2002 and 4602 on each of the secondary DCs
    Event Viewer - Applications and Services Logs - DFS Replication - Event 4602 - Event 2002

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.

gpupdate - success

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

  1. Alex

    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 author

      Thanks Alex,

      I have added in the additional steps to stop/start the DFS Replication service per the Microsoft article.

      Jack

      Reply
  2. Pingback: GPupdate fails to run on cliens after DFRS replicated DC’s experience a dirty shutdown | syshead

  3. Vladislav Artukov

    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
  4. Yves

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

        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 author

          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
  5. Jon

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

    Reply
  6. Rasmus Burkal

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

    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
  8. Rene Sonnenschein-Flohr

    Hi Jack.

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

    Regards Rene´

    Reply
  9. Piyush Gohil

    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
  10. Dick

    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
  11. Sander

    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
  12. AZ SysAdmin

    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
  13. Martin Lopez

    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
  14. Simon

    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
  15. Bill

    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
  16. Pratik Patel

    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
  17. Erin

    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
  18. David Lean

    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
  19. Dusty

    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
  20. Pingback: Migrando o Active Directory para uma nova versão do Windows Server | Eduardo Mozart

  21. Pingback: Authenticate From Wrong Domain Controller | Share IT

  22. Sven

    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

Leave a Reply

Your email address will not be published. Required fields are marked *