Group Policy processing order, and the settings that quietly lose

“The GPO is not applying” is almost always wrong. The GPO usually applied perfectly and then something applied after it. Group Policy has no conflict resolution beyond order of application, so the last writer wins and nothing anywhere logs an apology.

The symptom

Someone reports that a setting is not taking effect. The GPO exists, it is linked, the user is in the right organisational unit, and gpupdate /force changes nothing. On one machine the setting is right; on another it is not.

Before touching anything, establish which of three things you have:

• The GPO did not apply at all — filtered out, blocked, or the client failed to process it.
• The GPO applied and lost — another GPO set the same policy later.
• The GPO applied and worked, but the setting does not do what the person assumed.

These have completely different investigations, and gpresult tells you which one you are in within a minute.

The order everything depends on

Group Policy objects apply in LSDOU order: Local, then Site, then Domain, then organisational unit, descending through nested OUs. Later application overwrites earlier, so the GPO closest to the object normally wins.

Within a single container, link order decides. This is where people misread the interface: link order 1 has the highest precedence, because the list is applied bottom-up. The GPO at the bottom of the list applies first and the one at the top applies last, so the top one wins.

Two modifiers sit on top of that:

• Enforced is a property of the link. It promotes that GPO so lower containers cannot override it, and it survives blocked inheritance.
• Block inheritance is a property of the container. It stops higher-level GPOs applying to that container — except enforced ones.

Enforced beats block inheritance. If you remember one rule from this article, that is the one, because the two controls are usually configured by different people years apart.

Diagnosis

Get the resultant set of policy, not an opinion

gpresult /h C:\Temp\rsop.html /f
gpresult /r /scope:computer

Run it as the affected user for user settings, and elevated for computer settings — gpresult /r for the current user does not show computer policy unless you ask for it.

The HTML report is the useful one. It has three sections that answer the whole question: applied GPOs, denied GPOs with the reason, and — most valuable — the winning GPO named beside each individual setting. If your GPO appears in the applied list but another GPO’s name sits next to the setting, you have a precedence problem, not a delivery problem.

For a user and computer combination you cannot sign in as, use the planning mode in the Group Policy Management Console rather than guessing.

Read the denial reason

The denied list gives a reason, and each reason points somewhere specific:

Reason	What to check
Access denied (security filtering)	The principal needs both Read and Apply Group Policy
WMI filter false	Evaluate the filter against the actual target
Empty	The relevant half of the GPO has no settings
Disabled link, or disabled user/computer configuration	The link and the GPO status
Not applied (unknown reason)	Client-side processing failure — go to the event log

Security filtering deserves its own note. Since the MS16-072 change, Group Policy objects are retrieved in the computer’s security context rather than the user’s. If someone removed Authenticated Users from a GPO and granted Apply to a user group only, the computer account may no longer be able to read the GPO, and a user-targeted policy silently stops applying. The fix is to leave Authenticated Users, or at minimum Domain Computers, with Read, and control targeting with Apply Group Policy instead.

Go to the Group Policy operational log

For genuine processing failures, the client-side evidence lives in Microsoft-Windows-GroupPolicy/Operational:

• 4001 — policy processing started for a user or computer.
• 5312 — the list of GPOs that will be applied, in order. This is the single most useful event in the log, because it is the client’s own account of precedence.
• 8000 and 8001 — computer and user policy processing completed, with total time.

In the System log, three classics remain:

• 1058 — could not read gpt.ini from SYSVOL. Almost always name resolution, SYSVOL replication or share permissions.
• 1030 — failed to retrieve policy.
• 1085 — a client-side extension failed to apply its settings. The event names the extension, which tells you which part of the GPO to look at.

Interpretation: the ways settings quietly lose

Loopback processing, forgotten. A GPO on the computer’s organisational unit with loopback in Replace mode discards the user’s own GPOs entirely and applies the user settings from the computer’s OU path instead. In Merge mode, the computer’s user settings apply after the user’s own, so they win. Loopback is frequently applied to terminal servers or kiosks years earlier and then forgotten. If user settings behave differently on one set of machines, check loopback before anything else.

Preferences versus policies. Group Policy Preferences with “Apply once” or without “Remove this item when it is no longer applied” tattoo the registry. The value persists after the GPO stops applying, so a machine can show a setting that no current GPO delivers. True policy settings live under the Policies keys and are removed cleanly when they go out of scope. A setting that survives unlinking the GPO was a preference.

Two GPOs at the same level. Link order decides, and it is the most common cause of “it works for that department but not this one”.

Refresh timing. Clients refresh every 90 minutes with a random offset of up to 30 minutes; domain controllers refresh every 5 minutes. Some settings — drive mappings, folder redirection, software installation — only process at logon or startup, so gpupdate /force genuinely does not apply them. That is not a fault.

Slow link detection. Where a link is measured as slow, some extensions skip processing. On a branch connection, this produces a machine that is correct at head office and wrong at the branch with no error anywhere.

Resolution, in order of preference

Fix precedence rather than adding another GPO. Adding a higher-precedence GPO to defeat one you do not understand is how estates reach two hundred objects that nobody can reason about.

1. Find the winning GPO in the HTML report and decide whether it should win. Usually the answer is that it should not, and it is an old link nobody removed.
2. Change link order or unlink, rather than duplicating the setting.
3. Use Enforced sparingly and deliberately. It is the right tool for a genuine non-negotiable security baseline at the domain level. It is the wrong tool for winning an argument with another GPO.
4. Avoid block inheritance unless you own the whole subtree and have documented why. It makes future troubleshooting much harder because it hides GPOs that appear linked.
5. Consolidate. Two GPOs setting the same policy in opposite directions is a design fault, not a precedence puzzle.

Validation

Re-run gpresult /h after the change and confirm the winning GPO beside the specific setting, not just the applied list. Then confirm the setting’s actual effect — the registry value, the mapped drive, the firewall rule — because a GPO can win and still be configured wrongly.

Check at least two machines in different organisational units and, if you have branch sites, one across a slow link. A single successful test on the machine you were already debugging proves less than it appears to.

Keeping it readable

Two habits keep this estate manageable. Name GPOs so the name states scope and intent, and write the reason for the link into the GPO’s comment field. When someone asks in three years why a setting wins, the answer should be in the directory rather than in whoever is still employed.

The same discipline applies to the administrative accounts that can edit these objects. A GPO linked to the domain controllers organisational unit is equivalent to code execution on every domain controller, which is why it belongs in Tier 0.

Verification and limits

Processing order, enforcement, loopback behaviour, event IDs and refresh intervals were checked against current Microsoft documentation on 20 September 2026. The diagnostic sequence is how I work through these reports.

Nothing here was executed in a lab for this article. Link order and enforcement changes take effect estate-wide at the next refresh, so make them in a maintenance window with a record of the previous configuration. gpresult output contains account and organisational unit names — treat the HTML report as sensitive and do not attach it to a public ticket.

References

• Group Policy processing for Windows
• Group Policy scope in Windows
• Applying Group Policy troubleshooting guidance
• Get-GPInheritance