Windows 11 Setting Precedence: Group Policy, Registry, Intune, and Local Settings

Windows settings can be configured through Active Directory Group Policy, Local Group Policy, Microsoft Intune, the Windows registry, PowerShell scripts, Windows Settings, application configuration tools, and other management systems.

When two sources configure the same setting differently, the result depends on the type of setting and how Windows processes it. There is no single override order that applies universally to every Windows setting.

Traditional Active Directory Group Policy uses a defined processing hierarchy. Intune, registry changes, security protections, firewall rules, scripts, and Group Policy Preferences may follow different rules.

Overall Windows Settings Precedence Chart

The following chart provides the closest practical overall hierarchy for Windows settings. It ranks sources according to their normal, lasting authority rather than which process happened to write a value most recently.

The chart is ordered from highest to lowest precedence.
( Items at the top take priority over the items below them. )
When two sources configure the same setting, the source listed higher in the chart will normally override the source listed below it, subject to the exceptions noted.

Registry edits, scripts, and management agents can temporarily change a setting after a higher-level policy has been applied. However, the higher-level management system may restore its value during its next refresh.

Active Directory Group Policy Processing Order

For a domain-joined Windows computer, standard Group Policy Objects are processed in the following order:

1. Local Group Policy
2. Site-linked Group Policy
3. Domain-linked Group Policy
4. Parent OU Group Policy
5. Child OU Group Policy

This order is commonly abbreviated as LSDOU: Local, Site, Domain, Organizational Unit.

Policies applied later can overwrite conflicting policies applied earlier. Under normal processing, the GPO linked closest to the affected user or computer has the highest precedence.

For example, if a domain-level GPO disables a Windows feature but a GPO linked to the computer’s child OU enables it, the child OU setting normally wins.

Microsoft documents this order in its Group Policy processing documentation.

GPO Link Order

Multiple GPOs can be linked to the same site, domain, or OU. Within that location, the GPO displayed as Link Order 1 has the highest precedence.

Link Order 1 is processed after the other linked GPOs and therefore wins when multiple GPOs configure the same setting differently.

Enforced GPOs

The Enforced option changes the normal hierarchy.

If a domain-level GPO is marked Enforced, a conflicting GPO linked to a lower OU cannot override it. Enforced GPOs also continue to apply when an OU has Block Inheritance enabled.

Enforced should be used selectively because it can make policy troubleshooting and delegation more difficult.

Block Inheritance

Block Inheritance prevents ordinary GPOs linked to higher Active Directory containers from being inherited by the selected domain or OU.

It does not stop an Enforced GPO.

For example, an OU with Block Inheritance enabled may avoid settings from a normal domain-level GPO, but it will still receive settings from a domain-level GPO marked Enforced.

Security and WMI Filtering

Security filtering and WMI filtering do not override another policy. They determine whether a GPO applies in the first place.

A GPO excluded by security filtering or a false WMI filter does not participate in the conflict.

Not Configured Does Not Mean Disabled

A setting marked Not Configured does not normally reverse a setting configured somewhere else. It means that the current GPO does not provide an instruction for that setting.

For example:

• Local Group Policy disables Control Panel.
• A domain GPO leaves the setting Not Configured.
• The local setting remains effective because the domain GPO did not configure a conflicting value.

To override the local policy, the domain GPO would need to configure the corresponding opposite state, if the policy supports one.

Local Group Policy Precedence

Windows can contain more than one Local Group Policy Object.

Local policies are processed in this order:

1. Local Computer Policy
2. Administrators or Non-Administrators Local Group Policy
3. User-specific Local Group Policy

The last applicable local policy has the highest precedence. Therefore, a user-specific local policy can override a conflicting setting from the broader Local Computer Policy.

Microsoft confirms this processing order in its documentation for working with Local Group Policy Objects.

When the computer is joined to an Active Directory domain, applicable domain-based GPOs are processed after these local policies and normally override conflicting local settings.

Local Group Policy Editor is not included with Windows Home editions. However, policy-related registry values can still exist if they are written by software, scripts, provisioning tools, or an upgrade from another Windows edition.

Computer Settings vs. User Settings

