<

Active Directory DFSR Sysvol - Authoritative and Non Authoritative Restore Sequence

Published on
31,261 Points
11,861 Views
14 Endorsements
Last Modified:
Editors:
Approved
Mahesh
Freelancer, IT Consultant experienced on Microsoft server, AD and Messaging projects
This article explains DFSR Sysvol restoration process. The process originally explained in below MS KB article https://support.microsoft.com/en-in/help/2218556.
However they made is very confusing. Hence putting here in accurate way to get clear understanding of DFSR restoration process.

Active Directory DFSR Sysvol is very robust Sysvol replication engine.

It has number of benefits over conventional FRS Sysvol.

Check below article for more information

http://blogs.technet.com/b/askds/archive/2010/04/22/the-case-for-migrating-sysvol-to-dfsr.aspx


The major benefit is, DFSR has a self-healing system for problems like database corruption or journal wraps. However sometimes due to DNS problems, replication latencies, network problems, Sysvol might stop replicating on a specific domain controller. You might see event ID 4012 event ID on a domain controller in DFSR event logs.


DFSR0.jpg


In that case, you need to restore \ refresh Sysvol folder contents authoritatively \ non authoritatively depending upon the situation.


I have seen many Active Directory Distributed File System Replication (DFSR) Sysvol restoration articles, but most of the articles do not mention correct sequence \ restoration steps, especially for DFSR Sysvol Authoritative Restore. This process is explained in http://support.microsoft.com/kb/2218556.


However, the Microsoft article is not clear when to stop and start the DFSR service and on which server. This can lead to confusion, misunderstanding and even doing it wrong.


Hence I have set up a test lab and tried various sequences and found the correct sequence.


From Windows 2008 Domain Controllers and above domain functional levels, you can have the Active Directory Sysvol replicated with DFSR that is more robust and reliable than FRS replication technology.


There are TWO types of DFSR Sysvol restores are available:

  1. DFSR Sysvol Authoritative Restore
  2. DFSR Sysvol Non-Authoritative Restore


DFSR Sysvol Authoritative restore

If your DFSR replicated Sysvol is not replicating on any domain controller in an entire domain, it's broken and got corrupted on all domain controllers (very rare situation), in that case, you need DFSR Sysvol authoritative restore.

This restore should be done on primary domain control (PDC) master server because the PDC is the server where the most recent Sysvol data resides.

 

High-level approach for this restore:


  1. Disable DFSR Sysvol replication on all DCs including PDC master server
  2. Then you should initiate DFSR Sysvol authoritative restore on PDC
  3. Once authoritative restore gets completed successfully, then you should initiate nonauthoritative restore of DFSR Sysvol on other ADC servers one by one.


Steps to perform an authoritative restore of DFSR SYSVOL (like "D4" for FRS)


Step 1

On the PDC master server which is considered having most up to date Sysvol copy), open ADSIEDIT.MSC tool, load the domain directory partition and open properties of the following DN and edit two attributes mentioned below:


CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=PDC,OU=Domain Controllers,DC=domain,DC=com
(Replace PDC with the name of your primary DC server)



msDFSR-Enabled= FALSE
msDFSR-options= 1


DFSR1.jpg


Setting up msDFSR-Options to 1 makes that server authoritative for DFSR Sysvol replicated folder (Primary Copy).


Step 2

Navigate to the following DN and edit single attribute on all other domain controllers one by one in that domain:


CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=ADC,OU=Domain Controllers,DC=domain,DC=com
(Replace ADC with other additional DCs one by one)

msDFSR-Enabled= FALSE


DFSR2.jpg


Step 3

Force Active Directory replication throughout the domain. You can run repadmin /syncall command on all DCs OR you can go through all of your AD sites and services manually for all DCs.


Step 4

Run the following command from an elevated command prompt on the PDC (the same server that you set as authoritative) and all other ADC servers


DFSRDIAG POLLAD


This command will poll configuration changes in AD immediately for that DC wrt DFSR.

Note -  "DFSRDIAG" utility is installed by default when you promote 2008 / 2008 R2 / 2012 servers to domain controllers. If you have 2012 R2 / 2016 domain controllers, "Dfsrdiag" tool is not getting installed by default when you promote them to domain controllers. You need to install DFS management tools from server manager or from PowerShell cmdlet (Install-WindowsFeature RSAT-DFS-Mgmt-Con )


Step 5

Stop the DFSR service on all domain controllers including the PDC (the server where you want to restore DFSR Sysvol authoritatively). This step is required so that DC will stop communicating with DFSR Sysvol database and cannot make changes or modifications to DFSR configuration. This step is not given in original MS KB article.


Step 6

Start the DFSR service on PDC (the server where you want to restore DFSR Sysvol authoritatively) ONLY.


On the same server, You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated on PDC because "msDFSR-Enabled value is still set to FALSE".


DFSR3.jpg


Step 7

On PDC go to the Properties of same DN from Step 1 and set:


msDFSR-Enabled= TRUE


This will ensure that this PDC server is the primary member for DFSR replicated folder. This will also resume DFSR replication on the PDC server only; DFSR replication on other DCs is still disabled.


This step also resets msDFSR-options to 0 from 1 automatically (We have set it to 1 in 1st step on PDC) which means DFSR Sysvol authoritative restore is attempted on this DC (PDC)


