Most Group Policy troubleshooting starts from the wrong question. An operator opens GPMC, sees three or four GPOs linked at different levels, and asks “why isn’t my setting applying?” The more useful question is “which GPO actually wins here, and why?” Many Group Policy troubleshooting workflows assume the reader already understands that calculation. This guide makes it explicit before moving into filtering or client-side diagnostics.
This guide shows how Windows calculates precedence, how Enforced and Block Inheritance alter the normal path, and how to confirm the winning GPO before changing production links.
- Group Policy processing order builds scope as Local, Site, Domain, and OU, with parent OUs processed before child OUs.
- When applicable GPOs configure the same setting, the GPO with higher precedence normally supplies the winning value – usually the one processed later.
- Within one site, domain, or OU, the link with the lowest link-order number has the highest precedence. Link Order 1 is processed last at that container.
- Enforced is a link property that can reverse the normal winner. Block Inheritance is a domain or OU property that changes which inherited GPOs are eligible to apply – the two are not interchangeable.
- Link status, GPO status, security filtering, and WMI filtering decide whether a GPO is eligible to apply. Loopback processing rebuilds the user-side GPO list and can change effective precedence on its own.
- Use Group Policy Results in GPMC or
gpresult /has primary evidence for the winning GPO. Treatrsop.mscas a supplementary, incomplete view.
The examples below assume both GPOs are enabled, pass filtering, contain the relevant User or Computer half, and configure the same setting through a precedence-based client-side extension.
| Situation | Effective result | Reason |
|---|---|---|
| Two GPOs linked to the same OU | Lowest link-order number | It has the highest precedence at that container |
| Domain GPO vs. child-OU GPO | Child-OU GPO | Child OU is processed later in the chain |
| Enforced Domain GPO vs. child-OU GPO | Enforced Domain GPO | Lower-level containers cannot override an Enforced link |
| Parent GPO vs. OU with Block Inheritance | Parent GPO excluded | Non-Enforced inherited links are removed from the applicable list |
| Enforced parent GPO vs. Block Inheritance | Enforced parent GPO | Enforced links survive Block Inheritance |
| GPO link is disabled | That link is excluded | A disabled link never enters the applicable list, even though the GPO object still exists |
| GPO fails security or WMI filtering | GPO is excluded | It never enters the applicable list |
Diagnostic order for finding the winning GPO
Use this sequence as a troubleshooting decision path. It is not a literal trace of every internal Group Policy engine stage; it orders the checks so you can eliminate scope, eligibility, inheritance, and precedence problems efficiently when a setting isn’t behaving the way the link tree suggests it should:
- Is the GPO linked somewhere in the target’s site, domain, or OU path?
- Is that specific link enabled?
- Is the required User or Computer half enabled in GPO Status?
- Does the principal have the required Read and Apply Group Policy permissions?
- Does the WMI filter, if any, evaluate true on the destination computer?
- Does Block Inheritance remove an inherited non-Enforced link?
- Does an Enforced higher-level link retain priority over lower containers?
- Among links on the same container, which has the lowest link-order number?
- Among containers, apply the effective LSDOU hierarchy.
- Does the relevant client-side extension use simple overwrite, cumulative, merge, preference-item order, or another policy-specific rule?
- Confirm the actual winner in Group Policy Results or
gpresult.
The rest of this guide explains each factor in the same diagnostic order.
Group Policy processing order: separate Computer and User paths
Windows builds computer and user policy separately. Computer Configuration follows the computer account’s site, domain, and OU path. Normal User Configuration follows the user’s domain and OU path while using the site of the computer where the user signs in. Loopback is the exception: it adds or replaces user-side GPOs based on the computer’s location instead.
Within each path, the baseline order is Local, Site, Domain, and OU. Parent OUs process before child OUs. Microsoft documents this as the baseline processing model for currently supported Windows Server versions. The effective list can still change through disabled links or GPO sections, filtering, Enforced, Block Inheritance, loopback, and client-side extension rules – LSDOU is the starting hierarchy, not a guarantee that nothing downstream can alter the result.
Do not combine Computer Configuration and User Configuration links into one global link-order list. Each side is processed through its own scope, and link order only resolves conflicts among links at the same container within that side. If a policy area exposes both computer and user variants, the computer-side setting or a policy-specific rule can take precedence – verify that setting’s actual behavior rather than comparing unrelated link-order numbers.
Local is itself a simplified label. On supported client and member-server systems, Multiple Local GPOs can process as Local Computer Policy, then Administrators or Non-Administrators policy, then user-specific policy. Domain controllers do not support Multiple Local GPOs.
For a typical registry-based Administrative Template setting, the applicable GPO with the highest effective precedence supplies the winning value – usually the one processed later in the chain, unless Enforced or a policy-specific processing rule changes the result. Some client-side extensions merge, accumulate, or process items with their own rules, so confirm the actual result instead of treating every policy area as a simple last-write operation.
How link order works within one container
LSDOU handles precedence between levels. Link order handles precedence within a single container. It’s common to have three or four GPOs linked to the same OU, and GPMC’s Linked Group Policy Objects tab shows them in a numbered list.
This is the part that reads backwards the first time: within one site, domain, or OU, the link with the lowest link-order number has the highest precedence. Link Order 1 is processed last at that container, so it normally wins when another applicable GPO on that container configures the same setting.
Link Order 4 is processed earlier and loses that specific conflict to a higher-precedence link. Operators who assume “Link Order 1 = processed first = loses to everything after it” get exactly the opposite result, then spend time debugging a GPO that was never broken.
Practical takeaway:
- To give an otherwise applicable GPO the highest precedence among links on that container, move it to Link Order 1 – not the bottom of the list. Filtering, Enforced links at other levels, disabled sections, and client-side extension rules can still change the effective result.
- Link order resolves precedence only among GPO links on the same container. Do not compare link-order numbers across a domain and an OU; cross-container precedence follows the LSDOU hierarchy together with any applicable Enforced links.
- Renaming a GPO does not affect precedence. Deleting and recreating a link can change its link-order position, so always verify the order after re-linking a GPO.
How inheritance works across nested OUs
By default, GPOs linked at a parent OU are inherited by child OUs. A user in OU=Helpdesk,OU=Support,DC=ad,DC=example,DC=com receives applicable GPOs linked to Support first, followed by GPOs linked directly to Helpdesk according to the link order configured on that child OU.
Inheritance does not create precedence based on organizational hierarchy on its own. A GPO linked at a grandparent OU doesn’t lose to a GPO at a child OU because the child is more specific in an org-chart sense – it loses because child-OU GPOs process later in the sequence. Same mechanism as before, just extended across nested OUs.
Common causes of “this used to apply and now doesn’t” include an OU move that changed the effective chain, a new higher-precedence or Enforced GPO introducing a conflicting value, security or WMI filtering removing the previous winner, and Block Inheritance enabled somewhere in the chain without anyone checking which inherited settings depended on it. Block Inheritance on an intermediate parent OU is easy to miss when reviewing only the immediate container.
Enforced versus Block Inheritance
This pairing is a frequent source of confused escalations, mostly because the two settings sound like opposites and aren’t scoped the same way.
Enforced is a property of the link, not the GPO object itself. The same GPO can be linked to two different OUs, Enforced at one and not the other. An Enforced link ensures a higher-level GPO cannot be overridden by lower-level containers – it keeps its settings even where a lower-level GPO would otherwise win.
Block Inheritance is a property of the container (a domain or OU), not of any specific GPO or link. Microsoft documents that blocking inheritance on an OU prevents GPOs linked to higher-level sites, domains, and parent OUs from being inherited, unless those links are Enforced. Block Inheritance affects inherited domain-based links only – it does not remove Local Group Policy.
The key exception is that an Enforced site- or domain-linked GPO still applies through an OU with Block Inheritance turned on, even though every other non-Enforced GPO inherited from above is excluded. If a setting from a parent level is still showing up in Group Policy Results on an OU where Block Inheritance is active, checking whether the parent GPO’s link is Enforced is usually the fastest way to close the ticket.
| Feature | Applied to | Main effect |
|---|---|---|
| Link Order | GPO links on one container | Resolves precedence within that container |
| Link Enabled | One GPO link | Determines whether that specific link participates at that container |
| GPO Status | GPO object | Disables all settings, or only the User or Computer half, across every link to that GPO |
| Enforced | One GPO link | Prevents lower containers from overriding its settings |
| Block Inheritance | Domain or OU | Removes non-Enforced GPOs inherited from higher containers |
| Security Filtering | GPO scope | Controls which principals can apply the GPO |
| WMI Filtering | GPO scope | Applies the GPO only when the WMI query evaluates true on the destination computer |
Multiple Enforced links: Enforced does not remove link order. If several Enforced GPOs are linked to the same site, domain, or OU and configure the same setting, the link with the highest precedence – normally the lowest link-order number – wins that conflict.
Link-order numbers are never comparable across different containers, including Enforced links – a Domain link at position 1 and a child-OU link at position 1 are not competing with each other directly. If Enforced links exist at multiple hierarchy levels, inspect the effective precedence list in Group Policy Results or Get-GPInheritance rather than comparing their numeric link orders. Use Enforced sparingly: Microsoft’s own Set-GPLink guidance treats it as a setting that complicates delegation and troubleshooting for anyone working at a lower container later.
Worked example: domain, parent OU, and child OU conflict
Take one Administrative Template setting configured differently by three GPOs:
- Domain Baseline, linked at the domain: setting Disabled
- Parent OU Policy, linked at the parent OU: setting Enabled
- Child OU Exception, linked directly to the child OU: setting Disabled
The applicable list and the winning GPO change depending on inheritance and Enforced status:
- Normal processing, no Enforced links, no Block Inheritance: Child OU Exception wins. The child OU is processed after the parent OU and domain.
- Domain Baseline marked Enforced: Domain Baseline wins. Its setting cannot be overridden by GPOs linked to lower-level containers.
- Block Inheritance enabled on the child OU, no Enforced links: Domain Baseline and Parent OU Policy are both excluded, because they are inherited from higher containers. Child OU Exception remains applicable, since it is linked directly to the child OU, so it wins.
- Block Inheritance enabled on the child OU, Domain Baseline marked Enforced: Parent OU Policy is excluded, but the Enforced Domain Baseline still applies. Domain Baseline wins over Child OU Exception.
The effective value can be identical in more than one scenario while the GPO responsible for it is different. That’s why it’s worth confirming the winning GPO directly rather than checking only the final configured value – two setups that look the same on the endpoint can be one Enforced flag away from behaving very differently after the next change.
Link status, GPO status, security filtering, and WMI filtering
Filtering and status settings are part of Group Policy processing order too – they decide whether a GPO, or one half of it, participates before precedence ever resolves a conflict, a different question than “which GPO wins.” Check four things in order: the enabled state of the specific link, the GPO Status value, security permissions, and the WMI filter.
A disabled link affects only that link; the GPO object can still apply through any other enabled link elsewhere. GPO Status is different in scope: disabling User or Computer Configuration there affects that half everywhere the GPO is linked, not just one container. A GPO whose status is All Settings Disabled contributes no User or Computer settings anywhere.
Creating or editing a GPO does not place it in scope on its own. It must have an enabled link to an applicable site, domain, or OU, unless it is a Local GPO.
The applying principal needs Read and Apply Group Policy permissions. For user-side policy, do not check only the user’s Apply Group Policy permission – the computer account also needs Read access to the GPO so the client can retrieve and evaluate it, and an explicit Deny overrides an otherwise valid Allow.
A GPO can have one linked WMI filter, evaluated on the destination computer even when the GPO contains User Configuration settings. If the query evaluates false, Windows excludes the whole GPO from processing for that destination computer – the filter is not applied to individual settings inside the GPO. A GPO can sit at the highest applicable container in the processing path, Enforced, Link Order 1, and still do nothing if it fails this or any other eligibility check.
Security filtering and its common failure modes, including Denied (Security) and Unknown Reason results, are covered in more depth in security filtering and denied GPO results.
Where loopback changes the user GPO list
Security and WMI filtering determine whether a GPO is eligible to apply. Loopback processing is a different kind of modifier: it changes how Windows constructs the user-side GPO list and can change effective precedence on its own. Merge supplements the normal user list with user settings selected through the computer’s path; Replace discards the normal user-location list and uses only the computer-location list.
In Merge mode, the computer-path user settings are appended after the normal user list and receive higher effective precedence in conflicts. In Replace mode, the normal user-location list is not gathered at all.
Microsoft documents Merge and Replace as distinct processing modes, common on RDS session hosts, kiosks, and shared lab machines. The full merge-vs-replace breakdown is covered in Group Policy loopback processing – the short version here is that loopback failures are rarely “GPO not applying,” they’re “the wrong GPO list applying.”
How to confirm the winning GPO
Before touching production links, inspect the static configuration read-only, then confirm the actual applied result:
$targetOu = 'OU=Helpdesk,OU=Support,DC=ad,DC=example,DC=com'
$inheritance = Get-GPInheritance -Target $targetOu
$inheritance |
Select-Object ContainerName, GpoInheritanceBlocked
$inheritance.GpoLinks |
Format-Table DisplayName, Enabled, Enforced, Order, Target -AutoSize
$inheritance.InheritedGpoLinks |
Format-Table DisplayName, Enabled, Enforced, Order, Target -AutoSizeGpoLinks includes direct links, including disabled links. InheritedGpoLinks lists the enabled links that survive inheritance rules, ordered by effective precedence. Neither collection evaluates endpoint-side security tokens, WMI results, Local GPOs, or client-side extension behavior – that still needs Group Policy Results or gpresult.
Get-GPInheritance contacts the PDC Emulator by default when -Server is omitted, which is fine for normal reading. During a replication-sensitive incident, target a specific DC to see what that DC currently knows:
$domain = 'ad.example.com'
$server = 'dc01.ad.example.com'
$inheritance = Get-GPInheritance `
-Target $targetOu `
-Domain $domain `
-Server $serverGet-GPInheritance is read-only and shows static links and inheritance status.
- Open Group Policy Results in GPMC and run the wizard against the target user/computer – this is the primary tool for viewing the actual applied policy and the winning GPO per setting. Group Policy Results reports what actually applied; Group Policy Modeling is a simulation and does not evaluate Local GPOs, so use Modeling for change planning, not as proof of current endpoint state.
- After changing a link, link order, Enforced, or Block Inheritance, refresh the relevant user or computer policy before collecting a new report. Use a new sign-in or restart when the setting or client-side extension requires foreground processing. Before forcing that refresh, confirm the relevant AD and SYSVOL changes have replicated to the domain controller the client is likely to use – a policy refresh cannot retrieve a change that has not reached that DC yet.
- Run
gpresult.exe /h C:\Temp\gpresult.html /ffrom an elevated shell when a portable HTML report is useful –gpresultdoes not create a missing folder, so create the destination first (if not exist C:\Temp mkdir C:\Temp) or point it at an existing writable path, and use/fto overwrite an existing report. Make sure the report targets the affected user rather than a different administrator account used only for elevation; use Group Policy Results orgpresult.exe /user CONTOSO\jdoe /scope user /h C:\Temp\jdoe-gpresult.html /fwhen the user context is ambiguous. Do not confuse/userwith/u:/userselects the target account whose RSoP is reported, while/usupplies credentials for a remote query and cannot be combined with/h. Usegpresult /rfor a quick scope summary. See generate and read a gpresult report for full syntax. - Treat
rsop.mscas a supplementary, incomplete view only – it does not display every modern Group Policy setting, so don’t rely on it as the final word if a setting isn’t showing up there. - Cross-check the reported winning GPO against link order, Enforced status, filtering, and inheritance in GPMC or the
Get-GPInheritanceoutput above. The static link tree can look misleading until all effective-scope factors are considered. - If the result still doesn’t match expectations, check Block Inheritance on every OU in the chain, not just the immediate parent.
- For user-side settings on machines where computer OU and user OU differ, confirm whether loopback processing is in play before assuming the user’s own OU-linked GPOs should have applied.
If Group Policy Results is missing, stale, or fails to generate, move to the Microsoft-Windows-GroupPolicy/Operational event log and correlate the processing Activity ID – precedence analysis cannot substitute for a failed policy-processing diagnosis. See the full Group Policy troubleshooting workflow, linked at the end of this guide, for that path.
For setting-specific failures involving Group Policy Preferences, tattooed settings, or another management layer such as MDM, verify the actual endpoint state too. Microsoft’s own guidance on Group Policy Modeling and Results treats RSoP as the diagnostic starting point, not the only check.
A common misconception worth naming directly is that “the most specific OU always wins.” That shorthand fails when an Enforced link prevents a lower-level GPO from overriding it, and it can also mislead when Block Inheritance removes higher-level GPOs from the applicable list. Scenario 4 shows the first case: Group Policy Results reports the Enforced domain GPO as the winning GPO even though a conflicting GPO is linked directly to the child OU. Verifying beats assuming.
Operator checklist before changing precedence in production
Group Policy processing order is easy to reason about in theory and easy to get backwards under pressure. Work through this checklist before editing a live link:
- Confirm the current effective result with Group Policy Results or
gpresult /hbefore making any change – you need a known-good baseline to compare against. - Identify every GPO in the LSDOU chain for the affected object, not just the one you’re about to edit.
- Check Enforced status on every link in that chain, and Block Inheritance on every container in it.
- If reordering links at a container, note the current order first – “lowest link-order number wins” is easy to get backwards under pressure.
- Make one change at a time where possible. Stacking a link-order change with a new Enforced flag makes the next
gpresultdiff much harder to interpret. - Refresh the relevant policy, complete any required sign-in or restart, then re-run Group Policy Results and confirm the winning GPO matches intent – not merely that the endpoint currently shows the expected value.
- Document the change, including the reasoning for Enforced or Block Inheritance if either was touched – the next person debugging this container needs the why, not just the what.
“Closest OU wins” is only shorthand for default processing. Enforced can reverse the normal winner, while Block Inheritance changes which inherited GPOs enter the applicable list in the first place.
FAQ
What is the Group Policy processing order?
The default order is Local, Site, Domain, and OU. Parent OUs process before child OUs, and Windows builds separate lists for Computer Configuration and User Configuration.
Is Link Order 1 the highest precedence?
Yes, among GPO links on the same site, domain, or OU. Link Order 1 is processed last at that container, so it normally wins conflicts there. Link order is not comparable across different containers.
Does the closest OU always win?
No. It’s a useful default shorthand for conflicting normal links, but an Enforced higher-level link can retain precedence, and filtering, a disabled link, or Block Inheritance can remove GPOs from the effective list entirely.
Does Enforced override Block Inheritance?
Yes. An Enforced inherited link remains applicable through a domain or OU where Block Inheritance is enabled.
Does Block Inheritance remove a GPO linked directly to the OU?
No. It removes non-Enforced GPO links inherited from higher containers. Direct links on the blocked container remain, and Local Group Policy is unaffected either way.
Do security and WMI filters change precedence?
No, they change eligibility. A GPO that fails filtering is removed before precedence resolves conflicts among the remaining applicable GPOs. WMI filters evaluate on the destination computer even for User Configuration settings.
How do I find the winning GPO?
Use Group Policy Results in GPMC or gpresult /h. Get-GPInheritance shows static links read-only but does not confirm the actual applied result. rsop.msc does not display all modern Group Policy settings.
How does loopback affect precedence?
Merge appends user settings gathered through the computer’s GPO path and gives them higher effective precedence. Replace uses only the computer-location user GPO list and skips the normal user-location list entirely.
For the full Group Policy troubleshooting workflow beyond precedence, see the dedicated guide.
Official Microsoft references
The sources below cover the specific Group Policy processing order mechanics discussed in this guide.
Group Policy Troubleshooting Series
8 articles – Workflow · Processing Order · GPResult · GPUpdate · Filtering · Loopback · Events