Computer Configuration applies to the device and normally affects every user who signs in. User Configuration applies to an individual user.

When Windows or an application provides equivalent computer-scope and user-scope policies, the computer policy generally has priority.

However, this should not be treated as a universal rule for arbitrary HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER registry values. The application must be designed to evaluate those locations in that order.

Group Policy loopback processing can also change how user settings are selected:

• Merge mode applies the user’s normal policies first and then applies user settings associated with the computer. The computer-related user policies have higher precedence.
• Replace mode ignores the user’s normal GPO list and uses only the user settings associated with the computer.

Loopback processing is commonly used for kiosks, conference-room computers, classrooms, and other shared devices.

Registry Changes vs. Group Policy

The registry is not a separate policy authority in the same way that Active Directory or Intune is. Many Group Policy settings ultimately work by writing values into the Windows registry.

For Administrative Template settings, Group Policy stores instructions in Registry.pol files and applies the corresponding values to the registry. Microsoft describes this in its Registry Policy file format documentation.

Editing a Group Policy-Managed Value Manually

If an administrator manually changes the exact registry value controlled by Group Policy, the manual change might take effect temporarily.

However, Group Policy can restore the configured value during subsequent policy processing, such as:

• A forced Group Policy update
• Computer startup
• User sign-in
• A background policy refresh
• A change to the applicable GPO

Therefore, manually changing a policy-managed registry value is not a reliable way to override Group Policy.

Running the following command forces Group Policy to be reapplied:

gpupdate /force

Some policies require a restart or sign-out before the effective behavior changes.

Policy Keys vs. Preference Keys

Applications designed according to Microsoft’s registry policy model generally check for an administrative policy value first. If no policy exists, the application checks the user’s preference value.

Policy values are commonly stored under locations such as:

HKEY_LOCAL_MACHINE\Software\Policies
HKEY_CURRENT_USER\Software\Policies

Normal application preferences may be stored elsewhere under Software.

According to Microsoft’s registry-based policy guidance, policy keys should take priority over preference keys.

This is why changing a value through an application’s interface may have no effect when the setting is centrally managed. The application continues to read the administrative policy value instead of the user preference.

Group Policy Settings vs. Group Policy Preferences

Group Policy settings and Group Policy Preferences are not the same.

A standard policy is intended to enforce a configuration. The associated interface may be disabled or display a message such as “Some settings are managed by your organization.”

A Group Policy Preference sets or updates a preferred configuration but usually does not prevent a user or administrator from changing it afterward.

By default, Group Policy Preferences are reapplied during Group Policy refreshes. A user’s change may work temporarily and then be replaced during the next refresh.

Preferences can also be configured with:

• Apply once and do not reapply
• Remove this item when it is no longer applied
• Item-level targeting
• Create, Replace, Update, or Delete actions

A preference can remain on the computer after the GPO stops applying unless Remove this item when it is no longer applied is enabled. This persistent behavior is sometimes informally called tattooing.

Microsoft provides a detailed comparison in its Group Policy Preferences documentation.

Microsoft Intune and MDM vs. Group Policy

Windows 10 and Windows 11 can receive configuration through Mobile Device Management, commonly Microsoft Intune.

There is no universal rule stating that Intune always overrides Group Policy or that Group Policy always overrides Intune.

Windows includes the following Policy CSP setting:

./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP

When MDMWinsOverGP is set to 1, an applicable MDM policy takes precedence over an equivalent Group Policy setting. Windows blocks the corresponding Group Policy value and uses the MDM configuration.

This behavior has an important limitation. It applies only to supported settings within the Windows Policy CSP that have an equivalent Group Policy mapping. It does not automatically cover settings managed through other CSPs, including many Defender and Firewall settings.

Microsoft warns that configuring the same setting through MDM and Group Policy can otherwise create a race condition with no guaranteed winner. More information is available in the ControlPolicyConflict Policy CSP documentation.

The safest approach is to assign one management authority to each setting instead of configuring contradictory values through both Intune and Group Policy.

Computers Managed by Both Active Directory and Intune

A computer being joined to Active Directory and enrolled in Intune does not automatically make Intune the higher authority.

