Group Policy Processing Order Explained

2.2K

When you link Group Policy Objects (GPOs) to users and/or computers containers in Active Directory, 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.

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 Object is the lowest level of precedence allows to configure and apply specific settings only to the local computer (user).
• 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).

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

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 but config a WMI filter so that the policy applies only to machines running Windows 11.

The following WMI query targets only Windows 11 devices:

SELECT * FROM Win32_OperatingSystem
WHERE Version >= "10.0.22000"
AND ProductType = "1"

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.

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).

The easiest way to view applied Group Policies is to use the gpresult command.

In order to display a summary of applied policies, use the command:

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.

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.