Group Policy Not Applying to Users or Computers: A Systematic Diagnosis

Start Here: Confirm the Basics

Before running any diagnostic tools, confirm:

Has enough time passed? Group Policy applies at startup (computer policy) and at logon (user policy) by default. Background refresh runs every 90 minutes with a random offset of up to 30 minutes. Use gpupdate for an approved refresh and read its completion result. Some settings require logoff or restart; two minutes is not a universal completion threshold. gpupdate /force reapplies all settings and can trigger additional processing.
Is the object in the right OU? Confirm the user or computer is in the OU where the GPO is linked (or a child OU). Open ADUC and verify. Domain links can be affected by inheritance, security/WMI filtering and disabled settings; inspect the effective scope.
Is the GPO enabled? In the GPMC, open the GPO's scope and confirm the link is enabled and the GPO status is not set to "All Settings Disabled".

If all three are confirmed and the policy is still not applying, proceed to the diagnostic steps below.

Scope and prerequisites

This guidance is for domain Group Policy on supported Windows clients and Windows Server. The recorded evidence in Step 1 is one home-lab computer RSoP from 26 September 2026, not a full estate survey. Other examples and output on this page are illustrative. Use a management workstation with RSAT/GPMC and delegated rights for the affected scope. Collect user results in the affected user context; computer results may require elevation. Back up a GPO and record its links, filters and delegation before an authorised change.

Step 1: Run gpresult

The fastest way to confirm what a client received:

CMD

REM Run in the affected user context; use elevation for computer results.
gpresult /R

REM Create a restricted diagnostic directory first.
if not exist C:\Temp mkdir C:\Temp
gpresult /H C:\Temp\gpresult.html /F

Open the HTML report and look at:

Applied GPOs: The GPO should appear here
Denied GPOs: If your GPO appears here, the reason tells you why it was filtered

If no relevant results appear, first confirm the requested user/computer scope and whether RSoP data exists for that session. Then investigate processing errors and DC access. Empty results alone do not diagnose a connectivity failure.

Recorded evidence (26 Sep 2026)

One home-lab computer RSoP. It records one applied GPO and one denied GPO. It is not a user-policy result and it is not a full estate survey. The capture note was: found denied (Security filter).

Redacted excerpt:

Field	Recorded value
Section	Computer
Applied	PCs_Default_WiFi - Baseline W11
Denied	PCs_Group_Edge - Keeper Password Manager
Reason	Access Denied

Step 2: Check the Denied GPOs Reason

Reason shown	Meaning	Fix
Access Denied	Object does not have Read + Apply Group Policy permissions on the GPO	Check Security Filtering in GPMC — add the object's group or the object itself
WMI Filter	The WMI filter evaluated to false on this client	Test the WMI query manually (see below)
Disabled	The GPO or link is disabled	Re-enable
Out of Scope	Object is not in the linked OU	Move object or link GPO to correct OU

Step 3: Test WMI Filters Manually

If a WMI filter is the culprit, test the WMI query on the affected device:

PowerShell

# Example: Check if a WMI filter for Windows 11 is working
Get-CimInstance -Query "SELECT * FROM Win32_OperatingSystem WHERE Caption LIKE '%Windows 11%'"

If this returns no results, the filter is correctly excluding the device — but that may not be what you intended.

Common WMI filter pitfalls:

WMI queries that check OS build number may use Version (e.g. 10.0.26100) rather than Caption. Confirm your query returns results before relying on the filter.
WMI filters are evaluated on the client — capture query errors and processing events instead of treating an empty result or timeout as proof of corruption.

Step 4: Check the Client Event Log

Navigate to:

Event Viewer > Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational

Start with the Group Policy error in the System log and record its timestamp, error details and ActivityID. Correlate that processing instance with GroupPolicy/Operational events. Event 1006 concerns LDAP authentication/bind failures; its error details distinguish causes such as credentials and name resolution. It does not by itself prove that the DC is unreachable. Event 7017 is not a universal “processing started” marker.

Use Microsoft's Group Policy troubleshooting procedure to follow the matching processing instance. Preserve the original logs before repeating a refresh; filtering unrelated event IDs from only one channel can omit the cause.

Step 5: Slow-Link Detection

Windows applies only a subset of Group Policy CSEs (Client Side Extensions) over slow links by default. If the client considers its connection to a DC as "slow", some policy settings — including Folder Redirection, Software Installation, and Scripts — may be skipped.

How to check if slow-link is triggering:

CMD

gpresult /R

Look at the header output for the line:

