Fixing Missing SYSVOL/Netlogon Shares in DFS Replication on Windows Server

Table of Contents

This document provides guidance on troubleshooting and resolving issues where the SYSVOL and Netlogon shares are not available on a Windows Server domain controller utilizing DFS Replication for SYSVOL. These shares are critical for domain functionality, hosting Group Policy Objects and logon scripts. Their absence can severely impact user logins and policy application within the domain.

Often, this problem manifests after a domain controller has been recently promoted or if there are existing domain controllers running older Windows versions in the environment. The core issue frequently stems from an upstream replication partner experiencing errors. Specifically, a dirty shutdown condition, often indicated by Event ID 2213 in the DFS Replication event log, on a source domain controller can halt inbound replication for others, leading to the shares not being created or populated correctly.

While it might seem intuitive, simply deleting the DFS Replication database from the volume is generally not recommended. This action forces DFS Replication to treat all local data as non-authoritative, which could lead to data loss. The preferred approach is to allow DFS Replication to perform a graceful recovery process, as outlined in the guidance associated with Event ID 2213. This method ensures that the last writer wins in case of conflicting data versions, preserving recent changes. The following steps provide a structured method to investigate and resolve the missing SYSVOL and Netlogon shares, focusing on identifying the root cause and facilitating a proper recovery of the DFS Replication service.

Symptoms¶

When the SYSVOL and Netlogon shares are missing on a domain controller, several related issues might become apparent within your Windows Server environment. The most direct symptom is the physical sysvol folder on the domain controller appearing empty or incomplete. Users may experience logon problems, and Group Policies might not apply correctly to computers and users authenticating against this specific domain controller.

Other common indicators include the affected domain controller having been recently added to the domain or promoted. The issue is particularly prevalent in environments where domain controllers run a mix of Windows Server versions, including those older than Windows Server 2012 R2, and where DFS Replication is the configured method for SYSVOL replication. Crucially, an upstream domain controller – one from which the affected server is supposed to receive replication updates – might be in an error state, preventing the successful synchronization of SYSVOL data. This error state is often the primary blocker for the creation and sharing of the required directories.

Cause¶

The fundamental reason domain controllers may fail to share SYSVOL and Netlogon is an inability to complete inbound replication of the SYSVOL Share replicated folder. This inability is typically a consequence of upstream (source) domain controllers being in an unhealthy or error state regarding DFS Replication. A very common scenario leading to this state is a dirty shutdown of the DFS Replication service, which is often logged with Event ID 2213.

When a dirty shutdown occurs on a replication partner, it signals that the DFS Replication database was not properly closed. This can happen due to unexpected server reboots, power failures, or the DFS Replication service not stopping gracefully. The service then enters a recovery mode, pausing replication until the database integrity is verified and restored. If the affected domain controller’s replication partner is stuck in this state, the downstream server waiting for updates will not receive the necessary SYSVOL data, preventing it from initializing or populating the shares.

Resolution¶

Resolving missing SYSVOL and Netlogon shares when using DFS Replication involves diagnosing the state of DFS Replication across all domain controllers and then systematically recovering those in an error state. The process avoids drastic measures like database deletion and instead focuses on allowing the DFS Replication service to heal itself or be guided back to a healthy state. Forcing an authoritative or non-authoritative synchronization, while a tool for SYSVOL recovery, is often unnecessary and should be used judiciously, especially the authoritative method, as it carries a risk of data loss if not performed with the most current data set.

The following steps outline a general investigative and resolution process. This approach helps determine if the problem is an isolated incident or indicative of broader replication issues within the domain, ensuring a more robust long-term solution. Proper resolution involves ensuring that all domain controllers can successfully replicate SYSVOL and maintain a healthy state.

Step 1 - Evaluate the State of DFS Replication on All Domain Controllers¶

The first crucial step is to understand the scope of the problem. You need to identify which domain controllers are missing the SYSVOL share and what the current state of the DFS Replication service is on each server, particularly focusing on any error conditions. This assessment provides a clear picture of the replication topology’s health and pinpoints the source of the issue.

Begin by checking for the SYSVOL and Netlogon shares on each domain controller. While you can manually check shares via File Explorer or net share on the server itself, a more efficient way for multiple servers is using the net view command remotely. You can script this check across all domain controllers found in Active Directory using a command like For /f %i IN ('dsquery server -o rdn') do @echo %i && @(net view \\\%i | find "SYSVOL") & echo. This command iterates through each domain controller name and attempts to list its shares, filtering for “SYSVOL”. If “SYSVOL” (or “NETLOGON”) is not listed for a domain controller, it’s marked as affected.

Next, determine the DFS Replication state for the SYSVOL Share replicated folder on each domain controller. The Windows Management Instrumentation (WMI) interface provides programmatic access to this information. You can query the DfsrReplicatedFolderInfo class in the root\microsoftdfs namespace to get the state of the SYSVOL replicated folder. A command like 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 executed from a command prompt on a domain controller will query all DCs in the domain.

