Authoritative SYSVOL restore (FRS)


In my previous article “Non-authoritative SYSVOL restore (FRS)” I showed you, how to do a non-authoritative restore of SYSVOL.

What if you have bigger mess on your Domain Controllers with SYSVOL?
What if the most of DCs do not replicate SYSVOL or its changes?

What can you do, if you want to restore SYSVOL from a backup and you prefer it as a replication source?  Then you have another option, authoritative SYSVOL restore.

Today, I will show you, how to do that.

But, first of all. What is the basic difference between non-authoritative and authoritative SYSVOL restore?

In the first case (non-authoritative) you only touch SYSVOL on one DC at the time. The rest of your Domain Controllers are running and sharing SYSVOL for users. Only this particular DC has disabled SYSVOL during non-authoritative restore procedure.

The second case (authoritative) is much more visible for users. All of Domain Controllers do not run and share SYSVOL where Group Policies and logon scripts are located. When you decide to do authoritative SYSVOL restore, you need to inform all administrators to not create/modify Group Policies during that time. All other domain services are running except access to SYSVOL. So, this action should be performed out of office business hours.

How to start authoritative SYSVOL restore? What do you need to do first?

You should identify which Domain Controller is holding PDC Emulator operation master role. As you know, one of its functions is to manage and maintain GPOs. When you create or modify existing GPO, it is done directly on this Domain Controller.

If you need to restore SYSVOL from backup, it should also be done directly on PDC Emulator operation master role holder, from which you will initiate authoritative SYSVOL restore.

So, let’s see, how we can do that.

Log on to PDC Emulator FSMO role holder. If you do not know, which Domain Controller holds this role, run in command-line/elevated command-line on any of your DCs

netdom query fsmo
Finding PDC Emulator role holder

Finding PDC Emulator role holder

and you’ll see which DC is holding this role.

When you are logged on on this Domain Controller, you need to evaluate how many DCs are in your domain. The most simple way to check that is using Microsoft DS tools on a DC. Type in command-line

dsquery server -name * -limit 0 | dsget server -dnsname | find /v "dnsname" | find /v "dsget" >c:dcslist.txt
Collecting all Domain Controllers in a domain

Collecting all Domain Controllers in a domain

after you ran this command, on your DC’s C-Drive, you should find a text file named dcslist.txt Check its content, there are all Domain Controllers for your domain

All Domain Controllers in a file

All Domain Controllers in a file

On all of those Domain Controllers, you have to stop File Replication Service before you will be able to initiate authoritative SYSVOL restore, type in command prompt

net stop ntfrs
Stopping File Replication Service

Stopping File Replication Service

When you are sure that all of Domain Controllers have stopped FRS service, you can start restore.

You need to run registry editor on your PDC Emulator operation master role holder

Executing registry editor

Executing registry editor

and go to BurFlags value location

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNtFrsParametersBackup/RestoreProcess at Startup
BurFlags value location

BurFlags value location

to be able to modify BurFlags value, double-click on it and put D4 (hexadecimal) as a value

Setting BurFlags value

Setting BurFlags value

This sets Domain Controller as an authoritative source for SYSVOL replication. All other DCs will pull SYSVOL content from this server.

Now, you have to start File Replication Service on PDC Emulator role holder DC. Type in command-line

net start ntfrs
Running File Replication Service

Running File Replication Service

Refresh (F5 key) registry editior and you should see that BurFlags value is reset to 0

BurFlags value reset

BurFlags value reset

Check File Replication Service event log and search event IDs

  • 13566
  • 13516

If both of them are available then authoritative restore is configured.

Now, you need to log on to the rest of Domain Controllers and set up D2 BurFlags value to initialize non-authoritative restore of SYSVOL from specified server.

BurFlags value should be changed in the same location as for the previous DC, but instead od D4 value you have to specify D2

Location of this value is

HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNtFrsParametersBackup/RestoreProcess at Startup
BurFlags value location

BurFlags value location

Double-click the value and set up D2 (hexadecimal)

Changing BurFlags value

Changing BurFlags value

Before you will start FRS service, I would suggest to delete content of these 2 folders

  • %WINDIR%SYSVOLdomainPolicies
  • %WINDIR%SYSVOLdomainScripts

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

Warning! When you set up D2 BurFlags value, you need to know that during restoration time, your DC is prevent to be a Domain Controller! So, you need to be careful in locations/Sites where you have only single DC or you are going for authentication over WAN-link!

Now, you need to run File Replication Service and wait a while for SYSVOL replication.

After you ran FRS service, you should notice that BurFlags entry was reset to 0

BurFlags value reset

BurFlags value reset

From time to time, refresh File Replication Service event log and check for event ID 13516

When you see this event ID that SYSVOL replication is finished and your Domain Controller is ready to share SYSVOL for users.

SYSVOL re-initialized

SYSVOL re-initialized

When you see event ID 13520 that means, you did not remove content of policies and scripts folders. Do not worry they were moved to another folder which may be removed after all

SYSVOL content moved

SYSVOL content moved

All you need to complete the authoritative SYSVOL restore is to log on to EVERY Domain Controller and perform D2 BurFlags set up

Information! Microsoft does not recommend doing more than 15 concurrent non-authoritative restores to prevent performance issues. Remember that when you are doing authoritative restore in bigger Active Directory environments!

And that’s all! You fixed your broken SYSVOL share.

<<< Previous part

Author: Krzysztof Pytko


10 responses to “Authoritative SYSVOL restore (FRS)”

  1. Marcinei says :

    Para Windows server 2012 siga o KB Microsoft para solução do problema de replicação da pasta Sysvol:
    Marcinei Rocha

  2. Igor says :

    Hi Buddy,
    Saved the day for me! keep up the grate work! 🙂

  3. Tom says :

    Must give you some props for this post. Very detailed explanation and fixed my issue. Thanks man

  4. Alex says :

    Thank you, it´s better to understand then Microsofts KB… 🙂

  5. Ceefus Jenkins says :

    Great job. I was banging my head against a wall for 2 hours before I found this and this fixed everything!

  6. David says :

    When you are done, do you need to change dfsr-options back to 0 or leave that at 1?


Leave a Reply

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