Non-authoritative SYSVOL restore (DFS-R)

 

Last time, I wrote an article about Non-authoritative SYSVOL restore (FRS) which was based on File Replication Service for SYSVOL. Now, I will show you a procedure for non-authoritative SYSVOL restore based on DFS Replication (DFS-R).

So, let’s look at the procedure for DFS-R.

When you are working in Active Directory environment you may fall into this problem, especially in case where you have many Domain Controllers. Sometimes you may figure out that one or more Domain Controllers are out of date with SYSVOL replication.

Each Domain Controller has its own folder where GPOs and scripts are saved. This folder is located under %WINDIR%SYSVOLdomain (by default, if you changed that location during DC promotion, you need to refer to your own location).

There are 2 folders:

  • Policies where Group Policies are saved (%WINDIR%SYSVOLdomainPolicies)
  • Scripts where logon scripts or other files are saved (%WINDIR%SYSVOLdomainScripts shared as NETLOGON)

If a DC does not replicate SYSVOL you can see that some Group Policies (GPOs) or scripts are not available on DC(s) in SYSVOLdomain folder on particular DC. Another symptom may be that all GPOs are in place but they are not updated.

When you notice one of these behaviors, you would need to do non-authoritative SYSVOL restore which re-deploys SYSVOL data from working Domain Controller (holding PDC Emulator operations master role).

How to be sure if you need non-authoritative SYSVOL restore? There is no simple answer because that depends on the size of your Active Directory and number of Domain Controllers.

When we can decide to start this kind of retore ?

  • one DC out of couple does not replicate SYSVOL
  • a few DCs out of many do not replicate SYSVOL
  • more than few but less than 50% of them do not replicate SYSVOL

above examples are typical scenarios for non-authoritative SYSVOL restore.

Let’s see how you to do that.

First of all, you need to find out which DC or DCs does/do not replicate SYSVOL. Then you have to start SYSVOL restore.

When you see an empty SYSVOL, this may suggest that Domain Controller initialization where not finished after server was promoted. Active Directory database was replicated but SYSVOL was not. In this case, you can simply perform non-authoritative restore and SYSVOL should be replicated.

Empty SYSVOL folder

Empty SYSVOL folder

Another case is when DC, is not up to date with SYSVOL. Some policies are missing and non-authoritative SYSVOL restore would be helpful

Missing Group Policies under SYSVOL

Missing Group Policies under SYSVOL

When you log on to Domain Controller with PDC Emulator operation master role, you should see that there are more policies than on those faulty Domain Controllers

All Group Policies on DC with PDC Emulator role

All Group Policies on DC with PDC Emulator role

So, you can see that those Domain Controllers need SYSVOL restore to have all data up-to-date.

OK, let’s start non-authoritative restore of SYSVOL. This procedure is a little bit different than for FRS, you do not set up anything in registry. All changes (which can be compared to D2 BurFlags value) are done with ADSI Editor console. You need to run adsiedit.msc from Domain Controller on which you want to initiate non-authoritative SYSVOL restore. Type in run box

adsiedit.msc
Running ADSI Editor

Running ADSI Editor

Connect to domain partition (Default Naming Context). Click right mouse button (RMB) on root node in the console and select “Connect to

Connecting to Default Naming Context

Connecting to Default Naming Context

select a well known Naming Context and choose “Default Naming Context

Selecting Naming Context

Selecting Naming Context

Expand below location bt clicking on each node within a console

Default Naming Context -> DC=domain,DC=local -> OU=Domain Controllers -> CN=Domain Controller name -> CN=DFSR-LocalSettings -> Domain System Volume

where DC=domain,DC=local is a distinguished name of your domain and CN=Domain Controller name is DC name on which you want to initiate non-authoritative SYSVOL restore.

Searching SYSVOL subscription node

Searching SYSVOL subscription node

and select “CN=SYSVOL Subscription” entry by RMB in the right pane, choose “Properties

Editing SYSVOL subscription entry

Editing SYSVOL subscription entry

In the “Attributes Editor” windows, search for msDFSR-Enable attribute and edit it

msDFSR-Enabled attribute edition

msDFSR-Enabled attribute edition

Change its state from TRUE to FALSE and accept the change

Modification of msDFSR-Enabled attribute

Modification of msDFSR-Enabled attribute

and accept changes to be applied (do not close window, you will use it later)

Accept attributes changes

Accept attributes changes

I would suggest to remove all content from SYSVOL folders before starting non-authoritative restore:

  • %WINDIR%SYSVOLdomainPolicies
  • %WINDIR%SYSVOLdomainScripts

Note! (by default, if you changed SYSVOL location during DC promotion, you need to refer to your own location)

Now, you need to start Active Directory replication in a domain. Start elevated command prompt

Running elevated command prompt

Running elevated command prompt

and type a command to initiate AD replication (you need to have at leatd domain administrator’s privileges) and wait for its end

repadmin /syncall /AdP
Replicating Active Directory

Replicating Active Directory

and run dfsrdiag command to synchronize with the global information store

dfsrdiag PollAD
Sync with the global information store

Sync with the global information store

Note! When you ran dfsrdiag command and it was not recognized, you need to install DFS Management Tools from features!

Adding DFS Management Tools feature

Adding DFS Management Tools feature

Please check DFS Replication event log, if you can see event ID 4114 which indicates that SYSVOL is no longer replicated

Event log review

Event log review

OK, let’s set up msDFSR-Enabled attribute to TRUE state and accept changes (use that previous window, you haven’t closed)

