Group Policy Processing Order Explained

2.4K

When you link Group Policy Objects (GPOs) to users and/or computers containers in AD, it’s important to understand the order in which they are processed. In this guide, we will take a look at the concepts of the scope and precedence of Group Policies in AD domains. The priority of a GPO is determined by the order in which it is applied — the later a policy is applied, the higher its priority.

A Group Policy Object has two closely related components:

• Group Policy Container (GPC) stored in AD
• Group Policy Template (GPT) stored in the domain’s SYSVOL folder

The GPC contains directory-based info such as GPO links and config metadata, while the GPT contains policy files and administrative template data.

Note that both components must be available and properly replicated. SYSVOL replication is normally handled by DFS Replication (DFSR) in modern AD environments. Problems with AD/SYSVOL replication can cause inconsistent Group Policy results between DCs.

Our guide focuses on traditional AD Group Policy processing. However, in modern Windows environments, devices may also receive config through MDM platforms such as Microsoft Intune, which use a separate policy-management and conflict-resolution model.

Central Store for Administrative Templates

In case your organization manage Windows Administrative Templates, you should consider using a Central Store for ADMX/ADML files. The Central Store is located in the PolicyDefinitions folder in the domain’s SYSVOL:

\\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions

When the Central Store is available, Group Policy Management tools use the centralized ADMX/ADML templates instead of relying on the local template files installed on the admin’s machine.

LSDOU rule

When describing Group Policy scopes, you must remember the important LSDOU acronym. LSDOU is a mnemonic rule that makes it easy to remember the order in which Group Policies are processed:

• L (Local GPO) – Local Group Policy is the first stage of traditional Group Policy processing and applies to the local machine and/or local users before Site, Domain, and OU-linked GPOs are processed.
• S (Site GPO) – applies to all objects in a particular Active Directory site.
• D (Domain GPO) – applied at the domain root level to all objects within the domain
• OU (Organizational Unit GPO) – is the highest level of priority and applies to specific OU within a domain. The GPO assigned to a nested (child) OU has a higher priority than the GPO assigned to the parent OU.

The settings described in the OU’s GPO take precedence. For example, if some Windows option is enabled at the domain policy level but disabled at the target Organizational Unit (OU) level by another policy, the setting will be disabled on the client device. This is because the policy closest to the object in the Active Directory hierarchy takes precedence (the last GPO in the hierarchy wins).

Local Group Policy Processing

Unlike domain Group Policy, which is managed through AD, Windows can have multiple Local Group Policy layers. These policies are processed before domain-based GPOs. Windows supports local policy scopes that can target:

• Local Computer Policy – applies to the computer and its users.
• Administrators Local GPO – applies to users who are members of the local Administrators group.
• Non-Administrators Local GPO – applies to users who are not members of the local Administrators group.
• Per-user Local GPO – applies to a specific local user account.

This allows you to apply different local policy settings depending on the user context, even when the machine is not managed exclusively through a single Local GPO.

Local Group Policy can still provide baseline settings before domain GPOs are processed on domain-joined machines. However, you should generally avoid using Local Group Policy as an unmanaged enterprise config mechanism because it can make troubleshooting and config management more difficult.

Group Policy Processing Phases

Group Policy settings are processed during several stages of the machine lifecycle:

• Computer Configuration settings are processed during machine startup.
• User Configuration settings are processed when a user signs in.
• Group Policy settings are periodically refreshed in the background while the machine is running. By default, domain-joined computers refresh Group Policy every 90 minutes with a random offset of up to 30 minutes to reduce load on DCs.

Keep in mind that modern versions of Windows also support Group Policy Caching, which stores previously applied policy info locally to improve startup and logon performance on slow network connections. Because of this caching behavior, policy changes may not always be immediately visible until the next policy refresh cycle/manual Group Policy update.

You can also trigger a manual policy refresh by using the following command:

gpupdate /force

Note. When Windows detects a slow network connection to a DC, some Group Policy client-side extensions may be skipped during background processing. Keep in mind that features (such as Software Installation and Folder Redirection) are commonly affected. This behavior can cause certain policy settings to appear unapplied until a faster connection is available or the machine is restarted.

Understanding these processing phases is important when troubleshooting Group Policy issues because some settings require a machine restart or user logoff/logon before they take effect.

Note. To manage GPOs in an Active Directory domain, use the Group Policy Management snap-in (gpmc.msc).

GPOs linked at different levels

The following screenshot shows several GPOs linked at different levels of the Active Directory hierarchy. The numbers indicate the order in which the policies are applied. The last policy applied to the Servers OU is the gpoServerSecurity policy (this policy has the highest priority).

