Article ID: 2958414 - View products that this article applies to.
You may encounter a situation in which SYSVOL and Netlogon shares are not shared on a domain controller. The following additional symptoms or conditions may also apply:
Domain controllers without SYSVOL shared cannot replicate inbound because of upstream (source) domain controllers being in an error state. Frequently (but not limited to), the upstream servers have stopped replication because of a dirty shutdown (event ID 2213). The event message is as follows:
Event Type: Warning
What follows are recommended methods for troubleshooting and resolving missing SYSVOL and Netlogon shares on domain controllers that replicate by using the DFS Replication service.
The process, detailed in KB article 2218556
(http://vkbexternal.partners.extranet.microsoft.com/VKBWebService/ViewContent.aspx?;%5banySimpleType%5d;2218556)"How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for FRS)," reinitializes DFS Replication if SYSVOL is not shared on domain controllers. This is unnecessary in most cases, and it may cause data loss if done incorrectly. It also prevents determining the cause of the issue and averting future occurrences of the issue.
What follows are general steps to investigate the missing shares. Determine if the problem is caused by a one-time occurrence, or if the upstream domain controller(s) cannot support replication by using DFS Replication.
Deleting the DFS Replication database from the volume should not be required and is discouraged. Deleting the database causes DFS Replication to consider all local data on the server to be nonauthoritative. By letting DFS Replication recover the database gracefully (as instructed in the 2213 event), the last writer will still win any conflicting versions of SYSVOL data.
Step 1 - Evaluate the state of DFS Replication on all domain controllersEvaluate how many domain controllers are not sharing SYSVOL, have recently logged an Error event, and are in an "error" state. To do this, follow these steps.
Check for the SYSVOL share
You may manually check whether SYSVOL is shared or you can run the following command to inspect each domain controller by using the net view command:
For /f %i IN ('dsquery server -o rdn') do @echo %i && @(net view \\%i | find "SYSVOL") & echo
Check DFS Replication state
To check DFS Replication's state on domain controllers, you may query WMI. You can query all domain controllers in the domain for the SYSVOL Share replicated folder by using WMI as follows:
For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state
The "state" values can be any of the following:
0 = Uninitialized
1 = Initialized
2 = Initial Sync
3 = Auto Recovery
4 = Normal
5 = In Error
Note Depending on a domain controller's condition, it may fail to report a state value and indicate "No Instance(s) Available."
Check Event logs for recent errors or warnings
If any domain controllers do not report the "SYSVOL Share" replicated folder as being in a state "4" (normal), check the event log of those domain controller(s) to evaluate their condition. Review each domain controller for recent errors or warnings in the DFS Replication event log, such as the warning event ID 2213, which indicates that DFS Replication is currently paused.
Check the Content Freshness configuration
Determine whether DFS Replication triggered content freshness protection on the affected domain controllers. Content Freshness is enabled on Windows Server 2012 (and later versions) domain controllers by default, but may also be manually enabled on Windows Server 2008 and 2008 R2 servers.
To evaluate if content freshness is enabled, the MaxOfflineTimeInDays setting will be set to 60. If content freshness is disabled, MaxOfflineTimeInDays will be set to 0. To check MaxOfflineTimeInDays, run the following command:
wmic.exe /node:%computername% /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays
To query all domain controllers in the domain, run the following command:
For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays
For each domain controller enabled for content freshness, evaluate if DFS Replication has logged an event ID 4012 that indicates replication of the folder has stopped because replication has failed for longer than the MaxOfflineTimeInDays parameter.
Step 2 - Prepare the domain controllers that are in an error stateInstall appropriate updates
For any domain controllers running Windows Server 2008 or 2008 R2, first install DFS Replication updates to prevent data loss and to fix known issues. It is a best practice to use the latest version of DFS Replication. The latest version of DFS Replication is discussed in article 968429
Back up SYSVOL data
Perform a backup of SYSVOL data (if present) on each domain controller. Backups may be a simple file copy of the SYSVOL contents to a safe location or, it may be a backup that uses backup software.
Depending on the situation, policy files could be moved to "PreExisting" or "Conflict and Deleted." "PreExisting" and "Conflict and Deleted" contents will be purged if initial synchronization is performed multiple times on a server. Back up data in these locations to avoid data loss.
Step 3 - Recover DFS Replication on the domain controllers in the error stateBased on the number of domain controllers in the domain, select the appropriate method to recover the DFS Replication service.
For environments that have two domain controllersDetermine whether a dirty shutdown was detected (event ID 2213) on either domain controller. You may find the second domain controller is waiting to complete initialization of SYSVOL, This is because after promotion, it will have logged a 4614 event that indicates that DFS Replication is waiting to perform initial replication, and it will not have logged a 4604 event signaling that DFS Replication has initialized SYSVOL.
If content freshness is enabled on both domain controllers
If the second domain controller is waiting to perform initial synchronization (event 4614 logged without the 4604 anti-event), follow the section of article 2218556
(http://vkbexternal.partners.extranet.microsoft.com/VKBWebService/ViewContent.aspx?;%5banySimpleType%5d;2218556)to set the first domain controller as authoritative. You do not have to configure the second domain controller as nonauthoritative, because it is already waiting to perform initial synchronization.
Or, if the second domain controller is healthy and SYSVOL is shared, perform the following steps:
If content freshness is not enabled or triggered on both domain controllers
If the first domain controller is in the event ID 2213 state and the second domain controller has never completed initialization after it was promoted and content freshness has not been triggered, perform the following steps:
Or, if the first domain controller is in the 2213 state and the second domain controller is healthy (SYSVOL is shared), run the ResumeReplication WMI method on the first domain controller. It will log event ID 2214 at the completion of dirty shutdown recovery.
For environments that have three or more domain controllersDetermine whether a dirty shutdown was detected and whether DFS Replication is paused on any domain controllers (event ID 2213). You may find a domain controller is waiting to complete initialization of SYSVOL after promotion. It will have logged a 4614 event that indicates that DFS Replication is waiting to perform initial replication, and it will not have logged a 4604 event signaling that DFS Replication has initialized SYSVOL.
If content freshness is enabled and there are three or more domain controllers in the domain
Content freshness protection will log an event ID 4012 that indicates that replication has stopped because replication on the folder has failed for longer than the MaxOfflineTimeInDays parameter. You must follow the instructions in article 2218556
If all domain controllers have logged the 4012 event and their "state" is "5," then follow the instructions in article 2218556
Or, if one or more domain controllers are blocking replication because of content freshness, they each must be non-authoritatively recovered. To do this, follow these steps:
If content freshness is not enabled or triggered and there are three or more domain controllers in the domain
If content freshness protection was not triggered, run the ResumeReplication WMI method on the affected domain controllers. You must be aware of the replication topology, and you must "fan out" from a healthy domain controller by selecting direct partners of it, then recovering further downstream domain controllers, and so on. After replication is resumed, DFS Replication will log events 2212, 2218, and then 2214 (indicating that DFS Replication initialized the SYSVOL replicated folder).
Preventing future occurrences of the issueCheck whether the Application and System event logs are frequently reporting ESENT database recovery operations, disk performance problems, or both. These typically coincide with unexpected shutdowns of the system, with DFS Replication not stopping gracefully, or disk subsystem failures. Consider updating the system's drivers, installing appropriate updates to the disk subsystem, or contacting the system's hardware manufacturer to investigate further. You may also contact Microsoft Customer Support Services to help evaluate the system's health and DFS Replication behavior.
The Service Control Manager (SCM) uses the default time-out time of 20 seconds for stopping a service. In some complex DFS Replication implementations, this time-out value may be too short, and DFS Replication stops before the appropriate database is closed. At service restart, DFS Replication detects this condition, and then performs the database recovery. WaitToKillServiceTimeout may be used to grant DFS Replication more time to commit changes to the database during shutdown. For more information, go to article 977518
After you have restored DFS Replication of SYSVOL, DFS Replication health must be carefully monitored in the environment to prevent this scenario. Regular review of DFS Replication event logs, collecting of DFS Replication health reports, and collecting of replication state (by using the WMI query in the "Check DFS Replication state" section under "Step 1 - Evaluate the state of DFS Replication on all domain controllers" in this article) are recommended.
DFSR Event Messages Reference
Article ID: 2958414 - Last Review: May 23, 2014 - Revision: 2.0