How to Fix SYSVOL and NETLOGON Missing on a Domain Controller

A domain controller that isn’t sharing SYSVOL and NETLOGON is a domain controller that can’t do its job. Group Policy stops applying, logon scripts vanish, and clients that depend on those shares start behaving strangely. Run net share on the DC, see no SYSVOL and no NETLOGON, and you’ve found a replication problem hiding behind two missing folders.

Here’s the key idea: those shares are not something you create by hand. A DC only publishes them once its SYSVOL replication is healthy. So the fix is almost never “share the folder” — it’s “get replication working again, and the shares come back on their own.”

This guide walks through identifying whether you’re on DFSR or the older FRS, checking what’s actually broken, and running the right recovery — non-authoritative when one DC is sick, authoritative when SYSVOL is broken across the board.

Why the shares disappear#

SYSVOL holds your Group Policy templates and logon scripts, and it’s replicated between DCs by a dedicated engine. On domains built for Server 2012 and later that engine is DFS Replication (DFSR). Older domains may still use the legacy File Replication Service (FRS) until someone migrates them.

The Netlogon service only advertises the SYSVOL and NETLOGON shares when it’s satisfied that replication is in a good state. If the replication engine is stopped, in an error state, or stuck mid-initialization, Netlogon holds the shares back rather than serve incomplete policy. That’s the behavior you’re seeing.

Common triggers:

• A DC was promoted but never completed its initial SYSVOL sync.
• DFSR hit a dirty shutdown or database error and paused replication.
• FRS suffered a journal wrap and stopped on its own.
• A system state restore left the DC’s SYSVOL out of step with the engine.
• Replication has been broken long enough that the DC fell out of sync entirely.

Step 1: Confirm what’s actually missing#

Start on the affected DC with the basics. Are the shares really gone, or just one of them?

net share

You want to see both SYSVOL and NETLOGON listed, pointing at the SYSVOL path (by default C:\Windows\SYSVOL\sysvol\<domain> and the scripts subfolder). If they’re absent, check the underlying folders exist on disk:

Get-ChildItem C:\Windows\SYSVOL\sysvol
Get-ChildItem C:\Windows\SYSVOL\domain

Then run a focused health check:

dcdiag /test:netlogons /v
dcdiag /test:sysvolcheck /v

dcdiag will usually tell you whether the problem is the share, the replication engine, or something broader like DNS or RPC.

Step 2: Determine DFSR or FRS#

The recovery procedure is completely different depending on the engine, so confirm which one your domain uses:

dfsrmig /getmigrationstate

If you’re still on FRS, migrating to DFSR should be on your roadmap — FRS has been deprecated for years and isn’t supported as a SYSVOL engine on current server versions. But fix the immediate outage first.

Step 3a: Fix it on DFSR#

For DFSR, the question is how many DCs are affected.

If one DC is broken and at least one other has a good SYSVOL, you do a non-authoritative sync on the broken DC — it rebuilds its copy from a healthy partner. If every DC has a bad or empty SYSVOL, you pick the best copy, mark it authoritative, and let the others sync from it.

flowchart TD
A["SYSVOL/NETLOGON missing"] --> B{"Does at least one DC<br/>have a good SYSVOL?"}
B -->|Yes| C["Non-authoritative sync<br/>on the broken DC (D2)"]
B -->|"No, all bad"| D["Authoritative sync (D4)<br/>on the best copy"]
D --> E["Non-authoritative sync<br/>on every other DC"]
C --> F["Netlogon republishes shares"]
E --> F

Non-authoritative DFSR sync (one broken DC)#

This is the common case and the safer one. On the broken DC, edit its DFSR SYSVOL subscription object in AD (via ADSI Edit or PowerShell) and set the non-authoritative flag, then restart DFSR.

The object lives at:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<ThisDC>,OU=Domain Controllers,DC=...

Set msDFSR-Enabled = FALSE, force replication of that change, restart DFSR, then set msDFSR-Enabled = TRUE and restart DFSR again:

# 1. On the broken DC, disable its SYSVOL membership (msDFSR-Enabled = FALSE)
#    then push the change and restart DFSR
repadmin /syncall /AdeP
Restart-Service DFSR

# 2. Re-enable membership (msDFSR-Enabled = TRUE), push again, restart
repadmin /syncall /AdeP
Restart-Service DFSR

DFSR sees the membership come back, treats the local copy as needing initialization, and pulls a fresh copy from a healthy partner. Watch the DFS Replication event log for event 4614 (initialization) followed by 4604 (a healthy, initialized SYSVOL).

Authoritative DFSR sync (all DCs broken)#

Only do this when no DC has a usable SYSVOL, because it declares one DC’s contents as the master that overwrites everyone else. Pick the DC with the most complete, correct SYSVOL.

On that chosen DC:

1. Stop the DFSR service.
2. Set msDFSR-Enabled = FALSE and msDFSR-Options = 1 on its SYSVOL subscription object.
3. Force replication of that change to all DCs (repadmin /syncall /AdeP).
4. Start DFSR — it logs event 4114 (SYSVOL no longer replicating).
5. Set msDFSR-Enabled = TRUE, force replication again, restart DFSR.
6. Look for event 4602, confirming this DC is now the authoritative SYSVOL source.

Then run the non-authoritative procedure on every other DC so they rebuild from the authoritative copy.

Step 3b: Fix it on FRS (legacy)#

If dfsrmig told you the domain still runs FRS, the equivalent recovery uses the BurFlags registry value under:

HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

The BurFlags value drives the resync:

The procedure mirrors DFSR:

1. Stop the File Replication Service:   net stop ntfrs
2. Set BurFlags = D2 (single broken DC) or D4 (authoritative source)
3. Start the service:                   net start ntfrs
4. Watch the File Replication Service event log for event 13516
   (FRS is ready and SYSVOL is being shared again)

For a domain-wide rebuild: set D4 on the one good DC, start FRS, confirm it’s healthy, then set D2 on every other DC. A common cause of FRS stopping in the first place is a journal wrap (event 13568) — the D2 resync clears it.

Step 4: Verify the shares are back#

Once the engine reports a healthy, initialized SYSVOL, Netlogon should republish the shares within a minute or two. Confirm:

net share
dcdiag /test:netlogons
dcdiag /test:sysvolcheck

You can also force a Netlogon recheck if you’re impatient:

Restart-Service Netlogon

Wrapping up#

Missing SYSVOL and NETLOGON shares almost always trace back to a stalled replication engine, not a broken share. Identify whether you’re on DFSR or FRS, figure out whether one DC or all of them are affected, then run the matching recovery: non-authoritative to rebuild a single sick DC from a healthy one, authoritative only when everything is broken and you’ve confirmed the best copy.

The one mistake to avoid is forcing an authoritative copy from the wrong DC, or hand-copying the folder and bypassing the engine. Let DFSR or FRS do the work, verify with dcdiag, and the shares come back on their own. If this DC has been unhealthy for a while, it may be cleaner to retire it — see decommissioning a domain controller safely.