Interactive Troubleshooter

Published: Sep 1, 2026

Group Policy Not Applying: gpresult and rsop Guide

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

An interactive root-cause diagnostic tree to systematically identify and resolve Group Policy Objects (GPO) failing to process on Windows clients. Diagnose MS16-072 security filtering permissions, SYSVOL DFS-R synchronization failures, WMI filter evaluations, and fast startup processing delays.

Full Diagnostic Tree & Step-by-Step Overview

What specific diagnostic behavior or error is reported when running gpresult /h or checking Event Viewer?

GPO is listed under 'Denied GPOs' (Access Denied, Security Filtering, or WMI Filter false evaluation)
GPO is listed under 'Applied GPOs' but settings fail to take effect, or infrastructure/SYSVOL error occurs
Group Policy processing is completely skipped, delayed until reboot, or loopback processing is failing

Why is the GPO explicitly marked as 'Denied' in the gpresult output?

Denied due to 'Access Denied (Security Filtering)' or missing Read permissions following security updates
Denied due to 'WMI Filter (Evaluated to False)' or WMI repository diagnostic errors

Fix MS16-072 Security Filtering and Grant Domain Computers Read Permissions

Solution:

Root Cause: Missing Read Permissions for Machine Account (MS16-072 Security Update)

Microsoft Security Bulletin MS16-072 changed the security context under which User Group Policy Objects are retrieved. Policies are now fetched using the Computer account context (Domain Computers) rather than the User context. If Authenticated Users was removed from Security Filtering and Domain Computers was not explicitly granted Read permissions, the client rejects the GPO with an 'Access Denied (Security Filtering)' message.

Step-by-Step Fix:

1.Generate Comprehensive HTML Diagnostic Report:

Open Command Prompt as Administrator and run:

cmd
   gpresult /h C:\gpreport.html

Open C:\gpreport.html in a web browser and navigate to User Details > Denied GPOs to confirm the filtering status.

2.Update GPO Delegation in Group Policy Management Console (GPMC):

Open gpmc.msc on a Domain Controller or RSAT management workstation.

Select the affected GPO and click the Delegation tab.

Click Add..., enter Domain Computers, and set permissions to Read (Do NOT grant 'Apply group policy').

3.Verify Security Filtering Configuration:

On the Scope tab, ensure your target User or Group is still listed under Security Filtering with both Read and Apply permissions.

4.Force Policy Refresh on Client:

Run the following command on the target machine:

cmd
   gpupdate /force

Repair WMI Repository and Validate WMI Filter Syntax

Solution:

Root Cause: WMI Filter False Evaluation or Local WMI Repository Corruption

If a GPO relies on a WMI Filter (e.g., checking OS version or hardware architecture), processing will fail if the query returns False or if the client machine's Windows Management Instrumentation (WMI) repository is corrupted. This triggers Event ID 1085 in the Application log.

Step-by-Step Fix:

1.Test WMI Query Locally via PowerShell:

Run the exact WMI query used by the GPO filter (e.g., checking for Windows 11):

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

If the command returns no output or throws an error, the filter query or local WMI database is invalid.

2.Check Local WMI Repository Integrity:

Run the WMI verification tool from an elevated prompt:

cmd
   winmgmt /verifyrepository

3.Salvage and Repair WMI Repository (If Inconsistent):

If the repository is reported as inconsistent, run:

cmd
   winmgmt /salvagerepository

Restart the Management Instrumentation service:

powershell
   Restart-Service winmgmt -Force

4.Re-evaluate Policy Processing:

Force GPO re-processing to test WMI evaluation:

cmd
   gpupdate /target:computer /force

What underlying infrastructure or client-side caching issue is preventing policy settings from applying?

SYSVOL DFS-R replication out of sync (GPT.ini version mismatch between Domain Controllers)
Corrupted local client Registry.pol file or Client-Side Extension (CSE) lockup

Synchronize SYSVOL DFS-R Replication and Resolve GPT.ini Version Mismatches

Solution:

Root Cause: SYSVOL / Active Directory Version Mismatch (GPT.ini Out of Sync)

Each GPO consists of two parts: the Group Policy Container (GPC) stored in Active Directory, and the Group Policy Template (GPT) stored in \\domain.com\SYSVOL. If DFS-R replication stalls between Domain Controllers, the versionNumber in AD won't match the version in GPT.ini. When a client detects a version mismatch, it aborts policy application.

Step-by-Step Fix:

1.Identify the Domain Controller Servicing the Client:

Run gpresult /r and look for Group Policy was applied from: <DC_Name>.

2.Compare GPC and GPT Version Numbers:

Run the following PowerShell command to check GPO versions across all DCs:

powershell
   Get-GPO -Name "Your-GPO-Name" | Select-Object DisplayName, UserVersion, ComputerVersion

Open \\<DC_Name>\SYSVOL\yourdomain.com\Policies\{GPO-GUID}\GPT.ini and verify the Version= integer matches AD.

