Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

14 Responses to “(2014-08-01) Fixing AD/SYSVOL Replication And Reconnecting A Disconnected AD Domain (Part 6)”

  1. […] (2014-07-30) Fixing AD/SYSVOL Replication And Reconnecting A Disconnected AD Domain (Part 4) (2014-08-01) Fixing AD/SYSVOL Replication And Reconnecting A Disconnected AD Domain (Part 6) […]


  2. […] « (2014-08-01) Fixing AD/SYSVOL Replication And Reconnecting A Disconnected AD Domain (Part 6) […]


  3. Jerome said

    I think you totally mix and match the code on this page none of the pasted script correspond with the description 😦

    Nice work anyway


    • Jorge said

      Do not understand what you mean. Can you please provide details?


      • Jakub Kamenc said


        Jerome is right.

        The PS codes (as text) don’t not correspond to the codes presented on the screenshots.

        For example, for updating “CN=DFSR-LocalSettings” object you used “Set-ADObject” cmdlet (screenshot), but “New-ADObject” was presented in the text code area.

        Beside this small mistake, the article is great – thank you.


        • Jorge said

          the code is right as you have to recreate the objects because undelete is not possible due to the special attribute value I mention.
          I think I created the object first (shown in the code, but in screen dump) and then updated it (not shown in the code, but shown in the screen dump)


  4. Jerome said

    The command :

    New-ADObject -Instance $templateDomainSystemVolume -name “Domain System Volume”

    Is not working 😦


  5. T. Fieg said

    This description worked perfect in our case!

    The DFS-R-LocalSettings object (including everything below) was missing for one of our Domain Controller preventing it from replicating SYSVOL content for quite a while.

    That object could be created manually, however for creation of both CN=Domain System Volume and CN=SYSVOL Subscription objects we followed the steps shown in Figure 3 & 4. After that we’ve set the msDFSR-Enabled attribute in the properties of CN=SYSVOL Subscription to FALSE state and restarted DFSR service. In DFSR eventlog ID 4114 was shown; then msDFSR-Enabled attribute was modified back to TRUE state followed by another restart of DFSR service.

    Then running repadmin /syncall /AdP in administrative command shell and very quickly we could see the SYSVOL directory getting updated with missing information. This was a very straight forward fix!


  6. Adam said

    Hello, is it possilbe to fix these record if we have two DCs and both are missing these values? (I migrated from Samba to Windows). Thanks 🙂


  7. Marti_the_g said

    Thanks a bunch, your code was exactly what I needed. One of my DCs lost the setting and DFSR snapin reported it as missing. After seeting it and refreshing dfsr shows the DC again. Now I can do an non authoritative restore of sysvol.


  8. Henric Appelgren said

    Six years later and this is still a saving grace! Thanks alot1


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: