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.
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:
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.
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:
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:
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
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".
Step 7
On PDC go to the Properties of same DN from Step 1 and set:
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.
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:
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
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.
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:
This step will enable DFSR replication across the domain controllers and they will start non-authoritatively restoring DFSR Sysvol
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:
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
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.
Step 1
On the Problematic ADC, open ADSIEDIT.MSC tool and go to following distinguished name (DN) value and edit below attribute:
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:
On the same server, You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated.
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:
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:
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
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
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (17)
Commented:
Commented:
Author
Commented:I honor your comments
If you could please endorse the article...
Mahesh.
Commented:
I have couple of questions. If we are unsure that PDC has the clean copy of sysvol, What is the procedure in the authoritative restore?
Restore it from backup on all DCs/ at PDC and perform authoritative restore as on the Steps above?
My other question in Step 1. You set msDFSR-options= 1 and have not done anything for that after that, Is it staying as it is ?
Author
Commented:2. Ideally you should look for Sysvol contents (including policy folders) 1st if they are same across domain controllers and there are same number of GPOs exists
If you certain that current PDC did not have all contents of Sysvol but it might having on other DC, then you should promote that other DC as PDC, replicate the changes to all other DCs and on that DC initiate Sysvol authoritative restore
If Sysvol contents are missing on all domain controllers, then doing authoritative restore will not restore them
In that case you need to restore Sysvol contents from backup on PDC server only and need to attempt Sysvol authoritative restore on PDC followed by non authoritative restore on other DCs
This is good point and thanks for highlighting and will highlight in article...
When you do Sysvol authoritative restore, this bit is set to 0, it means Sysvol authoritative restore is attempted on that DC
For Other DCs this value remains <Not Set>
Thanks
Mahesh.
View More