Recover Missing SYSVOL and NETLOGON Shares on a Domain Controller

Before you begin

Applicable to supported Windows Server/client environments where the named role or feature is installed. Run read-only checks first from an elevated PowerShell or Command Prompt as appropriate. Replace example hostnames, domain names, addresses, ports and paths with values from the affected environment. Record the exact error, timestamp, OS build and scope of impact.

Production safety: obtain change approval and a verified backup before modifying AD DS, DNS, DHCP, firewall, IIS, storage or Hyper-V configuration. Ensure console/out-of-band access before network or remote-access changes.

Symptoms and likely root cause

A DC does not publish SYSVOL/NETLOGON, Group Policy fails or a newly promoted DC never completes SYSVOL initial sync.

DFSR paused after dirty shutdown, upstream DC replication failure, content freshness protection, incomplete initial sync or wrong source-of-truth selection.

Diagnostic commands

net share
dcdiag /test:sysvolcheck /test:advertising
Get-Service DFSR,Netlogon
Get-WinEvent -LogName DFS Replication -MaxEvents 100 | Select TimeCreated,Id,LevelDisplayName,Message
repadmin /replsummary
dfsrdiag replicationstate

Run the commands in order and save the complete output. The commands above are intended to establish the failing layer before a configuration change is attempted.

How to interpret the results

Healthy DCs publish both shares. Interpret DFSR event 2213 (paused after dirty shutdown), 4012 (content freshness), 4614 (initial sync pending), 4604 (SYSVOL initialized) and 4602 (authoritative initialization) using full event text. Identify which DC has the latest valid SYSVOL data.

Practical correction

If event 2213 is present, use the ResumeReplication method in that event and confirm recovery. For initial sync, repair partner connectivity/backlog. Authoritative/non-authoritative sync is a high-risk recovery and must follow Microsoft procedure only after source-of-truth and backups are confirmed.

Make one change at a time. Re-run the failed diagnostic after each change so the cause-and-effect relationship is clear.

Fallback and recovery

Back up SYSVOL contents and system state. Never delete the DFSR database, force authoritative sync on every DC or copy SYSVOL folders over each other. Stop if the selected source lacks current GPO/scripts.

Verification checklist

Success: DFSR reaches normal state, SYSVOL and NETLOGON shares appear, dcdiag checks pass and a client can read/apply a test GPO.

• Repeat the original failing operation from the affected client/user or service.
• Test from a second approved endpoint or subnet where relevant.
• Review the relevant event log/IIS log after the fix.
• Record the change, actual result and any remaining limitation.

Frequently asked question

Can deleting the DFSR database fix missing shares? No. Microsoft discourages it; it complicates recovery and risks data loss.

Official technical reference

Microsoft Learn — troubleshoot missing sysvol and netlogon shares

Use the official documentation for exact version support, prerequisites and any procedure that differs between Windows Server releases.

Technician field note

This runbook describes a controlled diagnostic path; it is not a universal guarantee that every environment has the same cause. If evidence does not match the expected result, stop and investigate rather than applying unrelated fixes. Do not mark the incident resolved until the original symptom is verified as cleared.