Group Policy was applied from: DC01.corp.example.com
Group Policy slow link threshold: 500 kbps
The computer is not using a slow link connection.

If you see "slow link detected", the client measured bandwidth below the threshold during the GP processing window.

Fix options:

Inspect the slow-link threshold GPO setting: Computer Configuration > Administrative Templates > System > Group Policy > Configure Group Policy slow link detection — the default is 500 Kbps. Raising the threshold classifies more connections as slow, so it is not a general fix. Investigate site selection, latency and bandwidth first. See Group Policy processing.
Enable specific CSEs to always process over slow links: Individual CSE settings (e.g., Always process the script policy settings) are available in the same Administrative Templates path.

Step 6: Check DC Connectivity and Replication

If logs indicate DC discovery or policy-read failure, check the affected client and the DC that served it. A newly changed GPO can also differ between DCs while replication is incomplete.

Confirm DC connectivity from the client:

CMD

nltest /dsgetdc:corp.example.com /force
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com

If nltest fails, the client cannot locate a DC. Check:

DNS resolution is pointing to an AD-integrated DNS server
The client is in the correct site in AD Sites and Services
No firewall is blocking Kerberos (TCP/UDP 88) or LDAP (TCP 389) to domain controllers

Check GPO replication health on the DC side:

CMD

REM Run with delegated read access from an approved AD management host.
repadmin /replsummary
repadmin /showrepl

Look for replication failures or high latency. If the GPO was created or modified on DC01 but the client is processing from DC02, and replication between them has failed, DC02 will serve an older version of the policy.

Ask the AD service owner to investigate replication failures, including the GPO's AD metadata and SYSVOL content. Do not force forest-wide replication as a routine client diagnostic. After the underlying fault is resolved, repeat policy processing on one affected client and compare versions and results.

Step 7: Loopback Processing and Inheritance Blockers

If the above steps do not reveal the cause:

Check if Block Inheritance is set on the OU: GPMC > OU > right-click > check for the grey shield icon
Check if an Enforced GPO higher in the hierarchy is overriding your setting: Enforced GPOs win over Block Inheritance
Check if Loopback Processing is enabled elsewhere and replacing user policies with computer-OU policies

Using the RSoP Wizard (GPMC Alternative)

In GPMC, right-click Group Policy Results and run the Group Policy Results Wizard for the affected computer and user. This queries recorded results, subject to remote access and permissions. Group Policy Modeling simulates a proposed scenario; it is not evidence that settings actually applied. If remote queries are unavailable, collect gpresult /H on the client.

See gpresult documentation for supported switches and permissions. Check the effective local setting as well as its reported winning GPO.

Backing up and restoring a GPO before you change it

Before you edit a GPO that looks like the cause, take a backup:

PowerShell

New-Item -ItemType Directory -Path C:\GPOBackups -Force | Out-Null
Backup-GPO -Name "CIS-Win11-Level1-Computer" -Path C:\GPOBackups -ErrorAction Stop

Secure the backup directory and record the returned backup ID plus the current links, filtering and delegation. Restoration is a separate write operation: choose the intended backup and review its impact before using Restore-GPO. Recheck scope and effective settings afterwards; taking a backup must not immediately restore old settings.

Validation and limitations

Compare the report before and after the scoped correction, including the winning GPO for the specific setting. Validate actual behaviour on the affected computer/user and a control device. Logoff or restart only when the setting requires it and the interruption is approved.
Local Group Policy exists on standalone machines and can affect local accounts. This article's domain-link and replication checks concern AD domain GPOs.
For filtered user GPOs, the computer also needs permission to read the GPO. Removing Authenticated Users requires preserving an appropriate computer Read permission; do not add Apply permission to every computer as a shortcut. See Microsoft's user policy retrieval guidance.
RSoP is recorded policy data, not a complete view of every mechanism that writes a setting. Intune, scripts and application configuration can affect behaviour outside the reported GP result.
If a pilot change regresses other settings, restore the specific approved configuration from the recorded backup and revalidate its scope. Do not move production objects between OUs merely to test inheritance.

Correction record

26 September 2026 — Home-lab, computer RSoP only: Added one redacted computer RSoP. One GPO was applied (PCs_Default_WiFi - Baseline W11) and one was denied (PCs_Group_Edge - Keeper Password Manager) with reason Access Denied (security filter). This is not a full estate survey.

10 September 2026 — Reviewed against documentation: Corrected event interpretations, slow-link threshold direction, SRV lookup and GPMC workflow. Removed routine forced replication and immediate restore commands. The earlier RSoP consolidation and redirect remain in place.