3.Force DFS-R SYSVOL Synchronization:

On the affected Domain Controller, force DFS-R replication via PowerShell:

powershell
   Update-DfsrReplicatedFolders -GroupName "Domain System Volume" -ReplicatedFolderName "SYSVOL Share"

4.Audit Domain Controller Health with dcdiag:

Verify overall SYSVOL health across domain controllers:

cmd
   dcdiag /test:sysvolcheck /s:DC_Name

Purge Corrupted Client Registry.pol File and Reset Group Policy History

Solution:

Root Cause: Corrupted Local Policy Cache (Registry.pol) or Client-Side Extension Lock

When a client machine encounters an unexpected shutdown during policy processing, the local policy cache files (Registry.pol) located in System32\GroupPolicy can become corrupted. Subsequent gpupdate commands silently fail because the Group Policy Client service (gpsvc) cannot parse the binary registry cache.

Step-by-Step Fix:

1.Stop Group Policy Processing Service (If Responsive) or Open Elevated Prompt:

Open Command Prompt as Administrator.

2.Purge Local Machine and User Policy Caches:

Unhide and delete the corrupted Registry.pol files:

cmd
   del /f /q /a:h "C:\Windows\System32\GroupPolicy\Machine\registry.pol"
   del /f /q /a:h "C:\Windows\System32\GroupPolicy\User\registry.pol"

3.Clear Local Group Policy Registry History Keys:

Run PowerShell to clear the client-side GPO history tracking keys:

powershell
   Remove-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History\*" -Recurse -Force

4.Force Full Re-application with Reboot:

Re-register policies and force a system reboot to re-download fresh GPOs from SYSVOL:

cmd
   gpupdate /force /boot

What timing or processing mode setting is affecting policy execution?

Asynchronous startup processing or Windows Fast Startup skipping Computer policies
Loopback Processing Mode (Replace vs. Merge) misconfiguration on Terminal Servers / VDI

Enforce Synchronous Policy Processing and Disable Windows Fast Startup

Solution:

Root Cause: Asynchronous GPO Processing and Windows Fast Startup (Hybrid Boot)

By default, Windows uses Asynchronous Processing combined with Fast Startup. The OS presents the desktop login prompt before the network interface completely initializes. As a result, Computer policies requiring a active network connection (e.g., Software Installation, Drive Maps, Folder Redirection) are skipped until the second or third reboot.

Step-by-Step Fix:

1.Enable Synchronous Policy Processing in GPO:

In GPMC, edit a GPO linked to the Computer OU.

Navigate to: Computer Configuration > Administrative Templates > System > Logon.

Enable Always wait for the network at computer startup and logon.

2.Disable Windows Fast Startup via Registry or Command Line:

Run Command Prompt as Administrator to turn off hibernate/fast boot:

cmd
   powercfg /h off

Alternatively, set the registry DWORD value to 0:

cmd
   reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power" /v HiberbootEnabled /t REG_DWORD /d 0 /f

3.Test Policy Execution on Startup:

Restart the client machine twice to confirm synchronous processing enforces settings prior to user logon:

cmd
   shutdown /r /t 0

Configure User Group Policy Loopback Processing Mode Correctly

Solution:

Root Cause: Loopback Processing Mode Mismatch on Multi-User / VDI Hosts

Loopback Processing directs Windows to apply User GPOs linked to the Computer's Organizational Unit (OU) when users log into specific hosts (e.g., Remote Desktop Session Hosts or VDI desktops). If Loopback is disabled or set to the wrong mode (Replace vs. Merge), user settings linked to the computer account fail to apply or overwrite essential domain user settings.

Step-by-Step Fix:

1.Audit Loopback Configuration in GPMC:

Navigate to: Computer Configuration > Administrative Templates > System > Group Policy.

Open Configure user Group Policy loopback processing mode.

2.Select the Correct Loopback Mode:

Merge Mode: Combines User GPOs from the Computer OU with User GPOs from the User OU (Computer OU GPOs take precedence in conflict).

Replace Mode: Completely ignores User GPOs from the User OU and ONLY applies User GPOs linked to the Computer OU.

3.Verify Active Loopback State on Target Host:

Run gpresult /h C:\loopback_test.html on the server.

Inspect the Component Status section for Group Policy Infrastructure to verify that Loopback Mode is active and evaluating correctly.

4.Force Immediate Session Refresh:

Execute a forced update to refresh user configuration:

cmd
   gpupdate /target:user /force

Related Diagnostic Guides

Windows 11 Wi-Fi Connected but No Internet? How to Fix It

Google Account Suspicious Activity? How to Check for Unknown Devices

Microsoft Account Hacked? How to Recover and Secure Your Account

Fast Charging Not Working? How to Check USB PD and Quick Charge Support

Laptop Using Integrated Graphics Instead of Dedicated GPU? Here's How to Fix It

Subscribe to StepDiag

Embed Guide on Your Website