Group Policy Not Applying: A Step-by-Step Troubleshooting Guide for Security and IT Teams Who Need to Know Why GPO Settings Are Being Skipped

The first command to run on any endpoint experiencing a GPO failure:

gpresult /H C:\gpresult.html /F

Open the HTML report and check two sections:

Applied GPOs: Lists every GPO that was applied, including the DC it was read from and the applied order. If the GPO you expect does not appear here, it was either filtered out or never reached the client.

Denied GPOs: This section is the most useful for troubleshooting. Each denied GPO shows the reason it was not applied. Common reasons:

• Reason: Not Applied (Empty) -- The GPO has no settings in the applicable section (Computer vs User)
• Reason: Inaccessible (No Read Permissions) -- The computer account cannot read the GPO object in AD
• Reason: Denied (Security) -- Security filtering removed the computer from scope
• Reason: Denied (WMI Filter) -- The WMI filter evaluated to false on this machine
• Reason: Not Applied (Unknown Reason) -- Requires event log investigation

For computer-side GPOs, run gpresult as SYSTEM to get the computer context (user context shows user GPOs, computer context shows computer GPOs):

pshtool.exe -s cmd.exe /c "gpresult /H C:\gpresult_system.html /F"

Or use PsExec:

PsExec.exe -s gpresult /H C:\gpresult_computer.html /F

The single most common reason a GPO fails to apply is a security filtering misconfiguration introduced when trying to scope the GPO to a specific group.

The default security filter on every GPO is Authenticated Users with Read and Apply Group Policy permissions. This ensures every authenticated computer and user in scope gets the policy. When administrators add a custom group (e.g., Target Computers) to the security filter, they often remove Authenticated Users without understanding that this breaks computer policy application.

Here is why: when a computer processes GPOs during startup, it authenticates as the computer account. If Authenticated Users is removed, the computer account has no Read permission on the GPO object itself. The CSE cannot read the GPO settings and the policy silently fails.

The fix requires two separate steps:

1. Add the target group to security filtering with Apply Group Policy permission
2. Keep Authenticated Users with Read permission only (uncheck Apply Group Policy for Authenticated Users, but leave Read checked)

This allows all authenticated users/computers to read the GPO (required), but only the target group will have the policy applied to them.

To verify security filtering in PowerShell:

Get-GPPermission -Name "Your GPO Name" -All | Select-Object Trustee, Permission

Look for entries where Trustee has GpoApply permission. If only a custom group has GpoApply and Authenticated Users has no Read, that is the bug.

WMI filters add a conditional evaluation to GPO application. Before applying a GPO, the client runs a WMI Query Language (WQL) query on the local machine. If the query returns no results, the GPO is denied. The failure shows as Reason: Denied (WMI Filter) in gpresult.

Common WMI filter failure scenarios:

OS version filter excluding new builds: A WMI filter targeting Select * from Win32_OperatingSystem Where Version LIKE "10.0.19%" will fail to match Windows 11 (10.0.22xxx builds). Verify the build version on the endpoint:

wmic os get Version

Architecture filter with incorrect string: %PROCESSOR_ARCHITECTURE% is an environment variable, not a WMI property. Use Win32_Processor.AddressWidth instead:

SELECT * FROM Win32_Processor WHERE AddressWidth = '64'

WMI repository corruption: If WMI is corrupt on the endpoint, all WMI filter queries fail and all GPOs with WMI filters are denied. Test WMI health:

winmgmt /verifyrepository

If the result is not WMI repository is consistent, rebuild the repository:

winmgmt /resetrepository

To test a WMI filter query manually before debugging the GPO:

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

If the command returns an object, the filter passes. If it returns nothing, the filter would deny the GPO.

Replication failures: A GPO link created on DC1 may not be visible from DC2 if replication is delayed or broken. The endpoint contacts its logon DC for GPO processing. If that DC has not replicated the new GPO link, the policy does not apply.

Check which DC the endpoint authenticated against:

nltest /dsgetdc:yourdomain.com

Then verify whether that specific DC has the GPO link:

Get-GPInheritance -Target "OU=Workstations,DC=domain,DC=com" -Domain yourdomain.com -Server thatspecificDC

Compare the output to what you see from your primary DC. If the GPO link is missing from one DC, check replication health:

repadmin /showrepl
repadmin /replsummary

Link order: When multiple GPOs are linked to the same OU, they process in link order (highest number = lowest priority). A GPO with a lower link order number wins when settings conflict. If your security GPO is at link order 5 and a local IT GPO at link order 1 sets a conflicting value, the IT GPO wins.

Inheritance blocking and enforcement: An OU with Block Policy Inheritance set will not receive GPOs linked to parent OUs or the domain. Only GPOs linked directly to that OU, or GPOs marked as Enforced, will apply. Use Get-GPInheritance to check:

Get-GPInheritance -Target "OU=Workstations,DC=domain,DC=com" | Select-Object GpoLinks, InheritedGpoLinks, GpoInheritanceBlocked

If GpoInheritanceBlocked is True, your domain-level security GPOs are not reaching computers in that OU unless they are enforced.

When gpresult shows a failure but the reason is unclear, the Group Policy Operational event log has detailed processing records for each GPO evaluation cycle.

Open Event Viewer and navigate to: Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational

Or query via PowerShell:

Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 200 |
Where-Object { $_.LevelDisplayName -in @('Error','Warning') } |
Select-Object TimeCreated, Id, Message |
Format-List

Key event IDs:

• Event 7017: GPO processing failed. The message includes the GPO name and the error code.
• Event 7320: Security filtering blocked GPO application (the machine account is not in the Apply Group Policy scope).
• Event 7013: The client could not contact the domain controller to read GPO data (network/DNS issue).
• Event 5312: List of GPOs that applied during this processing cycle. Cross-reference with gpresult to verify consistency.

For corporate security baselines (e.g., CIS Level 1 GPOs), pay particular attention to Event 7320 appearing on machines that should be in scope. This often indicates that a group membership change removed the computer account from the target group.