SYSVOL Unavailable in Active Directory Domain Environment

Question

SYSVOL Unavailable in Active Directory Domain Environment

Carlos Lopez 0

The SYSVOL shared folder is unavailable or inaccessible on one or more Domain Controllers within the Active Directory domain environment

0 comments

Answer accepted by question author

Ronald Sabiiti 1,585 Independent Advisor

Hi Carlos,

When the SYSVOL share is unavailable on a Domain Controller, Group Policy processing and logon script access may be affected. This is commonly related to DFS Replication (DFSR), DNS resolution, or Netlogon service issues.

I recommend performing the following checks on the affected Domain Controller:

Verify SYSVOL and NETLOGON shares: Run net share and confirm that both shares are present.
Check Active Directory health: Run dcdiag /v and repadmin /replsummary to identify domain controller health or replication issues.
Check DFS Replication: Review Event Viewer → Applications and Services Logs → DFS Replication for errors, particularly events 4612, 2213, and 4012.
Verify services: Ensure that DFS Replication and Netlogon services are running.
Check SYSVOL replication: If DFSR is used, run dfsrmig /getmigrationstate to verify the SYSVOL replication migration state.
Verify DNS and connectivity: Confirm that the affected DC can resolve and communicate with its replication partners.

Microsoft documentation for references:

Troubleshoot DFSR SYSVOL replication failures

Troubleshoot domain controller location and DNS issues

SYSVOL replication and migration to DFS Replication

Thank you for choosing Microsoft Q&A.

0 comments

1 additional answer

Your answer

Answer 1

Identify whether the affected domain controllers use DFS Replication (DFSR), then classify each controller by its SYSVOL share, replication state, and DFSR event ID before attempting recovery.

1. Inventory SYSVOL and DFSR state

Run these commands from an elevated Command Prompt on a domain controller:

For /f %i IN ('dsquery server -o rdn') do @echo %i && @(net view \\%i | find "SYSVOL") & echo

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

repadmin /replsummary

DFSR state 4 is normal; 2 means initial synchronization, and 5 means an error. A missing WMI instance can also indicate that the controller cannot report its DFSR state. Microsoft recommends diagnosing the affected and upstream controllers before reinitializing SYSVOL; deleting the DFSR database is discouraged and can make local data non-authoritative.^1^

These procedures apply only when SYSVOL uses DFSR. Evidence includes a SYSVOL Share WMI instance and events under Event Viewer → Applications and Services Logs → DFS Replication. If the domain still uses FRS, do not apply the msDFSR-* recovery procedure; use the separate FRS checks, including REPADMIN /SHOWREPS, NTDS connection objects, DNS resolution, replica-set membership, and subscription validation.^2^

2. Select the recovery branch by event ID

Before changing replication membership, copy every DC’s SYSVOL contents—including PreExisting and Conflict and Deleted, if present—to a safe location.

Event 2213: DFSR is paused after recovery from a dirty shutdown. Run the exact ResumeReplication WMI command included in that controller’s 2213 event. Successful recovery logs 2214. If another DC is awaiting initial synchronization, run:
```
  dfsrdiag pollad
```
Successful SYSVOL initialization logs 4604.
Event 4012: Content-freshness protection stopped replication. The documented default threshold is 60 days; a configured nonzero value may differ. Query it with:
```
  wmic.exe /node:%computername% /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays
```
If only some DCs are affected and at least one healthy DC has a current SYSVOL, recover the affected DCs non-authoritatively.
Event 4614 without 4604: The DC is waiting for initial SYSVOL replication. Confirm that its upstream partner is healthy rather than repeatedly rebuilding the waiting DC.^1^

3. Non-authoritative recovery for individual affected DCs

Use this when at least one DC has a verified, current SYSVOL and only selected DCs need repair:

Open adsiedit.msc and locate the affected DC’s object:

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

Set msDFSR-Enabled=FALSE.
Force AD replication using Active Directory Sites and Services → NTDS Settings → connection → Replicate Now. Validate both partners:
```
   REPADMIN /SHOWREPS <sourceDC>
   REPADMIN /SHOWREPS <affectedDC>
```
Run DFSRDIAG POLLAD on the affected DC and confirm event 4114.
Set msDFSR-Enabled=TRUE, replicate AD again, and rerun DFSRDIAG POLLAD.
Confirm events 4614, followed by 4604, and verify net view \\<affectedDC> lists SYSVOL.^3^

4. Authoritative recovery only when the entire domain requires it

Use this domain-wide operation only when every DC requires initialization—for example, all DCs are state 5 with event 4012—and after identifying the DC containing the newest valid SYSVOL:

Set DFSR startup to Manual and stop DFSR on every DC.
In ADSI Edit, set msDFSR-Enabled=FALSE on every DC’s SYSVOL Subscription.
On the chosen authoritative DC only, also set msDFSR-options=1.
Replicate AD throughout the domain and validate with REPADMIN /SHOWREPS.
Start DFSR only on the authoritative DC; confirm 4114.
Set its msDFSR-Enabled=TRUE, replicate AD, then run:
```
   DFSRDIAG POLLAD
```
Confirm 4602 on the authoritative DC.
Start DFSR on every other DC; confirm 4114.
Set msDFSR-Enabled=TRUE on each non-authoritative DC and run DFSRDIAG POLLAD.
Confirm 4614, then 4604, verify the SYSVOL shares, and restore DFSR startup to Automatic on every DC.^3^

References