The output of the WMI query will show a numerical state value for the ‘SYSVOL share’ replicated folder on each server. Understanding these states is vital:
- 0 = Uninitialized: The replicated folder is not yet configured or has been reset.
- 1 = Initialized: The configuration is loaded, but initial synchronization hasn’t occurred.
- 2 = Initial Sync: The server is performing the first full synchronization of the replicated folder’s contents.
- 3 = Auto Recovery: The service is recovering from a dirty shutdown.
- 4 = Normal: The replicated folder is healthy and actively replicating changes.
- 5 = In Error: The replicated folder has encountered a significant error and replication is stopped.

Any domain controller showing a state other than 4 (Normal), or failing to report a state (indicating communication issues or a severely unhealthy state), requires further investigation. Focus on those in state 5 or those that did not list the SYSVOL share.

Review the DFS Replication event log on the domain controllers identified as unhealthy or missing shares. Look for recent error or warning events. Event ID 2213 is a critical warning indicating DFS Replication detected a dirty shutdown and has paused replication for that replicated folder (SYSVOL in this case). Other events might point to connectivity issues, database corruption, or journaling problems. Identifying these specific events helps confirm the cause of the error state.

Finally, check the Content Freshness configuration on each domain controller, especially those running Windows Server 2012 and newer (where it’s enabled by default) or Windows Server 2008 R2 (where it could be enabled manually). Content Freshness is a protective measure that stops replication for a replicated folder if replication has failed for a period longer than the MaxOfflineTimeInDays setting (default 60 days). This prevents serving stale data. You can check this setting using WMI: wmic.exe /node:%computername% /namespace:\\\\root\\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays for the local server, or loop through all DCs as done previously: For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\\\root\\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays. A value of 60 indicates Content Freshness is enabled; 0 means it’s disabled. Look for Event ID 4012 on servers where Content Freshness is enabled, as this event confirms that replication was stopped due to exceeding the MaxOfflineTimeInDays threshold, often explaining why a server is stuck in state 5 (In Error).

Step 2 - Prepare the Domain Controllers That Are in an Error State¶

Before attempting to recover the DFS Replication service on affected domain controllers, it’s important to perform some preparatory steps. These steps help prevent data loss and ensure the recovery process is successful.

If any of the affected domain controllers are running Windows Server 2008 R2, ensure that the latest DFS Replication updates (hotfixes) are installed. There were known issues in earlier versions of DFS Replication that could lead to data loss or prevent proper recovery. Using the latest available hotfixes is a recommended best practice for stable DFS Replication operation. Consult relevant Microsoft documentation for the list of currently available updates for DFS technologies.

Critically, back up the SYSVOL data on each domain controller, especially on those identified as being in an error state or potentially having the most up-to-date data. This backup can be as simple as copying the contents of the SYSVOL folder (typically located at %SystemRoot%\SYSVOL) to a safe alternative location, or it can be a full system state backup using your standard backup software. During non-authoritative synchronization or initial sync, DFS Replication moves files that are not present on the replication partner into special folders like PreExisting or Conflict and Deleted within the SYSVOL path. While this mechanism is designed to prevent data loss during sync, these folders might be purged later, particularly if initial synchronization occurs multiple times. Having a separate backup ensures you can restore any necessary policy files or scripts that might end up in these temporary locations or are otherwise lost.

Step 3 - Recover DFS Replication on the Domain Controllers in the Error State¶

The method for recovering DFS Replication on domain controllers depends on the number of domain controllers in your environment and whether Content Freshness protection has been triggered. The goal is to bring the DFS Replication service and the SYSVOL replicated folder back into a healthy state (state 4 - Normal), allowing shares to be created and populated.

For environments that have two domain controllers¶

In a two-domain controller environment, diagnosing the source of the issue is relatively straightforward. Determine if a dirty shutdown (Event ID 2213) was detected on either domain controller. It’s common for one DC to be healthy while the other, perhaps recently promoted, is waiting for initial synchronization (Event ID 4614 logged, but not the completion Event ID 4604).

If Content Freshness is enabled on both domain controllers and one is waiting for initial synchronization (4614 without 4604), the domain controller that successfully logged Event ID 2213 and is in a paused state should be designated as the authoritative source for SYSVOL. The one waiting for initial sync doesn’t need to be explicitly set as non-authoritative because it’s already in a state of expecting data. You would typically follow the procedure to force an authoritative synchronization for DFSR-replicated SYSVOL. This involves setting a flag in ADSI Edit and resuming replication on the chosen authoritative server.

Alternatively, if one domain controller is healthy (SYSVOL shared, DFS-R state 4) and the other is in an error state or missing shares (possibly due to a 2213 or 4012 event), you should recover the unhealthy server non-authoritatively. First, back up all SYSVOL contents on the unhealthy domain controller. Compare its data with the healthy one; if it has newer policies, copy them to the healthy server before recovery to prevent them from being moved to PreExisting or Conflict and Deleted on the recovering server. Then, set the unhealthy domain controller’s membership for the SYSVOL replication group as disabled. This is done by modifying an object in Active Directory using tools like ADSI Edit, effectively marking it for non-authoritative recovery. Confirm Event ID 4114 is logged, indicating the membership is disabled. Force Active Directory replication if needed, then run dfsrdiag pollad on the target server to pick up the change. Re-enable the membership. The server will then perform an initial synchronization from its partner(s), logging Event ID 4614 upon starting and 4604 upon completion. After sync, check the PreExisting and Conflict and Deleted folders and restore any necessary files not replicated automatically.

