Most group policy active directory problems aren’t configuration errors. They’re processing order misunderstandings. Once you know the sequence in which GPOs apply — and what wins when two policies conflict — the troubleshooting logic becomes predictable.
- Group policy active directory applies in LSDOU order: Local → Site → Domain → OU; child OU wins conflicts with parent OU
- When multiple GPOs are linked to the same OU, link order determines precedence — lower link order number wins
- Computer policy applies at startup; user policy applies at logon — separate processing paths
- By default every GPO applies to Authenticated Users (everyone in scope); security filtering restricts this
gpresult /h report.htmlis your first diagnostic move, not your last- Never edit Default Domain Policy for anything beyond password policy, account lockout, and Kerberos settings
What a GPO Actually Is
A Group Policy Object is a container of settings that Active Directory applies to computers and/or users within a defined scope. The scope is determined by where the GPO is linked — domain, site, or OU. Group policy active directory management happens through two tools: the Group Policy Management Console (GPMC) and the GroupPolicy PowerShell module.
Each GPO has two halves that operate independently:
| Computer Configuration | User Configuration | |
|---|---|---|
| Applies to | Computer object in AD | User object in AD |
| Processing time | At startup, before logon | At logon |
| Typical use | Security settings, software, firewall rules | Desktop settings, folder redirection, drive maps |
| Can be disabled | Yes, independently | Yes, independently |
Either half can be disabled if unused. This reduces processing overhead and makes GPO intent explicit — an auditor opening GPMC can immediately see whether a GPO is computer-only, user-only, or both.
How Group Policy Processing Order Works (LSDOU)
Group policy active directory processing follows a fixed sequence. When settings conflict, later-applied policies win. The full processing order:
| Order | Layer | What applies | Wins over |
|---|---|---|---|
| 1 | Local | Settings on the machine itself (Local Security Policy) | Nothing — lowest priority |
| 2 | Site | GPOs linked to the AD site containing the computer | Local |
| 3 | Domain | GPOs linked to the domain root | Local, Site |
| 4 | OU | GPOs on the OU containing the object — parent first, then child | Local, Site, Domain, Parent OU |
A child OU GPO always beats a parent OU GPO for the same setting. An OU GPO always beats a domain GPO. This ordering is why “I set it at the domain level but it’s not applying” is almost always an OU-level override — or a link order conflict within the same OU.
What Happens When Multiple GPOs Are Linked to the Same OU
LSDOU explains inter-layer precedence. It doesn’t explain what happens when five GPOs are all linked to the same OU — which is the more common real-world situation.
In GPMC, each GPO link has a Link Order number. The GPO with link order 1 has the highest precedence and is processed last (wins on conflict). GPO with link order 2 is processed second-to-last, and so on.
In practice: if Link Order 1 sets screensaver timeout to 5 minutes and Link Order 2 sets it to 15 minutes, the result is 5 minutes — Link Order 1 wins.
A new GPO is linked to the Workstations OU and assigned Link Order 3. An older GPO at Link Order 1 configures the same registry setting with a different value. The new GPO applies but has no effect — the Link Order 1 policy wins every refresh cycle. gpresult /h shows both GPOs as “Applied” — which looks correct until you examine the winning value. Operators debugging this spend time re-editing the new GPO without realizing precedence is the issue.
To change link order: in GPMC, right-click the OU → select the Linked Group Policy Objects tab → use the arrow buttons to reorder.
Where GPOs Live: Linking and Scope
Creating a GPO and linking a GPO are separate operations. A GPO can exist in the domain without being linked anywhere — it has no effect until linked.
Where you link determines scope:
- Domain root link — applies to all objects in the domain. Use only for domain-wide mandatory policy: password policy, account lockout, audit policy. Frequently overused for convenience.
- OU link — applies to objects in that OU and child OUs (unless inheritance is blocked). Correct default for most GPOs.
- Site link — applies to all objects in that AD site, regardless of domain. Used for bandwidth-sensitive or location-specific settings. Rare in most SMB environments.
OU structure and group policy active directory scope are directly connected. A well-designed OU hierarchy makes GPO targeting precise and auditable. When OUs exist for operational reasons — not just GPO convenience — linking decisions become straightforward. The Active Directory structure guide covers forest, domain, and OU hierarchy in detail.
Security Filtering: Who Gets the Policy
By default, every GPO grants Apply Group Policy and Read permissions to Authenticated Users — meaning every authenticated user and computer within the linked scope receives the policy.
Security filtering changes this. To restrict a group policy active directory object to specific users or computers:
- In GPMC, select the GPO → Security Filtering tab
- Remove Authenticated Users
- Add a security group containing only the target objects (users, computers, or both)
Practical uses: pilot deployments before broad rollout, role-specific settings (server-only policies in a mixed OU), department-specific software restrictions.
Authenticated Users is removed from security filtering. No replacement security group is added. The GPO applies to nobody. No error appears in GPMC — the GPO looks linked and configured. gpresult /r shows the GPO in the “Denied GPOs” section with reason “Access denied.” This is a silent misconfiguration. The operator checks the GPO settings, checks the OU link, and finds nothing wrong — because the problem is in the Delegation tab, not in the settings or link itself.
WMI Filtering
WMI filters add a query-based condition to GPO application. Before a GPO applies, the WMI filter runs a query against the target machine — if the query returns false, the GPO is skipped for that machine.
Common use case: apply a GPO only to Windows 11 machines within an OU that contains mixed OS versions.
# Example WMI filter query — Windows 11 only
SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "10.0.2%" AND ProductType = "1"WMI filters add processing overhead — each filter runs a live query at policy refresh time. On slow hardware or large environments, accumulating WMI filters across many GPOs creates measurable logon latency. Use them where OS or hardware targeting is genuinely needed, not as a substitute for OU structure.
Block Inheritance and Enforced: When and Why
Two mechanisms let you override default LSDOU flow. Both have legitimate uses. Both are frequently overused.
| Mechanism | Applied to | Effect | When to use |
|---|---|---|---|
| Block Inheritance | OU | Parent OU GPOs do not flow into this OU | Isolated sub-environment (quarantine OU, lab OU, DMZ) |
| Enforced (No Override) | GPO link | This GPO applies regardless of Block Inheritance | Domain-wide mandatory settings that must never be overridden |
| Security Filtering | GPO | Controls which objects receive the GPO | Targeting specific groups without separate OUs |
Block Inheritance overuse creates AD topology debt. Every blocked OU is a location where domain-wide policy silently doesn’t apply. In inherited environments where Block Inheritance was applied freely, troubleshooting group policy active directory behavior requires checking every parent chain before drawing conclusions about what should be applying.
Enforced is the nuclear option. Use it only where a setting genuinely cannot be overridden — account lockout policy, domain password policy. Broad Enforced usage removes OU administrators’ ability to manage their own scope and makes policy behavior harder to predict.
When Block Inheritance is needed frequently, the real problem is usually GPO scope that’s too broad at the domain level. The fix is better OU structure, not inheritance blocking. The OU design guide covers how to structure OUs so GPO targeting is precise without relying on inheritance overrides.
Group Policy Refresh Intervals
Group policy active directory doesn’t apply only at startup and logon. After initial application, policies refresh in the background at regular intervals.
| Scenario | Default interval | Notes |
|---|---|---|
| Workstations | 90 minutes + 0–30 min random offset | Random offset prevents all machines refreshing simultaneously |
| Domain Controllers | 5 minutes | Faster refresh — DCs need current policy for authentication operations |
| Security settings | Every 16 hours regardless of changes | Applies even if no GPO changes detected |
| Startup/logon-only settings | Startup or logon only | Software installation, folder redirection — not refreshed in background |
Settings applied only at startup or logon — software installation, folder redirection, drive mappings when configured via certain methods — do not apply during background refresh. A user won’t receive a new drive mapping until they log off and back on, regardless of what gpupdate /force shows.
gpupdate /force triggers an immediate refresh cycle on the local machine. It doesn’t bypass startup/logon-only policies — for those, a reboot (computer policy) or logoff/logon (user policy) is required.
GPO Replication: Where Things Break
A group policy active directory object has two components stored in two separate locations, replicated through two different mechanisms.
GPO metadata — existence, GUID, links, version number — is stored in the AD database and replicated via standard AD replication between domain controllers.
GPO settings files — the actual policy templates and configuration — are stored in SYSVOL on each DC and replicated via DFSR.
When these paths diverge, policy behavior becomes inconsistent. A computer authenticating against DC1 may receive different group policy active directory settings than one authenticating against DC2 — because the SYSVOL files are out of sync even though AD metadata looks correct in GPMC. For DFSR-specific failures, see the SYSVOL replication troubleshooting guide.
Symptoms: policy applies on some machines but not others; settings appear inconsistent after reboot (client authenticated to a different DC); gpresult output differs between machines in the same OU. Active Directory replication troubleshooting covers the full DFSR and AD replication diagnostic workflow. The Microsoft Learn overview of group policy active directory application details the replication dependency model.
Loopback Processing: Computer Context Overrides User Policy
Standard group policy active directory processing applies user policy based on the OU where the user object lives. On shared workstations, RDS servers, and Citrix hosts, this creates a problem: users from across the organization log in, and their personal GPOs — designed for individual office workstations — follow them into server sessions.
Loopback processing changes this. When enabled on a GPO linked to the computer’s OU, user policy is determined by the computer’s OU context, not the user’s OU.
Two modes:
- Replace — user GPOs from the user’s OU are discarded. Only user GPOs linked to the computer’s OU apply.
- Merge — user GPOs from both locations apply, with computer OU GPOs winning on conflicts.
Replace is almost always correct for RDS and Citrix. Merge is used when users still need some of their standard user policy (drive mappings, for example) alongside the server-specific restrictions.
Without loopback, drive mappings, desktop shortcuts, and security settings designed for individual desktops apply in multi-user server sessions — with unpredictable results that are difficult to trace because gpresult on the server shows the user’s personal policies applying correctly.
Enable via: Computer Configuration → Administrative Templates → System → Group Policy → Configure user Group Policy Loopback Processing mode
Resultant Set of Policy: What’s Actually Applying
Resultant Set of Policy (RSoP) is the final computed policy for a specific user on a specific computer — after LSDOU ordering, link order, security filtering, WMI filtering, Block Inheritance, Enforced flags, and loopback processing have all been applied.
RSoP is what actually runs on the machine. Everything else — LSDOU, link order, filtering — determines how RSoP is calculated.
gpresult is the primary tool for viewing RSoP. The HTML report (gpresult /h) shows the full RSoP broken down by computer and user, with each GPO’s contribution, applied/denied status, and reason. Get-GPResultantSetOfPolicy generates the same report remotely. Full gpresult syntax and parameters are documented on Microsoft Learn.
When a setting isn’t behaving as expected, the question isn’t “is the GPO configured correctly?” — it’s “what does RSoP say for this user on this machine?” Those are different questions with different answers.
How to Verify What’s Actually Applying
Scenario: corp\john logs into PC-023. Expected: mapped drive Z: via drive mapping GPO. Actual: no mapped drive after logon.
- Log into PC-023 as corp\john → run
gpresult /h C:\report.html→ open the report - Check User Configuration → Applied GPOs — is the drive mapping GPO listed?
- If not listed: check Denied GPOs → reason will indicate security filtering (“Access denied”), WMI filter (“WMI filter evaluated to false”), or inheritance (“Blocked”)
- If listed as applied but drive still missing: drive mapping GPO may be applying but another GPO with higher precedence is removing the mapping — check Link Order in GPMC
- Verify the computer account is in the correct OU — if PC-023 was recently moved, it may still be in the wrong OU and loopback or computer-side filtering may be redirecting policy
- Check SYSVOL replication — run
repadmin /showrepland verify no errors; if DC replication is lagging, corp\john’s DC may have stale GPO files. Full diagnostic steps in the AD replication troubleshooting guide - Force a full refresh and recheck:
gpupdate /force /logoff→ log back in → re-rungpresult /r
# Summary — current user and computer
gpresult /r
# Full HTML diagnostic report
gpresult /h C:\GPOReport.html
# Remote RSoP for specific user and computer
Get-GPResultantSetOfPolicy -Computer "PC-023" -User "corp\john" -ReportType Html -Path "C:\rsop.html"
# List all GPOs in domain with status
Get-GPO -All | Select DisplayName, GpoStatus
# Force immediate refresh and logoff (for logon-only policies)
gpupdate /force /logoff
# Check replication health across DCs
repadmin /showreplgpresult /r gives the summary. gpresult /h gives the diagnostic detail — denied GPOs, filter reasons, version numbers. The HTML report is what you actually need when the summary doesn’t explain the problem.
Common Mistakes
Default Domain Policy trap. Default Domain Policy has one job: domain-wide password policy, account lockout policy, and Kerberos settings. In practice it accumulates years of miscellaneous settings added for convenience — software restrictions, registry tweaks, security baselines. The result is a GPO that can’t be safely edited, can’t be scoped, and applies to everything. Recovery requires auditing every setting it contains, which in a mature environment is a significant project with real rollback risk. Never add settings to Default Domain Policy. Create a separate GPO for each distinct purpose and link it at the appropriate OU level. Microsoft’s Group Policy overview documentation covers the intended scope of Default Domain Policy.
Linking GPOs at domain root for scope convenience. GPOs at domain root apply to all domain objects. Most settings don’t belong there. When a GPO should apply to workstations only — link it to the Workstations OU. Domain-root links are hard to revoke cleanly later and create broad, hard-to-audit scope.
Not running gpresult before anything else. When a user reports unexpected settings — wallpaper changing, software appearing, network drive missing — the first move is gpresult /h, not GPMC. The HTML report shows exactly what applied, what was denied, and why. Every other diagnostic path takes longer.
Forgetting that drive mappings don’t apply during background refresh. Drive mapping GPOs apply at logon only. gpupdate /force won’t apply them mid-session. This catches operators who push a drive mapping change and then wonder why it’s not showing up on currently logged-in machines — even after forcing a refresh.
Final Thoughts
Group policy active directory processing is deterministic once the model is clear. LSDOU, link order, inheritance, filtering, and refresh intervals follow consistent rules — but those rules interact in ways that produce non-obvious results when stacked. Most problems in production come down to four causes: wrong link scope (domain root instead of OU), link order conflicts within the same OU, security filtering misconfiguration, or SYSVOL replication lag creating inconsistent behavior across DCs. The post-install checklist covers baseline GPO verification steps immediately after DC promotion.
The diagnostic path is short. gpresult /h shows the Resultant Set of Policy — the final computed group policy active directory state for that user on that machine. Everything else is tracing why RSoP looks the way it does.
FAQ
What is LSDOU in Group Policy?
LSDOU is the processing order for group policy active directory: Local, Site, Domain, OU. Policies apply in that sequence, with later policies winning on conflict. A child OU GPO overrides a parent OU GPO. When multiple GPOs are linked to the same layer, link order (the numbered order in GPMC) determines which wins — link order 1 has highest precedence.
Why is my GPO not applying?
Run gpresult /h C:\report.html and check the Denied GPOs section for the affected computer and user. Common reasons: security filtering removed Authenticated Users without a replacement group (shows “Access denied”), WMI filter evaluated to false for that machine, Block Inheritance preventing the GPO from flowing down, or another GPO with higher precedence is overriding the same setting. SYSVOL replication lag is the cause when behavior is inconsistent across machines in the same OU.
What does gpupdate /force actually do?
It forces immediate reapplication of group policy on the local machine, bypassing the normal refresh interval (90 minutes for workstations, 5 minutes for DCs). It doesn’t change which DC the client uses. Important: startup-only (computer) and logon-only (user) policies don’t apply during a forced refresh — they require a reboot or logoff/logon respectively.
When should I use security filtering vs a separate OU?
Security filtering for temporary or role-based targeting where a new OU would be structural overkill — pilot deployments, a specific team in a mixed OU. A separate OU when the distinction is permanent and the objects have different management requirements beyond GPO scope. If you’re filtering the same group across many GPOs, that’s a signal the OU structure needs revision.
What is loopback processing in Group Policy?
Loopback processing changes how user policy is determined on shared computers. Normally user GPOs come from the user’s OU. With loopback enabled, user GPOs come from the computer’s OU instead (Replace mode) or a merge of both (Merge mode). Used on RDS and Citrix servers to prevent personal user policies from following users into multi-session server environments.
Does group policy work without SYSVOL replication?
Partially. AD replication (GPO metadata) and SYSVOL replication (policy files) are separate paths. If SYSVOL replication fails, GPO metadata is consistent across DCs but the settings files are stale or missing on some. The result: clients authenticating against different DCs receive different group policy active directory settings — behavior looks random from the user’s perspective. Consistent policy application depends on both paths being healthy. The AD replication troubleshooting guide covers how to diagnose and fix both paths.
What is AGPM and do I need it?
Advanced Group Policy Management is a Microsoft MDOP tool that adds change control, approval workflows, and version history to GPO management. Relevant for large teams where multiple administrators edit GPOs and audit trails are required. For SMB environments and single-administrator setups, standard GPMC with a documented change process covers the same ground without the infrastructure overhead.