For equivalent settings within the supported Windows Policy CSP:

1. Group Policy normally retains precedence by default.
2. Intune takes precedence when MDMWinsOverGP is enabled.
3. Settings delivered through other CSPs may use different conflict, merging, or precedence rules.

A computer joined only to Microsoft Entra ID does not receive traditional Active Directory domain GPOs. It is normally managed through Intune, another MDM platform, provisioning packages, scripts, or Local Group Policy.

PowerShell Scripts, Scheduled Tasks, RMM Tools, and Other Management Agents

PowerShell scripts, startup scripts, logon scripts, scheduled tasks, Microsoft Configuration Manager, remote monitoring and management tools, and third-party security agents do not participate directly in the LSDOU ( Local, Site, Domain, then Organizational Unit. )hierarchy.

If one of these tools modifies the same registry value as Group Policy, the effective result may depend on which process runs last.

For example:

1. A domain GPO writes a registry value during startup.
2. An RMM script changes the value five minutes later.
3. The RMM value becomes effective.
4. A later Group Policy processing event restores the GPO value.

This can cause a setting to repeatedly switch between two values. The correct fix is to locate and remove the conflicting configuration source.

Security Protections Can Block Configuration Changes

Some security features enforce their own protection systems.

Microsoft Defender Tamper Protection can block changes to protected Defender settings made through:

• The registry
• PowerShell
• WMI
• Local tools
• Group Policy

Microsoft notes that a Group Policy change may appear to succeed even though Tamper Protection blocked the effective change. Protected changes should be made through an authorized management channel or during Defender troubleshooting mode.

See Microsoft’s Tamper Protection overview.

Tamper Protection is available in Windows 10 and later. It is not part of the standard Windows 7 policy model.

Windows Firewall Uses Its Own Precedence Rules

Windows Firewall does not decide every conflict based only on whether a rule came from Local Group Policy, Active Directory Group Policy, or MDM.

For conflicting firewall rules:

1. An explicit block rule overrides a conflicting allow rule.
2. An explicit allow rule overrides the default block behavior.
3. A more specific rule normally overrides a less specific rule, except when an explicit block rule applies.

Administrators can also control whether local firewall rules are merged with centrally managed rules.

Microsoft documents these rules in its Windows Firewall rule precedence guidance.

This is an example of why the general Group Policy hierarchy cannot predict every Windows configuration result.

Does This Work the Same in Windows 7 and Windows 10?

Yes. Traditional Active Directory and Local Group Policy use essentially the same precedence rules in Windows 7, Windows 10, and Windows 11. Local, Site, Domain, and OU policies are processed in the same general order, including Enforced policies, Block Inheritance, link order, and loopback processing.

The primary differences involve newer management and security technologies. Windows 7 does not support modern Windows MDM, Policy CSP, MDMWinsOverGP, or Microsoft Defender Tamper Protection. Windows 10 version 1803 and later and Windows 11 can be managed through Intune or another MDM platform, creating additional potential conflicts with Group Policy. Newer Windows versions also contain policy settings that Windows 7 does not recognize or support.

How to Determine Which Policy Is Winning

Do not rely only on the value shown in Registry Editor. The registry displays the current value but usually does not identify which management source created it.

1. Identify the exact setting and determine whether it applies to the computer or user.

2. Generate a Group Policy Results report:

   gpresult /h gpresult.html

3. Open rsop.msc to review the Resultant Set of Policy.

4. Check the Group Policy operational log:

   Event Viewer
   Applications and Services Logs
   Microsoft
   Windows
   GroupPolicy
   Operational

5. Check whether the device is joined to Active Directory, Microsoft Entra ID, or both.

6. On an Intune-managed device, open:

   Settings
   Accounts
   Access work or school
   Select the connected account
   Advanced Diagnostic Report
   Create Report

7. Check for scripts, scheduled tasks, Configuration Manager baselines, RMM policies, or security agents that may be changing the setting.

8. Determine whether Defender Tamper Protection or another security control is blocking the change.

9. Run gpupdate /force, then restart or sign out if the policy requires it.

10. Confirm the effective result instead of assuming that a successful command changed the setting.