Active Directory and Group PolicyNew in this releasePublished 20 July 2026

SYSVOL or NETLOGON shares are missing on a domain controller: diagnosing DFSR and Group Policy

Missing SYSVOL and NETLOGON commonly indicates incomplete DFSR initial sync, replication failure, database trouble or an incorrect recovery action.

Control risk before changing productionValidate first in a test environment or on one representative system, and preserve configuration, logs and recoverable backups. Production cutovers, bulk policy changes, database repair and storage rebuild require a maintenance window and explicit rollback criteria.

1. Conclusion and scope

SYSVOL stores Group Policy templates and logon scripts, and NETLOGON is published only when SYSVOL is ready. Recreating folders or shares manually does not repair the directory state; an incorrect authoritative recovery can replicate damaged content to every DC.

This issue involves Active Directory, DNS, Group Policy, authentication and domain-controller health. Validate replication, backup and scope before change.

2. Risk signals that deserve priority

SYSVOL and NETLOGON are absent from net share, and clients fail to process GPO or logon scripts.
The DFS Replication log reports events such as 2213, 4012, 4612 or 4602, or replication remains stalled.

3. Pre-change assessment checklist

Identify the DC with the complete and most current SYSVOL and protect a backup of that copy first.
Run repadmin and dcdiag and check AD replication, DNS, time and disk health.
Review DFS Replication events, service state, database and SYSVOL subscription objects.
Determine whether snapshots, cloning, forced sync or a legacy FRS migration recently occurred.

Read-only checks and validation examples

net share
dcdiag /test:advertising /test:sysvolcheck
repadmin /replsummary
Get-WinEvent -LogName "DFS Replication" -MaxEvents 50

corp.example, 192.0.2.0/24 and 203.0.113.0/24 are documentation-only examples. Replace them only after the actual environment values have been verified.

4. Recommended implementation sequence

Do not manually create shares or apply arbitrary BurFlags changes.
Follow the Microsoft process for non-authoritative or authoritative DFSR sync and nominate exactly one authoritative source.
Recover one DC at a time and observe events 4602/4604 and share publication.
Compare Policies, Scripts, GPO counts and versions, then retest clients.

Remote assessment or on-site work?Logs, configuration and a small number of systems can usually be assessed remotely. Physical servers, storage, data-centre power, bulk cutover and recovery exercises should use a controlled on-site window. On-site service is available for Zhejiang, Shanghai and Jiangsu; other locations can be supported remotely.

5. Validation, rollback and common mistakes

Every DC publishes SYSVOL and NETLOGON again.
repadmin and DFSR show no persistent failures, and file-system and AD GPO versions match.
A new test GPO replicates and applies on a client.

Common mistakes

Running authoritative recovery on several DCs at once.
Overwriting a healthy SYSVOL with a snapshot from an uncertain time.
Stopping after the shares return without checking GPO content integrity.

Official references

Microsoft: Force authoritative and non-authoritative SYSVOL synchronization

Frequently asked questions

Can the SYSVOL and NETLOGON shares be created manually?

No. That does not repair replication or readiness and may conceal the real problem.

Which DC should be authoritative?

Use the copy that is complete, current and confirmed by the business and change records.

Need an assessment based on the actual environment?

Provide versions, topology, complete errors, event-log timestamps, scope of impact, recent changes and actions already taken. We will first determine risk, service boundary and rollback, then confirm the implementation scope.