Fix Group Policy Not Applying in Windows

The short answer

First force a refresh: open an elevated prompt and run gpupdate /force, then sign out or restart if it asks. If the setting still isn't there, find out why rather than guessing — run gpresult /r for a summary or gpresult /h report.html for a full report, and look at which GPOs applied and which were denied. The denial reason (out of scope, filtered out, or access denied) tells you exactly where to look next.

Group Policy that won't apply is one of the more frustrating Active Directory problems, because nothing is obviously broken — the GPO exists, it looks linked, yet the setting never lands on the machine. The trap is reaching for gpupdate /force over and over. Forcing a refresh only reapplies the policies that already reach the target; it can't deliver a GPO that scope or filtering is quietly excluding.

This guide works the problem the way a domain administrator does: refresh, then read the evidence with gpresult, then check the handful of things that actually stop a policy applying — the link and organizational-unit scope, security filtering, WMI filters, replication and SYSVOL, slow-link detection, and the loopback processing that catches people out on shared machines.

The Group Policy fix order — diagnose with gpresult before changing anything.

Step 1 — Force a refresh with gpupdate

Windows refreshes Group Policy in the background on a schedule, so a change you just made may simply not have been picked up yet. Force it:

gpupdate /force

/force reapplies all settings rather than only the ones that changed — the gpupdate command reference on Microsoft Learn is explicit that by default only changed settings are applied. If a policy requires sign-in or start-up to take effect (many do), Windows will offer to log you off or restart — accept it. You can target one side only:

gpupdate /force /target:computer
gpupdate /force /target:user

If the setting appears after this, you were just waiting on the refresh cycle. If it still doesn't, stop forcing and start diagnosing.

Step 2 — Read the result with gpresult

gpresult reports the Resultant Set of Policy — what actually applied to this machine and user, and, crucially, what was denied and why. This is the single most useful tool for this problem; the gpresult command reference lists /r for summary RSoP data and /h for an HTML report.

Open Command Prompt or PowerShell as administrator. This matters: without elevation the computer-configuration section is blank and you only see user settings.
For a quick on-screen summary:
```
gpresult /r
```
For the full picture, generate an HTML report and open it in a browser:
```
gpresult /h report.html
```

In the output, read two lists: Applied Group Policy Objects and the denied GPOs with a reason next to each. You also get the site, the organizational unit the account sits in, and the security groups it belongs to. Between them, those answer most "why isn't it applying" questions before you touch anything on the server.

Step 3 — Check the link and OU scope

A GPO only reaches accounts in the container it is linked to — a site, the domain, or an organizational unit (OU) — and the OUs beneath it. The most common mistake is linking a policy to the wrong OU, or editing the right-named GPO but linking a different one.

Confirm where the account really is. The gpresult report shows the OU the user and computer are in. A user object and a computer object can live in completely different OUs — and computer settings only apply to the computer's OU, user settings only to the user's.
Check the link is enabled. In the Group Policy Management console, a link can exist but be disabled; a disabled link does nothing.
Watch for Block Inheritance and Enforced. An OU set to block inheritance ignores policies from above it, unless a higher link is marked Enforced, which overrides the block.

Step 4 — Check security filtering and WMI filters

If a GPO is correctly linked but still denied for some targets, filtering is the usual reason.

Security filtering. For a GPO to apply to an account, that account (or a group it is in) needs both Read and Apply group policy permission on the GPO. If you added a group to security filtering but it lacks Apply, or you removed Authenticated Users without granting the replacement group Read, the policy silently won't apply. The gpresult report flags this as an access-denied / filtering denial.

WMI filters. A GPO can carry a WMI filter — a query that must return true on the target for the policy to apply. A filter such as "only 64-bit Windows 11" will correctly skip everything else, which looks like a failure if you forgot the filter was there. Check whether the denied GPO has a WMI filter attached, and test that the query actually matches your target.

Don't just delete Authenticated Users

Since the MS16-072 security update, Group Policy is retrieved in the computer's security context. If you tighten security filtering by removing Authenticated Users, make sure the computer accounts (for example via Domain Computers) still have at least Read on the GPO, or the policy can stop applying for everyone. Microsoft's troubleshooting article on user GPOs failing when computer objects lack Read permission walks through exactly this failure and its fix.

Step 5 — Check replication and SYSVOL

Every GPO has two halves: the Group Policy container in Active Directory and the Group Policy template — the actual files — stored in the SYSVOL share on each domain controller. Clients read policy from whichever domain controller they contact, so if your edits haven't replicated, a client talking to a lagging DC gets stale or missing policy.

Event ID 1058 in the System log is the classic sign: Windows could not read the gpt.ini file from SYSVOL, usually from a replication, connectivity or permissions problem on the policy template.
Confirm the client can reach the SYSVOL path \\<domain>\SYSVOL\<domain>\Policies\ and that replication between domain controllers is healthy before testing again.
Give replication time to converge, or force it, then re-run gpupdate /force and gpresult.

Step 6 — Slow-link detection and loopback gotchas

Two behaviours regularly explain policy that applies "sometimes" or "not the way I expected".

Slow-link detection. Group Policy measures the connection to the domain controller, and over a link it judges slow, some client-side extensions — notably software installation and folder redirection — are skipped to avoid crippling the session. A VPN or a congested branch link can trip this, so a policy that works in the office may not apply remotely.

Loopback processing. Normally user settings follow the user and computer settings follow the computer. Loopback changes that: it makes a computer apply user-side policy based on the computer's location — common on terminal servers, kiosks and lab machines. In Replace mode it discards the user's normal GPOs and applies only those linked to the computer's OU; in Merge mode it combines both. If user settings vanish or double up on shared machines, check whether loopback is enabled and which mode it uses.