Changing msDFSR-Enabled attribute back to TRUE state

Changing msDFSR-Enabled attribute back to TRUE state

and click OK to accept changes

Accepting attribute changes

Accepting attribute changes

again, start Active Directory replication

repadmin /syncall /AdP
Replicating Active Directory

Replicating Active Directory

run dfsrdiag command one more time to synchronize with the global information store

dfsrdiag PollAD
Sync with the global information store

Sync with the global information store

go back to DFS Replication event log and check if you can see these two event IDs:

  • 4614
  • 4604
4614 event ID

4614 event ID

4604 event ID

4604 event ID

go to %WINDIR%SYSVOLdomainPolicies and check if data was replicated. You should see all Group Policies and scripts there

All Group Policies on DC with PDC Emulator role

All Group Policies on DC after non-authoritative SYSVOL restore

and go to one more location, %WINDIR%SYSVOLdomainScripts to check if scripts and other files from NETLOGON share were replicated

All scripts on DC where non-authoritative SYSVOL has been done

All scripts on DC where non-authoritative SYSVOL has been done

That’s all! Everything you need to do is to repeat all those steps on each Domain Controller which does not replicate SYSVOL volume.

Done!

Next part >>>

Author: Krzysztof Pytko

Facebooktwittergoogle_plusredditpinterestlinkedinmail

21 responses to “Non-authoritative SYSVOL restore (DFS-R)”

  1. Darrelle Alexander says :

    Not sure if you still monitor this, but what about if Local Settings does not exist on the server you want to perform the non-authoritative restore on?

     
  2. Shu says :

    Thanks for your post, I have solve my misery.

     
  3. Jimmy says :

    Fantastic article, you saved my arse!!!

    One point to make, I had a Win2k8 R2 DC that failed big time (had all the FSMO roles too) and our most recent back up was several months old (don’t ask) So restoring the DC, before I could do any of the above, I had to reset the relationship with the 2nd DC (as per MS article KB288167) Once I had the computer account reset, I could then perform the above steps.

    I also noted I had to run the “repadmin /syncall /AdP” command from the good DC, as the “P” parameter in that, pushes the changes out. Otherwise, everything else was spot on!

    Thanks heaps!

     
  4. Mdavid says :

    Hi, I am currently trying to sort through a problem with these same symptoms. However, I don’t have a Domain System Volume container under the Domain Controllers, instead we just have a hex value for other shares that are currently being replicated. Any ideas?

     
  5. Joel says :

    Thanks for your post!
    But not work for me.

    Event 4614 ok, but not event 4604 and data not replicated.

    Windows 2012, two servers.
    Can you help me?

     
    • kpytko says :

      Hello,

      is this case still valid? Did it work for you now?

      Regards,
      Krzysztof

       
      • Nopla says :

        I have got exactly the same problem. Du you have any idea?

        > Event 4614 ok, but not event 4604 and data not replicated.

        Windows Server 2008 R2, 2 Servers

        Thank you!

         
        • kpytko says :

          Please check if connection between those 2 DCs are not broken and you are able to communicate.
          Additionally, please check your SYSVOL size and replication time interval.In case when SYSVOL is big, replication, may take a while.
          How much time has left from your SYSVOL restore?

          Regards,
          Krzysztof

           
          • Nopla says :

            Thanks for your reply!

            > Please check if connection between those 2 DCs are not broken > and you are able to communicate.
            The two DCs kann reach each other via PING.

            > How much time has left from your SYSVOL restore?
            The SYSVOL Restore ist more then one hour ago.

            Could it be that both Servers are awaiting the first replication?

             
          • iSiek says :

            If your Domain Controllers can ping, that not means they can communicate each other 🙂
            To replicate SYSVOL over DFS-R RPC dynamic port range is in use. Starting from Windows Server 2008 default pool is in range TCP 49152-65535. You need to be sure that servers can listen and use those ports.

            One hour should be enough to finish replication of SYSVOL in smaller environments but it looks like this is not working. Please ensure if you did that on proper DC. If so, please try to repeat the process exactly step-by-step and ensure if you removed old SYSVOL content on a broken Domain Controller. Check then once again if SYSVOL was replicated.

            Did you see any errors in server’s event log?

            Regards,
            Krzysztof

             
        • Abhay says :

          Remove all policies from misbehaving server using same mode option while booting up and then try..

           
        • Can says :

          did u fix it ?

           
  6. Nopla says :

    Thank you for your Post!

    I have two (stupid?) questions:
    I have two Domain Controllers (PDC,SDC). On the Second DC (SDC) the Sysvol is not up to date.

    – On wich DC i have to set “msDFSR-Enabled = TRUE”? On the “good” one (PDC) or on the “bad” one (SDC)?
    – I have to remove the Content of SYSVO only on the “bad” DC before restore?

    Thank you!

     
    • kpytko says :

      Hello,

      thank you for reading my blog!

      Flag needs to be set up on the broken SYSVOL Domain Controller only and yes, before you’ll start, it’s good to clean up SYSVOL content on a broken “bad” DC. That’s all 🙂

      Regards,
      Krzysztof

       
  7. gjb says :

    excellent article. helped me understand and sort a long-outstanding issue.

     
  8. Thompson says :

    Worked for me, thanks for the post. MS article on this is very useless.
    I had to run repadmin /syncall /AdP and dfsrdiag PollAD twice before I got the 4114 event ID come up.

     

Leave a Reply

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