Note that while you will have enabled DFSR replication on this DC (PDC) authoritatively, you must ensure that the DFSR service has been stopped on other DCs and that DFSR replication is in the disabled state. Otherwise, it leads to DFSR database conflicts and issues. I have seen many DFSR restoration articles, however, they did not mention this precaution.


DFSR4.jpg


Step 8

Force Active Directory replication throughout the domain. You can run the repadmin /syncall command on all DCs OR you can do that through the AD sites and services manually for all DCs.


Step 9

Run the following command from an elevated command prompt on the PDC:


DFSRDIAG POLLAD


This command will poll the configuration changes in AD immediately for that DC wrt DFSR. On the same server, you will see Event ID 4602 in the DFSR event log indicating SYSVOL has been initialized. That domain controller (PDC) has now done a “D4” of SYSVOL successfully. Open command prompt and type Net Share

 

Command Output should show Sysvol and Netlogon shares (Active Directory logon shares), it means Sysvol is fully initialized and designated as primary member for Sysvol replication


DFSR5.jpg


Step 10

Start the DFSR service on the other non-authoritative ADC servers one by one. On those servers, You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated on each of them. Starting DFSR service will enable these DCs to start accessing DFSR configuration database; however, still DFSR replication is not enabled.


DFSR3.jpg


Step 11

From Adsiedit.msc, go to the properties of same DN as Step 2 and edit single attribute on all other domain controllers one by one in that domain:



msDFSR-Enabled= TRUE
 


This step will enable DFSR replication across the domain controllers and they will start non-authoritatively restoring DFSR Sysvol


DFSR6.jpg


Step 12

Force Active Directory replication throughout the domain. You can run the repadmin /syncall command on all DCs OR you can do that through the AD sites and services manually for all DCs.


Step 13

Run the following command from an elevated command prompt on all ADC Servers (non-authoritative DCs) one by one:


DFSRDIAG POLLAD 


On the ADC servers, you will see Event ID 4604 in the DFSR event log indicating SYSVOL is now initialized and replicating correctly on each of them. These domain controllers have now done a “D2” of SYSVOL successfully. Open command prompt and type Net Share

 

Command Output should show Sysvol and Netlogon shares (Active Directory logon shares), it means Sysvol is fully initialized and synchronized with a primary replication partner


DFSR7.jpg 


DFSR Sysvol Non Authoritative restore


If your DFSR replicated Sysvol is not replicating on any specific domain controller apart from PDC master server, in that case, you need DFSR Sysvol Non-authoritative restore.


This restore should be done on problematic ADC server where you want to refresh Sysvol data from other healthy DC (Probably PDC) where Sysvol is healthy and replicating correctly.

High-level approach for this restore:


  1. Disable DFSR Sysvol replication on problematic ADC
  2. Then you should initiate DFSR Sysvol non-authoritative restore on that ADC


Steps to perform a non-authoritative restore of DFSR SYSVOL (like "D2" for FRS)


Step 1

On the Problematic ADC, open ADSIEDIT.MSC tool and go to following distinguished name (DN) value and edit below attribute:

 

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=ADC,OU=Domain Controllers,DC=domain,DC=com
(Replace ADC with your server hostname)

msDFSR-Enabled= FALSE


DFSR2.jpg


Step 2

Force Active Directory replication throughout the domain.


Step 3

Run the following command from an elevated command prompt on the same server that you set as non-authoritative:

DFSRDIAG POLLAD

On the same server, You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated.


DFSR3.jpg


Step 4

Restart DFSR service on the same server from an elevated command prompt or from services console.


Step 5

On the same DN from Step 1, set:

 

msDFSR-Enabled= TRUE


DFSR6.jpg


Step 6

Force Active Directory replication throughout the domain.


Step 7

Run the following command from an elevated command prompt on the same server that you set as non-authoritative:

DFSRDIAG POLLAD

On the same servers, You will see Event ID 4614 followed by 4604 in the DFSR event log indicating SYSVOL has been initialized successfully. That domain controller has now done a “D2” of SYSVOL. Now Open command prompt and type Net Share

Command Output should show Sysvol and Netlogon shares (Active Directory logon shares), it means Sysvol is fully initialized and synchronized with primary replication partner


DFSR8.jpg


DFSR7.jpg


Note - Sysvol and netlogon Initialization is controlled by SysvolReady 32 bit DWORD key located under HKLM\System\CurrentControlSet\Services\Netlogon\Parameters on each domain controller. For healthy Sysvol, this key value is set to 1 by default, as a result Sysvol and netlogon folders are shared and published with active directory.

If Sysvol initialization fails for any reason, the key value is set to 0 and both folders remain unshared and unpublished. Never change this key manually from 0 to 1 as doing so it may share Sysvol and netlogon but did not address and resolve actual problem. 


I have tested above process in a test lab on two Windows 2008 R2 Domain Controllers with Windows 2008 domain and forest functional level. 

The process remains unchanged for Windows 2012 / 2012 R2 and 2016 server editions


Any comments are welcome.


Please click Thumbs-Up below if you like the Article

14
Author:Mahesh
Ask questions about what you read
If you have a question about something within an article, you can receive help directly from the article author. Experts Exchange article authors are available to answer questions and further the discussion.
Get 7 days free