Dig deeper in the event log

For anything the reports don't explain, the Group Policy Operational log has a per-cycle record of processing: Event Viewer › Applications and Services Logs › Microsoft › Windows › GroupPolicy › Operational. It lists applied and denied GPOs with reasons and timing for each refresh, which is invaluable for intermittent failures.

Group Policy event ID reference

The System log names the failure for you. Each of these events also carries an error code on its Details tab, and that code — shown as a decimal — is what turns "policy failed" into a specific thing to fix. The event descriptions and the error-code meanings below are Microsoft's own, from the Applying Group Policy troubleshooting guidance on Microsoft Learn.

Event ID	What the event says	What it points at
1058	Windows attempted to read the file from a domain controller and was not successful.	It can't read the policy template from SYSVOL — name resolution or connectivity to the DC, replication latency, or the DFS client disabled. Check the Details error code: 3 = the system cannot find the path specified, 5 = access is denied, 53 = the network path wasn't found. Step 5.
1030	Windows attempted to retrieve new Group Policy settings for this user or computer.	The client couldn't fetch policy from Active Directory. Microsoft's first check is whether the LDAP ports are open — on the firewall, and locally on both the client and the domain controller.
1129	The processing of Group Policy failed because of lack of network connectivity to a domain controller.	No usable path to a DC when policy ran — typically the network wasn't ready at start-up, or LDAP port 389 is blocked. Microsoft notes this may be a transient condition that clears once the machine reaches a DC.
1006	Windows could not authenticate to the Active Directory service on a domain controller (LDAP bind failed).	An authentication problem, not a scoping one. Details error 5 = access is denied, 49 = invalid credentials (often a password that expired mid-session), 258 = timeout, which usually means the DNS configuration is wrong.
1053	Windows could not resolve the user name.	Name resolution failure on the current DC, or replication latency for a recently created account. Details error 525 = the specified user doesn't exist (often missing read permission on the OU), 1355 = the domain doesn't exist or couldn't be contacted, 1727 = RPC failed, commonly a firewall.
1097	Windows could not determine the computer account to enforce Group Policy settings.	The computer itself couldn't authenticate, so no computer configuration is applied. Check time sync first — a difference greater than five minutes from the DC breaks domain authentication; force it with `w32tm /resync`.
1002	The processing of Group Policy failed because of a system allocation failure.	A resource problem, not a policy problem. Confirm the machine isn't low on memory or disk space, and restart it if it has been running a long time.

Events 1129 and Netlogon's 5719 often appear together on machines that start faster than the network does; Microsoft's article on Netlogon event 5719 or Group Policy event 1129 covers that specific race between network initialisation and policy processing, including the Group Policy start-up wait-time settings that fix it.

Related Windows Server guides

Building the policies in the first place? See how to create and link Group Policy objects and how to set up Active Directory on Windows Server. If clients are being rejected by the domain entirely, that's a different problem — see fixing the trust relationship failed error.

Frequently asked

Why is my Group Policy not applying even after gpupdate /force?

gpupdate /force only reapplies the policies that already reach the machine or user; it cannot deliver a GPO that is being filtered out or is not in scope. If a setting still does not appear, the cause is almost always higher up: the GPO is not linked to the organizational unit that actually contains the account, its link is disabled, security filtering or a WMI filter is excluding the target, or the change has not replicated to the domain controller the client is using. Run gpresult to see which GPOs were applied and which were denied, and the report will tell you which of these is happening.

How do I see which Group Policies are actually being applied?

Use gpresult, the built-in Resultant Set of Policy tool. Open an elevated command prompt or PowerShell and run gpresult /r for a text summary, or gpresult /h report.html to generate a full HTML report you can open in a browser. Run it elevated, because without administrator rights the computer configuration section is blank and only user settings are shown. The report lists the applied GPOs, the denied GPOs with the reason for each denial, the site, the organizational unit the account sits in, and the security groups it belongs to, which is usually enough to explain why a policy is or is not taking effect.

Why does a GPO apply to some users or computers but not others?

Uneven results almost always come from scope and filtering rather than a broken policy. Check three things. First, security filtering: the account must be in a group that has both Read and Apply group policy permission on the GPO. Second, any WMI filter attached to the GPO, because the policy only applies where the filter query returns true, so a filter targeting a particular Windows build or hardware type will skip everything else. Third, the organizational unit structure, since a GPO only reaches accounts in the OU it is linked to and those beneath it. gpresult on an affected machine names the denied GPO and the reason, which points you straight at the culprit.

Can a replication or SYSVOL problem stop Group Policy applying?

Yes. A GPO has two parts: the Group Policy container in Active Directory and the Group Policy template stored in the SYSVOL share on each domain controller. If your edits have not replicated, or SYSVOL is not in sync between controllers, a client talking to a lagging domain controller sees stale or incomplete policy. The classic symptom is Event ID 1058 in the System log, meaning Windows could not read the gpt.ini file from SYSVOL. Confirm replication is healthy, check that the client can reach the SYSVOL path, and allow time for or force replication before testing again.

Why do my user settings disappear on a terminal server or kiosk?

That is usually loopback processing. Group Policy loopback makes a computer apply user-side settings based on the computer's location rather than the user's, which is common on terminal servers, kiosks and lab machines. In Replace mode it discards the user's normal GPOs entirely and applies only the ones linked to the computer's organizational unit, so familiar user settings vanish; in Merge mode it combines both. If user policy behaves unexpectedly on these machines, check whether loopback is enabled and which mode it uses, because it changes which GPOs are even considered.