If multiple GPOs are linked to the same container, they are processed according to their Link Order.

GPOs in OU process order

GPOs in an OU are processed in reverse order (from bottom to top), meaning the policy with link order 1 is processed last. Use the arrows in the GPMC console to change the link order of the GPO by moving it up or down.

Security Filtering and GPO Processing

The LSDOU rule determines the order in which Group Policy Objects are processed. However, a GPO must also pass security filtering before it can be applied.

By default, a GPO applies to the Authenticated Users group. You can restrict the scope of a policy by using Security Filtering and granting the Read and Apply Group Policy permissions only to specific users, computers, or security groups.

For example, a GPO linked to an OU may have the highest precedence according to the LSDOU rule, but it will not be applied if the target user/computer is not included in the security group specified in the Security Filtering settings.

When troubleshooting Group Policy issues, you should always check both the GPO processing order and the Security Filtering config.

Note. Security Filtering is evaluated after the GPO is discovered through the LSDOU processing order. If the user/computer does not have both Read and Apply Group Policy permissions, the GPO is skipped.

Using WMI Filters with Group Policy

In addition to Security Filtering, you can filter Group Policy Objects by using Windows Management Instrumentation (WMI) Filters. A WMI filter allows a GPO to apply only when a device meets specific criteria.

Here are the common examples include applying a GPO only to:

• Windows 11 computers
• Windows Server devices
• Laptops/portable computers
• Machines with a specific amount of RAM
• Devices running a particular OS version

Windows Version and Build Targeting

When targeting Windows versions with Group Policy, you should not rely only on the major OS version. Windows 11 and Windows Server 2025 use the 10.0 OS version numbering scheme, so the OS build number is important when distinguishing releases.

Current Windows releases include Windows 11 version 24H2 (build 26100) and Windows 11 version 25H2 (build 26200). Windows Server 2025 also uses the 26100 build family. The revision/build number changes with cumulative updates, so WMI filters should not be written as if a single complete build number remains constant.

When a GPO is processed, Windows evaluates the associated WMI filter. If the WMI query returns False, the GPO is skipped even if it has the highest precedence according to the LSDOU rule and passes Security Filtering.

For example, you can link a GPO to an OU that contains all workstations and use a WMI filter to target a specific Windows version/build family.

Keep in mind that you should avoid using a simple string comparison of the Win32_OperatingSystem.Version property to identify Windows 11. The Version property is returned as a string, so comparisons such as Version >= “10.0.22000” are lexicographical rather than numeric and can produce unexpected results with older Windows versions. In addition, Windows 11 releases use different build families, so a single version comparison may not reliably identify all supported Windows 11 releases.

If you need to target specific Windows versions/build families, you should consider using Group Policy Preferences Item-Level Targeting where practical, or use a carefully designed WMI filter based on the exact OS and build values supported by your environment.

For example, a WMI filter can be designed to target a specific Windows build family when a GPO must apply only to a defined OS release. The exact build values should be selected according to the Windows versions and builds supported in your environment.

Note that you should avoid using a broad pattern such as a generic Windows 11 filter:

Version LIKE "10.0.2%"

Pay attention that such a pattern does not match every Windows 11 release and can become outdated when Microsoft introduces new Windows versions.

WMI filters provide you with additional flexibility when targeting Group Policy settings in complex enterprise environments.

Note. WMI filters are evaluated during Group Policy processing and can increase policy app time, especially in large environments. Complex/poorly optimized WMI queries may slow down machine startup/user logon because the filter must be evaluated before the GPO can be applied. As a best practice, you should use WMI filters only when necessary and keep queries as simple as possible.

Understanding Loopback Processing

By default, User Configuration settings are applied based on the location of the user account in AD. However, in some environments, you need user settings to be determined by the machine the user signs in to rather than the user’s OU.

This behavior is controlled by the User Group Policy loopback processing mode setting located under Computer Configuration > Policies > Administrative Templates > System > Group Policy.

Loopback processing is commonly used in:

• Remote Desktop Services (RDS) environments
• Citrix Virtual Apps and Desktops
• Virtual Desktop Infrastructure (VDI)
• Kiosk devices
• Shared machines

There are two loopback modes are available:

• Merge – User policies from the user’s OU are processed first, and then User Configuration settings from the computer’s OU are applied. If conflicts occur, the computer OU settings take precedence.
• Replace – User Configuration settings from the user’s OU are ignored completely. Only User Configuration settings linked to the computer’s OU are applied.

Loopback processing changes the standard LSDOU behavior for User Configuration settings and is frequently used in enterprise environments where users share computers/access centralized desktop platforms.

