Group Policy Not Applying — Diagnose With gpresult & RSoP

Why GPO Fails Silently

Group Policy has multiple failure modes that produce no visible error to the end user — and often no alert to the admin. The most common culprits:

The computer or user object is not in the OU the GPO is linked to
Security filtering excludes the target — missing Read or Apply Group Policy permission
A WMI filter evaluates to false on that machine
Loopback processing isn't configured when targeting user settings via a computer-linked GPO
A higher-priority GPO or Block Inheritance is overriding it
SYSVOL is inaccessible or replication is broken

Work through each section below in order. Most issues surface by step 2.

Run gpresult First

gpresult is your primary tool. Run it on the affected machine as the affected user. It shows every GPO applied, every GPO filtered, and exactly why.

Generate an HTML report — easiest to read

On the target machine, open CMD or PowerShell as administrator:

gpresult /h C:\gpreport.html /f
start C:\gpreport.html

Look for Denied GPOs. The reason is shown next to each — "Inaccessible", "Disabled", "Security Filtering", etc.

Quick terminal output

gpresult /r

If your GPO is in the Denied list, the reason column tells you exactly what to fix. If it's missing from both lists, the object is not in scope.

TipRun gpresult /r /scope computer or /scope user to isolate which half is failing. Computer settings apply at boot, user settings at logon — they're processed separately.

Force a Refresh

gpupdate /force /logoff

The /logoff flag is important — some user policies only apply at logon, not on a background refresh. If gpupdate hangs or errors about reaching the domain, the problem is network/DNS, not policy logic.

Watch outIf gpupdate /force completes but the policy still doesn't apply, the issue is scope or filtering. Keep reading.

OU Scope and Linking

The GPO is linked to an OU, but the user or computer object is in a different OU. GPOs apply to the OU they're linked to plus all child OUs (unless Block Inheritance is set).

Find the object's actual OU

Get-ADUser -Identity jsmith | Select DistinguishedName
Get-ADComputer -Identity WORKSTATION01 | Select DistinguishedName

Compare that OU path to where the GPO is linked in GPMC. They must overlap — either an exact match or the object must be in a child OU of the linked OU.

Security Filtering

By default, GPOs have Authenticated Users in security filtering with Read + Apply Group Policy. If that group was removed, or a specific group was added without including the target account, the GPO is filtered out.

Check filtering in GPMC

Open GPMC → find your GPO → Delegation tab → Advanced. Verify:

Authenticated Users has Read permission
The specific user/group you're targeting has Apply Group Policy = Allow

NoteWhen using security filtering with a specific group, you must also grant the computer account (for computer policies) Read access — otherwise the machine can't read the policy file from SYSVOL.

WMI Filters

WMI filters evaluate a query against the target machine and only apply the GPO if the query returns true. A bad WMI filter silently blocks the policy everywhere.

Test the WMI query directly on the machine

Get-WmiObject -Query "SELECT * FROM Win32_OperatingSystem WHERE Version LIKE '10.%'"

If the query returns no results, the filter evaluates to false and the GPO is blocked. Fix the query or remove the filter to test.

Event Log Clues

Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" |
  Where-Object {$_.Message -like "*error*" -or $_.Id -eq 4016} |
  Select TimeCreated, Id, Message | Format-List

Key event IDs:

7016 — Failed to apply policy (includes extension name and error code)
1006 / 1030 — Unable to reach domain controller or access SYSVOL

TipEvent 1030 or 1006 usually means DNS or network. Verify the machine can reach a DC with nltest /dsgetdc:YOURDOMAIN before spending time on policy logic.

Group Policy Not Applying — Diagnose and Fix It