Group Policy Not Applying: Windows Troubleshooting

"The GPO is linked, the settings are right, and it works on my machine" is the standard opening line of every Group Policy ticket. The trap is reaching for gpupdate /force first: forcing a refresh only re-applies policies that already reach the target, and it cannot deliver a GPO that scope or filtering is quietly excluding. The right approach is to determine which stage broke — scope, policy retrieval, or processing.

Start With Evidence, Not a Refresh

gpupdate /force
gpresult /r
gpresult /r /scope computer
gpresult /r /scope user
gpresult /h C:\Temp\gpreport.html
gpresult /r /user DOMAIN\username

The HTML report is the single most useful artifact. Read it in this order: Applied GPOs, then GPOs denied / filtered out with the reason, then the component status. A GPO in the applied list means policy arrived and the problem is a setting or precedence issue. A GPO in the denied list names the filter that blocked it. No GPOs at all in either list means the client is not receiving Group Policy from a domain controller at all.

Scope Stage: Security Filtering and WMI Filters

• A GPO applies to an account only if that account (or one of its groups) has both Read and Apply group policy permission on the GPO. Removing Authenticated Users and adding a custom group without granting Read is the most common silent failure.
• Confirm the object is in the OU where the GPO is linked, or a child OU — GPOs linked at the domain root apply to all OUs unless blocked by inheritance.
• Check the link itself is enabled and the GPO status is not set to All Settings Disabled.
• A WMI filter that returns false on the target excludes it without an obvious error; test the query interactively.
• Loopback processing changes which user policies apply on specific computers — a frequent cause of "it works for me but not on the RDS server".

Retrieval Stage: DNS, DC Contact and SYSVOL

nltest /dsgetdc:corp.example.com
nltest /sc_query:corp.example.com
dcdiag /test:dns
\corp.example.com\SysVol\corp.example.com\Policies    # accessibility check
Get-SmbShare -Name SYSVOL

Each GPO has two halves: the Group Policy container in Active Directory and the Group Policy template in the SYSVOL share on every domain controller. Clients read policy from whichever DC they contact, so unreplicated changes mean a lagging DC hands out stale or missing policy. Event ID 1058 in the System log — Windows could not read gpt.ini from SYSVOL — is the canonical symptom, and its usual root causes are DFS-R replication, connectivity or permissions on the policy template.

Processing Stage: The Keys to Event Logs

Event IDs to filter in Applications and Services Logs
  Microsoft-Windows-GroupPolicy/Operational: 4001, 5016, 7016, 7017
  System: 1006 (cannot contact DC), 1058 (SYSVOL read failure), 1129 (network issue during refresh)

Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 50 |
  Where-Object { $_.Id -in 4001,5016,7016,7017 } | Format-Table TimeCreated,Id,Message -Wrap

Event 1006 confirms DC connectivity is the issue. Event 1129 points to a network problem during background refresh — check the workstation's power settings, VPN state and Wi-Fi profile. Event 7016 with a SYSVOL path is a retrieval problem, not a settings problem.

Slow-Link Detection and Other Silent Skips

By default, Windows applies only a subset of client-side extensions over a connection it considers slow (below the default 500 Kbps threshold). Folder Redirection, Software Installation and Scripts are the usual victims. If gpresult reports "slow link detected", either raise the threshold under Computer Configuration → Administrative Templates → System → Group Policy → Configure Group Policy slow link detection, or fix the underlying DNS problem that is making the client measure bandwidth against the wrong DC.

A Repeatable Triage Order

1. gpresult /h and read applied vs filtered.
2. If filtered: check permission, OU placement, link state, WMI filter.
3. If nothing applied: nltest and DNS, then SYSVOL access.
4. If applied but not effective: check precedence (last writer wins per OU order), loopback processing, and whether the setting is only applied at boot for computer-side preferences.
5. Only then force a refresh and retest — and record the outcome in the ticket, because the same OU will break again at the next change.

Related reading: Windows Server DFSR replication troubleshooting and Windows Server DNS zones and conditional forwarders.

原文链接：https://windows-now.com/how-to/fix-group-policy-not-applying-windows