If Content Freshness is not enabled or wasn’t triggered (no 4012 event) on both domain controllers, and one is in a 2213 state while the other hasn’t completed initial sync since promotion, the process is simpler. On the domain controller that logged the 2213 event, run the ResumeReplication WMI method as suggested in the event details. This command tells DFS Replication to proceed with the dirty shutdown recovery process. Once recovery completes, this server should log Event ID 4602, indicating it has initialized SYSVOL and is acting as the primary member (for its local data set, not necessarily authoritative for the domain). On the second domain controller waiting for initial sync, run dfsrdiag pollad to force it to check for configuration changes and trigger the initial sync (Event ID 4614), followed by 4604 upon completion. If the first domain controller is in a 2213 state but the second is already healthy (SYSVOL shared, state 4), simply running ResumeReplication on the first domain controller is usually sufficient. It will complete its recovery (logging 2214) and rejoin normal replication.

For environments that have three or more domain controllers¶

In larger environments, the replication topology becomes more significant. Identify all domain controllers that have detected a dirty shutdown (2213) or are otherwise in an error state (state 5) or waiting for initial sync (4614 without 4604).

If Content Freshness is enabled and has triggered (Event ID 4012 logged) on one or more domain controllers, indicating replication stopped due to being offline too long, these servers must be non-authoritatively recovered. The procedure involves disabling and re-enabling their membership in the SYSVOL replication group. You must carefully consider the replication topology: start the non-authoritative recovery from servers that replicate directly from a healthy, up-to-date partner. Disable the membership for the first layer of affected servers, wait for Event 4114, force AD replication and dfsrdiag pollad, then re-enable. Repeat this process layer by layer downstream until all affected servers are recovered. Ensure you back up data on the servers being recovered beforehand, as data not matching the partner’s version might be moved to PreExisting or Conflict and Deleted. After re-enabling membership, wait for 4614 and 4604 events, then restore necessary files from backups or the temporary folders.

A critical scenario arises if all domain controllers in the domain have logged the 4012 event and are in state 5. In this unique case, you must perform a full, authoritative restoration of SYSVOL from the domain controller holding the most complete and current set of policy data. This is the only situation where setting a DFS Replication server as authoritative for SYSVOL is required in a multiple DC environment due to Content Freshness. Follow the specific steps for authoritative synchronization, ensuring the chosen server truly has the authoritative copy of all necessary SYSVOL contents.

If Content Freshness is not enabled or hasn’t been triggered (no 4012 events), and multiple domain controllers are in a 2213 state or error state 5, you can attempt to resume replication on them. Again, consider the replication topology. Start by running the ResumeReplication WMI method on servers that can pull updates from a healthy partner. Work your way downstream through the replication connections. After running ResumeReplication, wait for Event IDs 2212, 2218, and finally 2214, indicating the dirty shutdown recovery is complete and the replicated folder has been initialized. This should allow replication to resume and the shares to appear.

Preventing Future Occurrences of the Issue¶

To minimize the chances of SYSVOL replication issues recurring, investigate the underlying causes of the dirty shutdowns or errors. Frequently, Event ID 2213 and other database errors are linked to unexpected system shutdowns or problems with the disk subsystem where the DFS Replication database and staging folders reside. Examine the Application and System event logs for recurring ESENT database recovery operations, disk performance warnings, or errors immediately preceding system restarts.

Ensure that system drivers, particularly for storage controllers and network adapters, are up to date. If disk performance is consistently poor or errors related to the disk subsystem are logged, consult the hardware vendor for diagnostics or firmware updates. Engaging Microsoft Customer Support Services can also be beneficial to help thoroughly evaluate system health and DFS Replication behavior in complex environments.

Another factor contributing to dirty shutdowns can be the time allotted for services to stop during a system shutdown or restart. The Service Control Manager (SCM) has a default timeout of 20 seconds. For large or busy DFS Replication databases, this might not be enough time for the service to properly commit all outstanding changes and close its database gracefully. You can increase this timeout by configuring the WaitToKillServiceTimeout registry value. Setting this value to a higher number (e.g., 60000 for 60 seconds) can give DFS Replication more time to shut down cleanly, reducing the likelihood of a dirty shutdown on the next startup. Be cautious when modifying registry settings and consult documentation for the specific value and location.

By systematically diagnosing the replication state, preparing domain controllers, applying the appropriate recovery method based on the environment size and Content Freshness state, and addressing underlying system health issues, you can effectively fix missing SYSVOL and Netlogon shares and improve the overall reliability of SYSVOL replication using DFS Replication.

Have you encountered missing SYSVOL/Netlogon shares in your environment? Share your experiences and troubleshooting tips in the comments below!