Group Policy in Active Directory applies computer and user settings through Group Policy Objects linked to sites, domains, and organizational units. The final result depends on processing order, link precedence, inheritance, security and WMI filtering, loopback mode, and the client-side extension responsible for each setting.
The baseline order is Local -> Site -> Domain -> OU, but “last policy wins” is only a starting model. Enforced links, blocked inheritance, filters, loopback processing, policy-versus-preference behavior, and settings that require foreground processing can all change the final Resultant Set of Policy.
- Group Policy applies in LSDOU order – Local, Site, Domain, OU – with a child OU’s conflicting setting normally taking precedence, unless an Enforced higher-level link is involved
- When multiple GPOs are linked to the same site, domain, or OU, link order decides precedence – the GPO at link order 1 is processed last and wins a conflict
- Computer and user policy process independently at startup/sign-in and again on a recurring background refresh – not every setting can apply in the background, though
- By default, Authenticated Users has Read and Apply Group Policy – removing it without restoring Read for the relevant computers breaks user-policy retrieval
- An elevated
gpresult /his the first diagnostic move, not the last - Keep Default Domain Policy limited to the domain’s default Account Policies – put everything else in dedicated GPOs
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. A GPO is really two parts: the Group Policy Container (GPC), an AD object holding version and link metadata, and the Group Policy Template (GPT), the folder of actual setting files stored in SYSVOL. Microsoft’s Group Policy overview covers both in more detail. 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 |
| Initial processing | Computer startup, before logon | User sign-in |
| Background processing | Normally every 90 minutes plus a random offset; 5 minutes on domain controllers | Normally every 90 minutes plus a random offset |
| Foreground-only examples | Software installation, startup/shutdown scripts | Folder Redirection, software installation, logon/logoff scripts |
| Can be disabled | Yes, independently | Yes, independently |
Foreground processing can be synchronous or asynchronous – some client-side extensions detect that they need synchronous processing and defer completion until a later startup or sign-in. Either half can be disabled if unused, which 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. A common computer-side example is pointing clients to a centralized update server before user logon – see WSUS Configuration for the specific policy values.
How Group Policy Processing Order Works (LSDOU)
Group Policy processing follows a fixed sequence, and later-applied layers normally take precedence over earlier ones for the same setting. The baseline order:
| Order | Layer | What applies | Default precedence, before exceptions |
|---|---|---|---|
| 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 |
Under normal inheritance, a child OU’s conflicting setting has higher precedence than the same setting from a parent OU or domain link – but this doesn’t override an Enforced higher-level link, and it only applies when both GPOs are actually in scope and configure the same winning setting. Several things change what enters the applicable list before precedence even matters: Block Inheritance, security and WMI filtering, loopback processing, disabled links or GPO halves, and Enforced flags. Some policy areas merge multiple GPOs’ settings rather than behaving as a single scalar winner, and Group Policy Preferences process items sequentially based on their configured action and item-level targeting. Microsoft’s Group Policy processing documentation covers the complete model.
What Happens When Multiple GPOs Are Linked to the Same Site, Domain, or OU
LSDOU explains inter-layer precedence. It doesn’t explain what happens when five GPOs are all linked to the same OU – the more common real-world situation.
In GPMC, select the site, domain, or OU, open the Linked Group Policy Objects tab, and use the arrow controls to change link order. The GPO with link order 1 has the highest precedence and is processed last (wins on conflict); 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 at 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. Both GPOs show as “Applied” in gpresult, which looks correct until the winning value is actually checked. Use the HTML report or Group Policy Results to inspect which GPO’s value is actually taking effect, not just whether each GPO applied. Operators debugging this spend time re-editing the new GPO without realizing precedence is the issue.
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. Link here only when a setting genuinely needs domain-wide scope; domain account policies (Password, Account Lockout, Kerberos) are a special case managed deliberately at this level. Workstation, server, department, application, and role-specific settings normally belong on the relevant OUs instead.
- 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 scope are directly connected. A well-designed OU hierarchy makes GPO targeting precise and auditable. The Active Directory structure guide covers forest, domain, and OU hierarchy in detail.
Inheritance, Block Inheritance, and Enforced
Two mechanisms let you override default LSDOU flow. Both have legitimate uses, and both are frequently overused.
| Mechanism | Applied to | Effect | When to use |
|---|---|---|---|
| Block Inheritance | OU | Non-Enforced GPOs inherited from site, domain, and parent OUs are blocked at that container | Isolated sub-environment (quarantine OU, lab OU, DMZ) |
| Enforced (No Override) | GPO link | This GPO applies regardless of Block Inheritance at lower containers | Settings that must retain precedence through lower OUs and Block Inheritance |
| Security Filtering | GPO | Controls which security principals 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, and in an environment where it was applied freely, troubleshooting means checking every parent chain before drawing conclusions. Enforced is a link property used when a higher-level GPO must retain precedence through lower OUs and Block Inheritance – use it sparingly, since it makes delegation and troubleshooting less flexible. Don’t enable Enforced merely because a setting feels important; first verify that normal scope and precedence don’t already produce the required result.
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.
Security Filtering and Required Read Permission
By default, Authenticated Users has Read and Apply Group Policy permissions on a GPO. Users and computers inside the link scope are eligible to apply the relevant enabled half of the GPO – but only if inheritance, filtering, WMI evaluation, loopback, and link state don’t exclude them first. The permission existing isn’t the same as the setting actually applying.
Security filtering narrows who receives the GPO. Since the MS16-072 behavior change, user Group Policy is retrieved in the computer account’s security context – if the computer itself can’t read the GPO, user settings can fail even when the user is in the correct security group. Removing Authenticated Users from Security Filtering removes both Read and Apply Group Policy, and that’s the mistake that catches people:
- Add the target user or computer security group to Security Filtering so it receives Read and Apply Group Policy
- If removing Authenticated Users from Security Filtering, open the Delegation tab
- Grant Authenticated Users, Domain Computers, or the affected computer group Read permission without Apply Group Policy
- Confirm there’s no explicit Deny permission, since Deny overrides Allow
- Verify the result with an elevated
gpresult /hreport
Practical uses for filtering: pilot deployments before broad rollout, role-specific settings (server-only policies in a mixed OU), department-specific software restrictions.
A user-targeted GPO is filtered to a user security group. Authenticated Users is removed from Security Filtering, but no computer group retains Read permission. The user is correctly targeted, yet the workstation can’t read the GPO in the required computer context, so user policy fails. The fix isn’t restoring Apply Group Policy to everyone – it’s restoring Read-only access for Authenticated Users, Domain Computers, or the affected computer accounts. Official guidance: Cannot apply user GPO when computer objects don’t have Read permissions.
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 specific Windows client builds within an OU that contains mixed OS versions. Example targeting current Windows 11 client build families – validate against all supported OS versions before production use, since build-number conventions can change:
SELECT * FROM Win32_OperatingSystem
WHERE ProductType = 1 AND BuildNumber >= "22000"BuildNumber is exposed as text, so validate comparison behavior for future build-number formats. WMI filters add processing overhead – each filter runs a live query at policy refresh time, and accumulating them across many GPOs creates measurable logon latency on slow hardware or in large environments. When possible, prefer stable OU design, security groups, or Group Policy Preference item-level targeting over accumulating broad WMI filters.
Group Policy Refresh Intervals
Group Policy doesn’t apply only at startup and sign-in. After initial application, policies refresh in the background at regular intervals – though not every setting can process that way.
| 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 |
| Foreground-only extensions | Startup, shutdown, logon, or logoff only | Software installation, Folder Redirection, scripts – not refreshed in the background |
Not every Group Policy extension processes during background refresh. Folder Redirection and Software Installation require foreground processing, and scripts execute only at startup, shutdown, logon, or logoff. Group Policy Preference Drive Maps are different: they can process during background refresh, subject to their configured action, item-level targeting, and extension settings – the Replace action can disconnect and recreate mappings repeatedly, so Update is often safer when the existing connection should remain available. Don’t tell users to log off and back on until the specific client-side extension actually responsible has been identified. Microsoft’s Group Policy Preferences documentation covers extension-specific reapplication behavior.
gpupdate /force reapplies all settings immediately on the local machine and is the default command to reach for:
gpupdate /force/logoff and /boot only matter for extensions that specifically require a logoff or restart to complete – they aren’t reflexive additions for every refresh, and interrupting a user’s session should come with a warning first:
gpupdate /force /logoff
gpupdate /force /bootGPO Replication: Where Things Break
A GPO has two components stored in two separate locations, replicated through two different mechanisms.
GPO metadata (the GPC) – existence, GUID, links, version number – is stored in the AD database and replicated via standard AD replication between domain controllers.
GPO settings files (the GPT) – 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 settings than one authenticating against DC2, because the SYSVOL files are out of sync even though AD metadata looks correct in GPMC. repadmin only validates AD replication – it doesn’t prove SYSVOL files are replicating correctly, even though it can expose an AD problem that indirectly prevents DFSR from converging. Check both, separately:
# AD replication
repadmin /replsummary
repadmin /showrepl
# SYSVOL/DFSR
dcdiag /test:Advertising /test:SysVolCheck
dfsrdiag ReplicationStateFor a targeted backlog comparison between two DCs:
dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /smem:DC1 /rmem:DC2Also inspect Applications and Services Logs -> DFS Replication, the SYSVOL and NETLOGON shares, and GPO version consistency. Healthy AD replication alone doesn’t prove the GPO template files in SYSVOL are current. For DFSR-specific failures, see the SYSVOL replication troubleshooting guide; for the full AD replication workflow, see Active Directory replication troubleshooting. The Microsoft Learn Group Policy application troubleshooting guidance details the replication dependency model.
Loopback Processing: Computer Context Overrides User Policy
Standard Group Policy 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 sign 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 instead of the user’s OU. It’s configured in Computer Configuration, and both the user and computer portions required by the design need to remain enabled – the computer object and user object both need to exist in AD.
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.
Choose based on the required session behavior rather than the platform name alone: Replace is appropriate when the shared computer should ignore the user’s normal GPO list entirely; Merge is appropriate when normal user policy should remain (drive mappings, for example) alongside computer-location settings that need to win on conflict. Microsoft’s loopback processing documentation covers both modes in detail.
Without loopback, drive mappings, desktop shortcuts, and security settings designed for individual desktops apply in multi-user server sessions with unpredictable results – 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 effective Group Policy calculated 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. It shows applied and denied GPOs and the resulting settings, but application-specific behavior, client-side extension errors, tattooed preference values, and settings outside Group Policy may still need separate validation – RSoP tells you what Group Policy computed, not necessarily that every workload is behaving correctly as a result.
gpresult is the primary tool for viewing RSoP. Run it elevated to reliably include computer-scope data:
gpresult /h C:\GPOReport.html /f/f overwrites an existing report instead of failing because the file already exists. For a single scope:
gpresult /scope computer /r
gpresult /scope user /rGet-GPResultantSetOfPolicy generates the same HTML report remotely. The GPMC’s Group Policy Modeling and Results tools provide the same RSoP data through a GUI wizard – Modeling is useful for testing a hypothetical user/computer combination before a change is made, Results shows what actually applied. When a report shows a processing error, or doesn’t explain the failure, inspect Applications and Services Logs -> Microsoft -> Windows -> GroupPolicy -> Operational, and use the Activity ID to correlate one processing cycle; the full log-based diagnostic workflow is covered separately (see below). 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.
A Short Verification Workflow
This stays concise on purpose – the goal here is confirming why RSoP looks the way it does, not the complete diagnostic workflow for a specific failure:
- Confirm the affected user/computer is in the expected OU and the relevant GPO half is enabled
- Generate an elevated
gpresult /hreport - Check Applied and Denied GPOs, and the reason for anything denied
- Confirm link order, inheritance, filtering, WMI, and loopback for the GPO in question
- If results differ by which DC the client authenticated against, confirm AD and SYSVOL replication separately
For client-side extension failures, the GroupPolicy Operational log and Activity ID workflow, DNS/DC discovery problems, and full symptom-based diagnosis, see GPO Not Applying.
Common Mistakes
Default Domain Policy trap. Microsoft recommends using Default Domain Policy only for the domain’s default Account Policies – Password Policy, Account Lockout Policy, and Kerberos Policy – and limiting Default Domain Controllers Policy to domain-controller user rights and audit policy. In practice, both accumulate 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. Different password and lockout requirements for selected users or groups use fine-grained password policies in Active Directory, not GPOs linked to their OUs. Create a separate GPO for each distinct purpose and link it at the appropriate OU level. If Default Domain Policy needs to be reset to its original state, Microsoft’s dcgpofix documentation covers the supported recovery tool and the intended scope of both default GPOs.
Linking GPOs at domain root for convenience. GPOs at domain root apply to all domain objects. Most settings don’t belong there – domain account policies are the deliberate exception. 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 an elevated gpresult /h, not GPMC. The HTML report shows exactly what applied, what was denied, and why. Every other diagnostic path takes longer.
Assuming every drive-map issue is a background-refresh limitation. Group Policy Preference Drive Maps can process during background refresh – the Replace action can disconnect and recreate mappings repeatedly, so Update is often the safer choice when the existing connection should remain available. Don’t tell a user to log off and back on before actually identifying which client-side extension is responsible.
Final Thoughts
Group Policy Active Directory processing is deterministic once the model is clear, but LSDOU, link order, inheritance, filtering, loopback, and refresh intervals interact in ways that produce non-obvious results when stacked. Most production issues come down to a handful of causes: link scope that’s broader than intended, link order conflicts within the same container, security filtering that removed Read along with Apply Group Policy, 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 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: Local, Site, Domain, OU. Policies apply in that sequence, and a child OU’s conflicting setting normally has higher precedence than the same setting from a parent OU or domain link – unless an Enforced higher-level link is involved. When multiple GPOs are linked to the same layer, link order (the numbered order in GPMC) determines which wins – link order 1 has the highest precedence.
Which GPO wins when multiple GPOs configure the same setting?
Within the same site, domain, or OU, the GPO with the lowest link order number wins. Across layers, a child OU beats a parent OU, which beats the domain, which beats local policy – unless Enforced, Block Inheritance, security/WMI filtering, or loopback changes what’s actually in the applicable list. Two GPOs can both show as “Applied” in gpresult while only one setting value actually wins – check the HTML report or Group Policy Results for the winning source, not just whether each GPO applied.
Why is a GPO denied by security filtering?
Usually because Authenticated Users was removed from Security Filtering and no replacement Read permission was granted for the relevant computer accounts. Since user Group Policy is retrieved in the computer’s security context, the computer also needs Read – adding the user’s security group to Apply Group Policy alone isn’t enough. Check the Delegation tab for the GPO and confirm Authenticated Users, Domain Computers, or the specific computer group has Read without Apply Group Policy, and that no explicit Deny exists.
What is the difference between Group Policy settings and Group Policy Preferences?
Group Policy settings are enforced and generally can’t be changed by the user – the UI is often grayed out. Group Policy Preferences configure an initial state (a mapped drive, a registry value, a shortcut) that the user can change afterward, unless “Apply once and do not reapply” is set. Preferences also support item-level targeting, so a single GPO can apply different values to different machines or users based on conditions like OU, security group, or IP range. Drive Maps is a preference client-side extension and can reprocess during background refresh, depending on its configured action.
What does gpupdate /force actually do?
It reapplies all Group Policy settings immediately on the local machine, bypassing the normal refresh interval. It doesn’t change which DC the client uses. /logoff and /boot only matter for the specific extensions that require a logoff or restart to complete – they aren’t reflexive additions, and interrupting a user’s session should come with a warning first.
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 on a GPO linked to the computer’s OU, 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 designed for individual desktops from following users into shared server sessions.
How do AD replication and SYSVOL replication affect Group Policy?
A GPO has two parts stored and replicated separately: metadata (the GPC) via standard AD replication, and the actual settings files (the GPT) in SYSVOL via DFSR. repadmin only confirms AD replication – it doesn’t prove SYSVOL files are current. If clients authenticating against different DCs get different results, check AD replication with repadmin /showrepl and SYSVOL/DFSR separately with dcdiag /test:SysVolCheck and dfsrdiag ReplicationState. The AD replication troubleshooting guide linked above covers diagnosing both paths.