Active Directory Policy and SYSVOL
Trace a Group Policy failure
Correlate one processing instance, investigate GPO read access and gpt.ini failures, and distinguish filtering from a failing extension.
Define the missing setting and the affected identity
Start with the computer, signed-in user, expected setting, expected GPO, and when the setting should take effect. Computer settings, user settings, preference items, and startup scripts follow different paths. “The GPO is applied” doesn’t tell you whether every item ran.
On the affected machine, collect the relevant user’s report plus elevated computer-scope results:
gpresult /h gpresult.html
gpresult /r /scope user
gpresult /r /scope computer
The HTML output is a local report file. Keep its creation time and the user’s identity. If you elevate as another account, explicitly select the intended user for the report. The gpresult reference documents /user, /scope, and output restrictions.
Classify the failure before refreshing
| Observation | Next evidence |
|---|---|
| GPO absent from applicable/denied lists | Link, OU/site, inheritance, requested user/computer scope, DC’s AD view. |
| GPO denied | Reported security or WMI reason; required identities and effective ACLs. |
| GPO applied, setting wrong | Winning setting, correct half of GPO, CSE behavior, preference action/targeting. |
| GPO files cannot be read | Exact DC/path, SMB and identity, SYSVOL replica content. |
| Processing is slow | One ActivityID, stage timings, the slow CSE or dependency. |
Capture the existing failure before running gpupdate. A refresh creates another processing instance with another ActivityID. Folder redirection, software installation, and scripts also have foreground requirements; see processing behavior.
Follow one ActivityID
Find the relevant Group Policy warning/error in the System log, open its XML/details, and copy System/Correlation/@ActivityID. Then filter the operational channel to that identifier. A PowerShell equivalent is:
$activity = '{11111111-2222-3333-4444-555555555555}'
$xpath = "*[System/Correlation[@ActivityID='$activity']]"
Get-WinEvent -LogName 'Microsoft-Windows-GroupPolicy/Operational' `
-FilterXPath $xpath |
Sort-Object TimeCreated |
Select-Object TimeCreated, Id, LevelDisplayName, Message
Replace the GUID, including braces, with the failed instance. Run locally, or specify the target computer with the required remote-event access. Match stage/CSE start and end events, read status codes, and compare timestamps. With several users on a session host, an unfiltered event list can mix unrelated processing instances. Microsoft’s Group Policy troubleshooting procedure shows the ActivityID workflow.
User policy still needs computer read access
Since MS16-072, Windows retrieves user GPO settings using the computer’s security context. The intended user still needs the appropriate filtering permissions, but the computer must be able to read that GPO. Removing Authenticated Users from Security Filtering can remove both Read and Apply, breaking retrieval even when the intended user group is present.
In GPMC, inspect Delegation → Advanced and effective permissions. When appropriate, restore computer read access through Authenticated Users, Domain Computers, or the intended computer group. Grant Read without granting Apply to a broad group if user application is meant to stay restricted. Check explicit denials too. See Microsoft’s MS16-072 permissions explanation.
Event 1058: use the exact path and error
A gpt.ini read failure can mean a missing path, access denial, a failed DFS referral, name resolution, or an unavailable share. Use the policy GUID and DC from the event rather than browsing a domain path that may choose another replica.
$gpoFolder = '{11111111-2222-3333-4444-555555555555}'
$path = "\\DC1.contoso.com\SYSVOL\contoso.com\Policies\$gpoFolder\gpt.ini"
Get-Content -LiteralPath $path -ErrorAction Stop
Use the affected context where practical. Reading the file as administrator only checks that administrator’s access, not the computer’s. Save the original failure before comparing a second DC. If the direct DC path fails, check its file/share/ACL state; if it works but the domain path fails, inspect DFS referral behavior. The tool examples in Microsoft’s 1058 event guide are historical. Its identity and file-path distinction is still useful; the obsolete interactive-task commands aren’t needed here.
Event 1129: inspect discovery and LDAP
Capture the selected DC and client site, resolve the selected server, and test the affected network path. Event 1129 signals failed connectivity during processing; its detailed message and trace determine the failed dependency. A responding DNS server does not prove a usable LDAP connection. A successful TCP handshake does not prove the bind succeeded.
If the network was unavailable during foreground processing, check whether a later background cycle succeeded and whether this extension needs another foreground cycle. That gives you more to work with than restarting until it works.
Slow processing belongs to a stage
Find where the time goes: DC discovery, GPO metadata retrieval, SYSVOL reads, a WMI filter, or an extension such as scripts or software installation. A WMI filter can time out. Test its exact query and namespace on the affected OS and time it. The WMI filter timeout guidance covers this case. Identify the filter and workload before considering a forest-wide registry workaround.
Collect GPSvc logging when events leave a gap
Local diagnostic change: record the previous GPSvcDebugLevel value under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Diagnostics, ensure %windir%\debug\usermode exists, and enable DWORD 0x30002. Reproduce one cycle, preserve gpsvc.log and EVTX files, then restore the prior setting. The logging instructions describe the path and value.
Retry the intended processing mode
Applies policy: a scoped retry can use:
gpupdate /target:computer
gpupdate /target:user
/force reapplies settings rather than limiting work to detected changes. /sync affects the next foreground application; /boot and /logoff can disrupt the session when required by an extension. Choose the operation deliberately using the gpupdate reference.
Collect a new report and ActivityID afterwards. Check the effective setting and try the operation that needs it; the refresh command’s completion message isn’t enough.
Read the processing mode and identity from the event
For the selected ActivityID, retain XML payloads as well as formatted messages. Check the principal, selected DC, background/foreground mode, synchronous/asynchronous state, loopback mode and extension duration where those fields are present. A computer-startup instance, user-logon instance and background refresh can overlap on one machine while exercising different code paths. Microsoft’s archived PowerShell event-analysis walkthrough demonstrates correlating principal, DC, network and duration evidence. Inspect named XML fields rather than adopting the old script’s positional indexes; available fields depend on event ID/version.
Use the DC recorded in the policy instance and the server reached for its files, rather than %LOGONSERVER%. A skipped CSE may be expected because its GPOs haven’t changed, or because of background restrictions or slow-link rules. “Processing completed” also doesn’t mean every extension succeeded. Match the missing setting to its CSE’s start/end/status events, then check the extension’s external resources and execution identity.
For scripts and preferences, test more than access as an interactive administrator. Computer startup tasks commonly use SYSTEM, so network resources see the machine identity. User logon tasks use the relevant user context, with extension-specific exceptions. The policy may download successfully while a script can’t read another share, or preference targeting selects no item. Once you’ve checked policy retrieval, follow extension and preference mechanics.