Is your Group Policy not applying in Windows 10 or Windows 11? You’ve configured a GPO, run gpupdate /force, but the setting still isn’t taking effect. This guide covers 8 proven fixes for when Group Policy simply refuses to apply in 2026.
Why Is Group Policy Not Applying?
Common causes include:
- GPO linked to the wrong OU
- Security filtering blocking the user or computer
- WMI filter not matching
- Loopback processing conflicting with user policies
- Higher-priority GPO overriding your settings
- Corrupted local Group Policy cache
- Computer not connected to domain controller
- Policy requires logoff or reboot to take effect
Fix 1: Run GPUpdate /Force and Check with GPResult
Start with the basics. Force a fresh policy refresh and immediately check what applied:
gpupdate /forceThen verify:
gpresult /rCheck the output for your GPO name. If it appears under "The following GPOs were not applied," the reason will be listed next to it. This is your first diagnostic step.
Fix 2: Verify the GPO Is Linked to the Correct OU
A GPO only applies to objects (users or computers) inside the OU it is linked to.
- Open Group Policy Management Console — press Win + R, type
gpmc.msc - Expand your domain → find your GPO
- Check the Scope tab → confirm the GPO is linked to the correct OU
- Confirm the target user or computer object is inside that OU
A common mistake is linking the GPO to the domain root but the computer sits in a sub-OU with "Block Inheritance" enabled.
Fix 3: Check Security Filtering
By default, GPOs apply to "Authenticated Users." If someone changed the security filtering, your user or computer may be excluded.
- In GPMC, select your GPO → go to Scope tab
- Under Security Filtering, check who is listed
- If “Authenticated Users” is removed, add your specific user, computer, or group
- Also check the Delegation tab → verify the target has Read and Apply Group Policy permissions
Fix 4: Check and Fix WMI Filters
WMI filters can silently block a GPO if the filter condition isn’t met on the target machine.
- In GPMC, select your GPO → check the WMI Filter field at the bottom
- If a WMI filter is set, click it to view the query
- Test the WMI query on your target machine in PowerShell:
Get-WmiObject -Query "SELECT * FROM Win32_OperatingSystem WHERE Version LIKE '10.%'"If the query returns no results, the WMI filter is blocking the GPO. Either fix the query or remove the filter.
Fix 5: Reset the Local Group Policy Cache
A corrupted local Group Policy cache prevents new policies from applying. Clearing it forces a fresh download from the DC.
- Open Command Prompt as Administrator
- Run:
rd /S /Q "%WinDir%System32GroupPolicy"
rd /S /Q "%WinDir%System32GroupPolicyUsers"
gpupdate /forceThis deletes all locally cached policy files and forces a complete rebuild from the domain controller.
Fix 6: Check GPO Precedence (Which GPO Wins)
When multiple GPOs apply conflicting settings, the one with highest precedence wins. The order is:
- Local Group Policy (lowest priority)
- Site-level GPOs
- Domain-level GPOs
- OU-level GPOs (highest priority — child OU overrides parent)
In GPMC → select your OU → go to Group Policy Inheritance tab to see the full precedence order. The GPO at the top has the highest priority.
Use gpresult /h C:report.html /f and open the HTML report — it shows the Winning GPO for each setting.
Fix 7: Check Event Viewer for Group Policy Errors
- Press Win + R → type
eventvwr.msc - Navigate to: Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational
- Look for Error (red) or Warning (yellow) events
Key Event IDs to watch for:
| Event ID | Meaning |
|---|---|
| 1129 | Network connectivity failure to domain controller |
| 1030 | Cannot fetch GPO list from DC |
| 7016 | Specific Client Side Extension (CSE) failed |
| 1085 | Windows failed to apply specific policy setting |
Fix 8: Some Policies Require Logoff or Reboot
Certain policy types only apply during foreground processing — at user logon or machine startup:
- Software Installation policies
- Folder Redirection policies
- Some registry-based preferences
For these, run:
gpupdate /force /logoffor
gpupdate /force /bootThis triggers the required logoff or reboot after the policy refresh, allowing foreground-only policies to take effect.
Quick Diagnostic Checklist
| Check | Tool |
|---|---|
| Is GPO linked to correct OU? | GPMC → Scope tab |
| Is target in security filter? | GPMC → Security Filtering |
| Is WMI filter passing? | PowerShell WMI query test |
| Which GPO is winning? | gpresult /h report.html |
| Any GP errors in logs? | Event Viewer → GroupPolicy → Operational |
| Does policy need reboot? | gpupdate /force /boot |
Key Takeaways
- Always start with
gpupdate /forcethengpresult /rto diagnose - Check GPO link, security filtering, and WMI filters in GPMC
- Clear the local GP cache if policies were working before but stopped
- Use the HTML report from gpresult to find which GPO is winning
- Some policies only apply at logon or reboot — use /logoff or /boot
For more Windows help, visit PGUpdate.in. See our related guides on gpupdate /force complete guide, fixing gpupdate not working, and how to use the gpresult command.
Frequently Asked Questions
Why is my Group Policy not applying even after gpupdate /force?
Check security filtering in GPMC — the user or computer may not be in the allowed group. Also check if a higher-priority GPO is overriding your setting using gpresult /h report.html.
How do I know which GPO is actually being applied?
Run gpresult /h C:report.html /f and open the HTML file. It shows the "Winning GPO" for every setting, making it clear which policy is taking effect.
Can a GPO apply to some computers but not others?
Yes — security filtering, WMI filters, and OU placement all control which computers receive a GPO. Use gpresult on the affected machine to see exactly what is and isn’t applying.
Does Group Policy work on non-domain computers?
Only Local Group Policy (via gpedit.msc) works on non-domain computers. Domain GPOs require the computer to be joined to an Active Directory domain.
How long does it take for Group Policy to apply automatically?
By default, every 90 minutes for computers and users, with a random offset of up to 30 minutes. Domain Controllers refresh every 5 minutes. Use gpupdate /force to apply immediately without waiting.
