Group Policy Processing Explained

A single computer or user account is almost always covered by more than one Group Policy Object at once — a domain-wide baseline, maybe a site-specific policy, and one or more OU-linked policies that get progressively more specific. Most of the time these simply combine without conflict. When they do conflict, Windows resolves it through a completely deterministic set of rules — LSDOU order, per-level link order, Block Inheritance, and Enforced links — that are precise but easy to get backwards from memory once more than two or three levels are involved. This post covers exactly how that resolution works.

LSDOU: broadest to most specific

Group Policy processes in a fixed order — Local, Site, Domain, then Organizational Units from the top-level OU down to the one actually containing the object (nested OUs process parent-to-child). By default, later-processed settings overwrite conflicting earlier-processed ones — which is why, absent any other rule, an OU-linked GPO wins over a Domain-linked one, which wins over a Site-linked one, which wins over Local policy.

Link order: multiple GPOs at the same level

A single container can have several GPOs linked to it, each with its own link order number. Confusingly at first glance, link order 1 has the highest precedence, not the lowest — Windows numbers link order so that the GPO you want to win is the one you move to position 1, read naturally as "this one matters most," even though internally it's processed last among that container's links.

Block Inheritance: cutting off everything above

Domain (Password Policy GPO)
  └─ Sales OU  [Block Inheritance: ON]
       └─ EU Sales OU (inherits from Sales OU's blocked state)

An OU administrator can set Block Inheritance to prevent GPOs linked at any level above that OU — Domain, Site, or a parent OU — from applying there at all. It's an all-or-nothing switch for everything above, not a way to selectively exclude one specific GPO while keeping others. Critically, it doesn't just affect that one OU — it affects everything nested beneath it too, unless something more specific overrides it further down.

Enforced: the domain administrator's override of that override

Enforced (previously called "No Override" in older Windows terminology) is the counterbalance: a GPO link marked Enforced applies even to an OU that has Block Inheritance turned on. This exists specifically so a domain administrator can guarantee a genuinely important setting — a minimum password length, a critical security baseline — can't be quietly bypassed by a delegated OU administrator's local configuration choices, while still letting that OU administrator freely customize everything else.

The one rule that reverses: Enforced-vs-Enforced

This is the genuinely counterintuitive part. For ordinary (non-Enforced) GPOs, the setting closest to the actual object wins — more specific beats more general. For Enforced GPOs specifically, that logic flips: when two Enforced GPOs conflict, the one set higher in the hierarchy (closer to the domain root) wins, not the one closer to the OU. The reasoning follows from what Enforced is actually for — a centrally-mandated policy that's meant to hold regardless of what's configured downstream, so a more centrally-set Enforced policy should still win over a more locally-set Enforced one.

Putting it together: an example

Domain:  "Default Domain Policy"      (link order 1, not enforced)
Domain:  "Baseline Security"          (link order 1, Enforced)
Sales OU: Block Inheritance = ON
Sales OU: "Sales Restrictions"        (link order 1, not enforced)

Working through the rules: Block Inheritance at Sales OU would normally cut off both Domain GPOs — but "Baseline Security" is Enforced, so it applies anyway. "Default Domain Policy" is not Enforced, so it's genuinely blocked. Final precedence for conflicting settings: Baseline Security (Enforced, so it outranks everything non-Enforced regardless of level) wins first, then Sales Restrictions (the only other GPO that actually applies here). "Default Domain Policy" contributes nothing to this OU at all.

Two more filters, applied before LSDOU even matters

LSDOU, link order, Block Inheritance, and Enforced all determine precedence among GPOs that already apply to a given object — but two separate mechanisms determine whether a GPO applies at all in the first place, independent of any of that. Every GPO has a discretionary access control list controlling who it applies to via security filtering: by default "Authenticated Users" has both Read and Apply Group Policy permissions, but scoping a GPO to a specific security group instead is common practice for anything that should only affect a subset of the users or computers in its linked container. Separately, a WMI filter attached to a GPO makes its application conditional on a WMI query's result evaluated at processing time — commonly used for hardware- or OS-version-specific policies, like a GPO that should only apply to laptops or to a specific Windows build. A GPO that looks correctly linked and correctly prioritized can still silently not apply to a specific object because of either of these, unrelated to anything about processing order.

Confirming what actually applied

gpresult /h report.html /f

Rather than reasoning through LSDOU, Block Inheritance, Enforced links, security filtering, and WMI filters by hand for a real object, gpresult generates an actual RSoP (Resultant Set of Policy) report — the genuinely applied, already-resolved outcome for a specific user or computer, including which GPOs were filtered out and why. It's the authoritative way to confirm a real-world result matches what the rules predict, and the first thing worth running when a policy doesn't seem to be taking effect the way the processing rules suggest it should.

Common mistakes

• Assuming Block Inheritance blocks Enforced GPOs too. It specifically doesn't — that's the entire purpose Enforced exists to serve.
• Debugging a "GPO isn't applying" problem purely through LSDOU logic. Security filtering and WMI filters are a separate, earlier gate — a GPO excluded by either one never even reaches the precedence rules.
• Reading link order 1 as "processed first, so it loses." It's the opposite — link order 1 has the highest precedence within its level.
• Applying normal precedence logic to Enforced-vs-Enforced conflicts. That one specific case reverses to favor the higher, more centrally-managed link.
• Forgetting that Block Inheritance affects every nested OU below it too, not just the one OU where it was actually set.

FAQ

Try it yourself

GPO Precedence Calculator works through exactly this logic — LSDOU order, link order, Block Inheritance, and Enforced links — for your own set of levels and GPOs, entirely in your browser.