Note. When loopback processing is enabled in Replace mode, the user’s OU location no longer determines which User Configuration policies are applied. Instead, the applicable user settings are derived from the computer’s location in AD.

Override default order

The administrator can override the default order in which Group Policies are applied in AD by using the following options:

• Change link order (described above).
• Block Inheritance – by default, child OUs inherit all GPOs from their parent, but you can block this inheritance if needed. Right-click on the OU and select Block Inheritance. This blocks inheritance of non-enforced GPOs from parent containers.
  

  

• Enforce GPO – settings cannot be overridden by non-enforced GPOs in child containers and are not blocked by Block Inheritance.

  

• Disable GPO Link – option can be used to prevent a GPO from being applied to a particular AD container (OU).

By default, Group Policy applies to all computers and users in an Active Directory container and its child containers. Understanding the order in which Group Policy is processed and their scopes helps you determine which GPO has precedence.

Group Policy and Intune/MDM Policy Coexistence

Windows devices may receive config from both traditional AD Group Policy and cloud-based management platforms (such as Microsoft Intune) in modern enterprise environments.

Group Policy and MDM policies do not follow the traditional LSDOU precedence model against each other. When the same Windows setting is configured by both a Group Policy and an MDM policy, the effective config depends on the policy area and the MDM/GPO conflict behavior supported by Windows.

In case your organization is transitioning from AD Group Policy to Microsoft Intune, you should identify conflicting settings and define which management channel is authoritative before deploying the corresponding policy.

Windows also provides policy settings that can be used to control MDM policy precedence over Group Policy for supported cases. You should check the behavior for the specific CSP and Windows version before assuming that one management platform always overrides the other.

When troubleshooting a Windows device managed by both AD and Intune, you need to check both the effective Group Policy result and the MDM policy state rather than relying only on gpresult.

Verifying Applied Group Policies

When troubleshooting Group Policy issues, it is important to check which GPOs were actually applied to a user/computer. The effective set of policies is known as the Resultant Set of Policy (RSoP).

On co-managed/Intune-enrolled devices, gpresult shows the Group Policy portion of policy processing. However, it does not provide a complete view of all MDM policies delivered through Intune. When troubleshooting policy conflicts, you should also review the device’s MDM policy state and the corresponding config in Intune.

The easiest way to see the resulting Group Policy config is gpresult. However, gpresult should not be the only troubleshooting tool. When policy processing fails, you should use the Group Policy Operational event log in order to investigate the processing sequence and the underlying error.

To display a summary of applied policies, use the command below:

gpresult /r

You can generate a detailed HTML report with the following command:

gpresult /h report.html

You can also use the graphical Resultant Set of Policy tool:

rsop.msc

These tools help you to determine which GPOs were applied, which policies were filtered out, and whether security filtering, WMI filters, or loopback processing affected the final result.

Troubleshooting Group Policy with Event Viewer

Keep in mind that gpresult and RSoP show the resulting Group Policy config, but they do not always provide enough info to identify why policy processing failed. When a GPO is linked correctly but does not apply as expected, you need to check the Group Policy event logs on the affected machine. 

Open Event Viewer and navigate to Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational. Here you’ll find the Group Policy Operational log records, which contains detailed info about Group Policy processing, including processing stages, applied and denied GPOs, warnings, errors, and other processing details. We recommend using this log when troubleshooting Group Policy app problems.

Also, don’t forget to check the System and Application event logs for related errors.

Each Group Policy processing instance is associated with an Activity ID. When you are troubleshooting a specific processing failure, use the Activity ID from the corresponding Group Policy event to correlate the events belonging to the same processing cycle in the Operational log.

Advanced troubleshooting. If the Group Policy Operational log does not provide enough info, you can try enabling verbose Group Policy Service (GPSvc) logging. Note that this should normally be enabled only temporarily while investigating a specific issue.

Using Group Policy Modeling

In addition to reviewing the Resultant Set of Policy (RSoP) on a client device, you can simulate Group Policy processing by using Group Policy Modeling in the Group Policy Management Console (GPMC).

Group Policy Modeling allows you to predict which policies will apply to a user/computer before they sign in or before a GPO is deployed. The simulation takes into account factors such as:

• GPO link order
• Organizational Unit structure
• Security Filtering
• WMI Filters
• Group membership
• Loopback Processing

To run a simulation, open Group Policy Management and go to Forest > Domains > Group Policy Modeling. The wizard generates a report showing the expected Resultant Set of Policy for a selected user and computer case.

Keep in mind that Group Policy Modeling is especially useful in enterprise environments when planning new GPO deployments/troubleshooting complex policy inheritance issues.

Note. Group Policy Modeling is available only when the domain contains Active Directory DCs and cannot be used for local Group Policy objects.