Active Directory Policy and SYSVOL
SYSVOL health
Check the shares, folder state, backlog, and whether the required files actually arrived.
AD replication and SYSVOL replication are separate
A GPO has directory metadata and files in SYSVOL. Healthy AD replication does not prove those files have arrived. A working SYSVOL share does not prove every DC has the same content.
Use a DC’s explicit UNC path when comparing its copy. A domain path can refer the client to another DC:
\\DC1.contoso.com\SYSVOL\contoso.com\Policies
\\DC2.contoso.com\SYSVOL\contoso.com\Policies
Confirm the share and readiness
Run on the target DC, or use the relevant remote-management option:
Get-SmbShare -Name SYSVOL, NETLOGON
dcdiag /s:DC1 /test:SysVolCheck /v
dcdiag /s:DC1 /test:NetLogons /v
SysVolCheck checks SYSVOL readiness; it is not a byte-for-byte comparison across all DCs. NetLogons adds checks of the shares and access. Read the DCDiag test descriptions when interpreting a pass.
Query the replicated folder state
Get-CimInstance -ComputerName 'DC1.contoso.com' `
-Namespace 'root\MicrosoftDFS' -ClassName DfsrReplicatedFolderInfo |
Where-Object ReplicatedFolderName -eq 'SYSVOL Share' |
Select-Object ReplicationGroupName, ReplicatedFolderName, State
| State | Meaning |
|---|---|
| 0 | Uninitialized |
| 1 | Initialized |
| 2 | Initial synchronization |
| 3 | Automatic recovery |
| 4 | Normal |
| 5 | Error |
No returned instance doesn’t mean state 4. Check for a query failure, then inspect the service, configuration, and event log. Remote CIM needs the right permissions and connectivity; a failed management query doesn’t tell you the replicated folder’s state.
A backlog has a direction
With DFSR management tools installed:
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /sendingmember:DC1 /receivingmember:DC2
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /sendingmember:DC2 /receivingmember:DC1
These ask what one member hasn’t received from the other. Check both directions where relevant. A nonzero count can be normal during activity; one that never drains needs investigation. A zero count for one pair doesn’t tell you about every member or whether the application’s expected files exist.
Get-DfsrBacklog provides PowerShell access where the DFSR module is available. Its ordinary output is limited to the first 100 pending updates; use its documented verbose reporting when obtaining the total. See Get-DfsrBacklog.
Read the DFS Replication log
Get-WinEvent -ComputerName 'DC1.contoso.com' `
-FilterHashtable @{ LogName = 'DFS Replication'; Level = 2, 3 } `
-MaxEvents 30 |
Select-Object TimeCreated, Id, Message
An old warning may have a later recovery event. Read the sequence rather than just counting errors. Events such as 2213 (paused replication) and 4012 (content freshness protection) need their specific documented response.
Get-CimInstance -ComputerName 'DC1.contoso.com' `
-Namespace 'root\MicrosoftDFS' -ClassName DfsrMachineConfig |
Select-Object MaxOfflineTimeInDays
Content freshness is enabled by default on Windows Server 2012 and later DCs. Check the actual configured value rather than inferring it from the OS version. See Microsoft’s missing SYSVOL and NETLOGON troubleshooting guide.
Measure propagation after health checks
DFS Management can generate a health report for Domain System Volume and a propagation test/report. The propagation test creates content, so plan it as a change and record the participating DCs and timing. Resolve stalled initial sync, paused members, or stale configuration before adding test traffic.
Don’t delete the database or try authoritative/non-authoritative resets just to see what happens. First work out which content is correct, then use the appropriate SYSVOL recovery procedure.
Readiness does not replace a share-access test
SysVolCheck reads Netlogon’s SysVolReady registry value. A value of 1 satisfies that readiness check, but it does not compare policy files or prove a particular client can read them. NetLogons checks access to the SYSVOL and NETLOGON shares. Use both the server’s publication state and access from the affected client. See the test definitions.
If one client fails and another succeeds against the same DC, check identity, SMB/network path, and client state. If every client fails against one DC but succeeds against another, check the failing DC’s share/replica. Keep the explicit server path with each result; a domain UNC may send you to a different server between tests.
Distinguish initial sync from an idle normal replica
Event 4614 says SYSVOL is waiting for initial replication. A later 4604 establishes completion for that initialization. A newly promoted DC with 4614 but no subsequent 4604 may be waiting on a source whose DFSR is paused or in error.
Inspect the upstream source as well as the new member. Starting over on the new DC cannot make an unavailable source provide files. Event 2213, content-freshness event 4012, initial-sync waiting, and normal state 4 are different branches in Microsoft’s missing-share guide.
Put a number and a time on the backlog
Get-DfsrBacklog -GroupName 'Domain System Volume' -FolderName 'SYSVOL Share' `
-SourceComputerName 'DC1' -DestinationComputerName 'DC2' -Verbose
Keep the named source/destination with the result. Record the verbose total separately from the returned objects, then repeat after an interval that suits the workload. A decreasing backlog suggests progress. Repeated reconnect errors, a fixed count, and new changes arriving faster than delivery each need a different investigation. The backlog cmdlet documents the 100-object output limit and total reporting.
Check the event log and schedule when a backlog stalls. dfsrdiag ReplicationState can be empty between transfers; it does not contradict a stored backlog. The count is pending updates, not a byte count or guaranteed completion estimate.
Compare a disputed file explicitly
For one policy or script, compare existence, content hash, and relevant ACLs on both server paths. PowerShell’s Get-FileHash establishes content equality for that file at collection time; it does not validate its ACL, all files, or the DFSR database. Policy version consistency also needs the GPO’s AD data and gpt.ini value. Use Group Policy tracing when file delivery and policy application disagree.
The share path is not necessarily the replica root
Read the published paths on the affected DC rather than assuming C:\Windows\SYSVOL\domain:
Get-SmbShare -Name SYSVOL,NETLOGON | Select-Object Name,Path
Run locally on that DC or through an explicit CIM session. NETLOGON normally exposes the domain’s scripts directory; SYSVOL exposes the namespace containing the domain junction and policies. FRS migration can introduce a separate SYSVOL_DFSR tree. A hard-coded script can keep changing the old tree after production shares move.
Inspect junction targets and DFSR’s configured content path as well as the files reached through the share. A missing junction, wrong target, unpublished share, inaccessible file and unsynchronized replica are different failures. Microsoft’s historical SYSVOL tree reference documents the FRS layout; adapt path inspection to the actual DFSR/migration state rather than recreating its old junction commands blindly.
When collecting sizes or file lists, don’t count the same tree through both its physical directory and junction aliases. Leave service-private staging/database/conflict trees out of ordinary policy-content comparisons. Keep the physical paths alongside the server UNC results, so you can check that you haven’t compared two aliases of the same data.