A Practical Guide to Group Policy (GPO) — How It Works, Confirming Application, and Choosing Between GPO and Intune

“I changed the GPO but nothing happened.” “I ran gpupdate and the setting still did not change.” “The app runs on my development machine but not on the PCs at the customer site.” Problems like these become much easier to investigate once you separate which GPOs are in scope, which setting wins, and when processing happened.

Group Policy is the mechanism that distributes and manages Windows settings across an organization. Being told that something is “distributed via GPO” does not tell you what is actually in effect on a given PC or for a given user. You have to compare the configuration on the distributing side with the result on the receiving side.

This article is a practical introduction for IT staff at small and midsize businesses who have inherited an AD environment, and for developers who deploy business apps to domain-joined PCs. It covers the order of application, when settings take effect, triage with gpresult and the event log, ADMX and the Central Store, and how to choose between GPO and Intune. The explanations are based on primary sources as of August 2026.

Start From What You Are Running Into

If this is your first read, pick up the terminology in Chapter 2, understand the mechanism in Chapters 3 and 4, and then move on to the verification steps in Chapter 5. If you are in the middle of an investigation, start from Chapter 5 and go back to the explanations of precedence and timing as the results require.

1. The Bottom Line First

“Which Setting Wins” and “When It Arrives” Are Separate Problems

Group Policy is processed in the order local, site, domain, OU (LSDOU), and when the same setting conflicts, the last write wins. The local GPO is the weakest layer. That said, Block Inheritance and Enforced change this default flow.¹

Application comes in two forms: foreground processing at startup and at sign-in, and background refresh at a default interval of roughly 90 minutes plus a random offset of 0 to 30 minutes. The background refresh on domain controllers defaults to 5 minutes. gpupdate /force reapplies every setting; it is not an all-purpose command that also applies, on the spot, settings that are only ever processed at sign-in or at restart.²³

Check the Result That Arrived Before You Keep Changing Things

Triage starts from the RSoP report produced by gpresult /h. Check the applied GPOs, the denied GPOs and their reasons, and the winning GPO for each setting. When you need to dig into processing failures or delays, use the GroupPolicy operational log.⁴⁵

Administrative template settings are, as a rule, written to registry locations such as Software\Policies, and policy-aware apps give those values precedence over their own settings. “Not Configured” writes no value at all. Some settings do write outside the dedicated keys, however, so when a value remains behind, check where it was written.⁶

Align the Management Method With the Assumptions Your App Depends On

In a domain, ADMX definitions are consolidated into the PolicyDefinitions Central Store in SYSVOL. It exists so that GPMC references one common set of templates.⁷

Choose between GPO and Intune based on the device’s identity foundation and where it is used. In a hybrid environment, avoid configuring the same setting twice and decide who owns each area. Group Policy analytics is useful for sorting settings before a migration.⁸⁹

For developers too, GPO is part of the environment specification. Settings that change an app’s assumptions, such as the execution policy, firewall local rule merging, and proxy and drive configuration, are distributed centrally. When something “fails only at the customer site,” confirm those assumptions with the report and the actual values.¹⁰¹¹

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (29 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. What Group Policy Is — Local GPOs and Domain GPOs

Group Policy is the mechanism by which an administrator centrally defines Windows settings and applies them to target computers and users. A bundle of settings is called a GPO (Group Policy Object).

Start by separating “the local GPO managed inside the PC itself” from “the domain GPO distributed from AD.”

Where Settings Live: Local or Domain

A workgroup PC, one that is not domain-joined, processes only the local GPO.¹ In other words, when people say a machine is “managed by GPO,” in practice they almost always mean a domain GPO.

flowchart TB
    accTitle: GPOs processed by a workgroup PC and by a domain-joined PC
    accDescr: A workgroup PC processes only the local GPO, while a domain-joined PC processes the domain GPOs distributed from Active Directory in addition to the local GPO
    pc{"How is the PC joined?"}
    pc -->|Workgroup| wg["Processes the local GPO only"]
    pc -->|Domain-joined| dom["Local plus domain GPOs"]
    dom -.-> note["GPOs in practice are almost all domain GPOs"]

Figure 1: A workgroup PC processes only the local GPO, while a domain-joined PC also processes domain GPOs.

What Settings Target: The PC or the User

Whatever the GPO, its contents fall into two broad branches.

• Computer Configuration: settings that take effect for anyone who signs in to that PC. Applied at startup.
• User Configuration: settings that take effect for that user no matter which PC they sign in to. Applied at sign-in.

The axis of “is this setting tied to the PC or to the person” shows up consistently in the order of application and in confirming that a setting took effect, both of which follow. Some items exist under both branches, so make it a habit to look at both whenever you are hunting for a setting.

flowchart TB
    accTitle: The two branches inside a GPO
    accDescr: Every GPO has a Computer Configuration branch and a User Configuration branch, where Computer Configuration is applied at startup and takes effect for anyone who signs in to that PC, and User Configuration is applied at sign-in and takes effect no matter which PC the user signs in to
    gpo["Contents of a GPO"] --> comp["Computer Configuration"]
    gpo --> user["User Configuration"]
    comp --> boot["Applied at startup"]
    user --> logon["Applied at sign-in"]
    boot -.-> anyone["Takes effect for anyone who signs in"]
    logon -.-> anypc["Takes effect on any PC"]

Figure 2: A GPO has two branches, Computer Configuration tied to the PC and User Configuration tied to the person.

3. How Application Works — LSDOU’s “Last Write Wins” and Controlling Inheritance

3.1. LSDOU: Local, Site, Domain, OU

On a domain-joined PC, GPOs are processed in the following order.¹

1. The local GPO
2. GPOs linked to the site
3. GPOs linked to the domain
4. GPOs linked to an OU (organizational unit) — processed from the highest OU down, ending with the GPOs on the OU that directly contains the target computer or user

The name LSDOU is taken from those initials. It expresses the order in which policies are processed, not an order “from highest precedence down.”

When several GPOs configure the same setting, the GPO processed later wins. Settings that do not conflict are simply combined.¹

In this default order, the GPO on the OU closest to the target is the strongest and the local GPO is the weakest. “I fixed it in gpedit.msc and it reverted” is exactly this behavior working as specified. The exceptions that change inheritance are covered in Section 3.2.

flowchart TB
    accTitle: The LSDOU processing order and last write wins
    accDescr: GPOs are processed in the order local, site, domain, OU, and in a conflict the GPO processed later wins, so the GPO on the OU closest to the target is the strongest and the local GPO is the weakest
    l["1. Local GPO"] --> s["2. Site"]
    s --> d["3. Domain"]
    d --> ou["4. OU (from the top down)"]
    ou --> win["Last write wins in a conflict"]
    win -.-> strongest["The GPO on the nearest OU is strongest"]
    win -.-> weakest["The local GPO is weakest"]

Figure 3: LSDOU is the order in which policies are processed, and when the same setting conflicts, the GPO processed later wins.

At the Same Location, the Lowest Link Order Number Wins

When several GPOs are linked to the same site, domain, or OU, check the link order on the “Linked Group Policy Objects” tab in GPMC.

The GPO with the lowest number is processed last and therefore has the highest precedence. It is important not to read this as “a lower number means it is processed first.”¹

flowchart TB
    accTitle: Link order when several GPOs sit at the same location
    accDescr: When several GPOs are linked to the same site or domain or OU, the processing order is decided by the link order in GPMC, and the GPO with the lowest number is processed last and takes the highest precedence
    multi["Several GPOs at the same location"] --> tab["Decided by the link order in GPMC"]
    tab --> last["The lowest-numbered GPO is processed last"]
    last --> win["Wins by last write and takes highest precedence"]

Figure 4: At the same link target, the GPO with the lowest link order number is processed last and wins.

3.2. Block Inheritance and Enforced

Block Inheritance and Enforced are the mechanisms that create exceptions to the default order in Section 3.1. Read them by separating where you set them from what they stop.¹

• Block Inheritance: set on a domain or an OU, it stops GPOs from being inherited from above. It is the tool for “this OU alone should not receive the company-wide standard.”
• Enforced (formerly No Override): set on a GPO link, it makes that GPO always apply even where inheritance is blocked below, and stops lower GPOs from overwriting it. When Block Inheritance and Enforced collide, Enforced wins.¹

flowchart TB
    accTitle: How Block Inheritance and Enforced relate
    accDescr: Block Inheritance stops GPOs from being inherited from above, but an enforced GPO always applies even where inheritance is blocked below and cannot be overwritten by lower GPOs
    upper["GPO from above"] --> blocked{"Inheritance blocked below?"}
    blocked -->|No| inherit["Inherited as is"]
    blocked -->|Yes| enforced{"Is the GPO link enforced?"}
    enforced -->|No| stop["Inheritance stops"]
    enforced -->|Yes| apply["Always applied"]
    apply -.-> noover["Not overwritten by lower GPOs"]

Figure 5: Block Inheritance stops inheritance from above, but an enforced GPO crosses the block and always applies.

Limit What You Use Enforced For

Because Enforced changes the default “last write wins,” using it liberally produces more results that do not match your intuition even when you read the RSoP. The rule of thumb is to limit it to things like security settings that absolutely must hold company-wide.

That covers inheritance and precedence. Whether a GPO can be applied to a target at all is also decided by security filtering, which comes next.

3.3. Security Filtering

Application Requires Both “Read” and “Apply”

Beyond the link target, who a GPO applies to can also be narrowed per GPO. The target user or computer must hold both the “Read” and the “Apply group policy” permissions on that GPO.¹³

By default, Authenticated Users, which includes both users and computers, holds both permissions, so everything under the link target is in scope. Narrowing this down to a specific security group is what security filtering does.

The filter applies to the GPO as a whole. It is not a mechanism for narrowing individual settings inside a GPO to different targets.¹³

For User-Targeted GPOs, Keep the PC’s Read Permission Too

When you narrow the target, do not remove “Read” from Authenticated Users. Since MS16-072 (2016), user-targeted policy is retrieved under the computer’s security context. If the PC cannot read the GPO, it will not be applied even when the target user holds both permissions.¹⁴

Think of the required permissions as two separate things.

• Give the target group Read plus Apply group policy.
• Leave Read only for Authenticated Users or Domain Computers. The Apply permission is not needed.¹⁴

flowchart TB
    accTitle: How security filtering decides whether a GPO applies
    accDescr: For a GPO to apply, the target user or computer must hold both the Read and the Apply group policy permissions, and a user-targeted GPO additionally requires that the computer account be able to read it
    target["Target under the GPO link"] --> perm{"Both Read and Apply?"}
    perm -->|No| deny["Denied by filtering"]
    perm -->|Yes| usergpo{"User-targeted GPO?"}
    usergpo -->|No| apply["Applied"]
    usergpo -->|Yes| comp{"Can the computer read it?"}
    comp -->|Yes| apply
    comp -->|No| deny2["Not applied (MS16-072)"]

Figure 6: Application requires both “Read” and “Apply group policy,” and a user-targeted GPO also requires the computer account to have Read.

After Changing a Group, Confirm With a New Token

Targeting the wrong object — “the setting is computer-targeted, but only the user was added to the group” — is a common stumble. Check first whether the setting is on the computer side or the user side.

The other one is “I removed them from the group and it still applies.” Membership is evaluated from the security token built at sign-in, so simply waiting for a background refresh changes nothing.

A user’s group change reaches the filter after a sign-out and sign-in, and a computer’s after a restart, once a new token has been built.

flowchart TB
    accTitle: How long a group change takes to reach the filter
    accDescr: Group membership is evaluated from the security token built at sign-in, so a user's change reaches the filter only after signing in again and a computer's only after a restart builds a new token
    change["Change the members of a group"] --> old["Not reflected while the old token stands"]
    old --> u["The user signs in again"]
    old --> c["The computer restarts"]
    u --> token["Evaluated with the new token"]
    c --> token
    token --> ok["Reflected in the filter"]
    old -.-> bg["A background refresh does not resolve it"]

Figure 7: A group change reaches the filter only once a sign-out or a restart builds a new token.

An Application for Shared PCs: Loopback Processing

On shared PCs and Remote Desktop servers, you sometimes want to “swap the User Configuration for everyone who signs in to this PC.” The special mode for that is loopback processing.

It applies user settings based on the computer’s location, and has two modes, Replace and Merge. It is an advanced feature used on kiosk terminals and classroom PCs, and this article does no more than note that it exists.¹⁵

flowchart TB
    accTitle: The idea behind loopback processing
    accDescr: Loopback processing is a special mode that applies User Configuration based on the computer's location, has the two modes Replace and Merge, and is used where every person who signs in should get the same user settings, such as shared PCs and kiosk terminals
    shared["Shared PCs, kiosk terminals, and the like"] --> lb["Loopback processing"]
    lb --> base["Decided by the computer's location"]
    base --> rep["Replace mode"]
    base --> mrg["Merge mode"]
    lb -.-> aim["Takes effect for everyone who signs in"]

Figure 8: Loopback processing is a special mode that applies User Configuration based on the computer’s location, and it has the two modes Replace and Merge.

4. When Settings Take Effect — Foreground Processing and Background Refresh

After you change a setting, the time for it to be applied may simply not have come yet. Here, separate whether the device can reach a DC from when that particular setting is processed.²

Separate Startup and Sign-in From Refreshes While the Machine Runs

First, the Device Has to Be Able to Reach a DC

On a running device that can reach a domain controller, settings that support background refresh spread across the fleet within roughly two hours by default. They do not reach offline devices, or laptops taken off-site without a VPN connection, until the next time the device connects to a DC.

Settings that are only ever applied by foreground processing require waiting for a startup or a sign-in on top of that.

The Difference Between gpupdate and /force

When you are in a hurry, run gpupdate on the target PC. Normally it applies only the settings that changed; adding /force reapplies every setting whether or not it changed.³

rem Refresh only what changed (normally this is enough)
gpupdate

rem Reapply every setting (when you suspect the cached state)
gpupdate /force

flowchart TB
    accTitle: DC reachability and how settings arrive
    accDescr: On a running device that can reach a domain controller, settings that support background refresh spread within roughly two hours, but they do not reach an offline device or a laptop taken off-site without a VPN connection until it next connects to a DC
    pc{"Can it reach a DC?"}
    pc -->|Yes| ok["Spreads within roughly two hours"]
    pc -->|No| ng["Does not arrive until it connects"]
    ng -.-> ex["Offline devices and laptops off-site without a VPN"]

Figure 9: A running device that can reach a DC gets the settings within roughly two hours, while an offline device gets nothing until it next connects to a DC.

Even /force Cannot Skip Foreground Processing

User-targeted software installation and folder redirection are processed only at sign-in, and computer-targeted software installation only at startup.³

The /logoff option of gpupdate signs out after the refresh and /boot restarts after it. When adding /force changes nothing, check whether the setting is one of the kinds that requires a sign-in or a restart.³

flowchart TB
    accTitle: The paths by which a setting takes effect
    accDescr: A GPO change arrives within the default interval of roughly 90 minutes plus a 0 to 30 minute offset if the setting supports background refresh, while a setting that is only applied by foreground processing has to wait for a startup or a sign-in, and even gpupdate needs /logoff or /boot for foreground-only settings when you are in a hurry
    change["Change a GPO"] --> kind{"Supports background refresh?"}
    kind -->|Yes| bg["Refreshed in roughly 90 minutes plus 0 to 30"]
    kind -->|No| fg["Applied at startup or sign-in"]
    bg --> done["Takes effect"]
    fg --> done
    rush["When you are in a hurry"] -.-> upd["Run gpupdate"]
    upd -.-> force["/force reapplies everything"]
    upd -.-> reboot["Foreground needs /logoff or /boot"]

Figure 10: Background refresh delivers only the settings that support it, and settings applied only by foreground processing still need a sign-out or a restart after gpupdate.

5. Triage When a Setting Does Not Take Effect — gpresult, the Event Log, and the Registry

The tools you use have different roles. gpresult shows the result of application, the operational log shows the course of processing, and the registry shows the actual values that were written. Rather than immediately changing settings again, narrow down the cause from the result.

5.1. Check the RSoP With gpresult /h

The final result of several overlapping GPOs is called RSoP (Resultant Set of Policy). The standard gpresult tool produces an HTML report from an elevated command prompt, which is easier to read.⁴⁵

In the example below, create the output folder C:\temp before running it. When you read the report, also confirm that it is the result for the PC and the user you mean to investigate.

rem Write an HTML report of the RSoP for both the user and the computer
gpresult /h C:\temp\gp-report.html /f

rem To check only the summary on the console
gpresult /r
gpresult /scope computer /r

Do Not Stop at “It Was Applied”

In the report, look at the following three things in order. Even when the GPO you want is in the list, the setting will not have the value you expect if another GPO overwrites it.

1. The list of applied GPOs — is the GPO you want in it
2. The list of denied GPOs and the reasons — the reason it was not applied, such as security filtering, a WMI filter, or an empty GPO, is shown⁵
3. The winning GPO for each setting — which GPO’s value decided the setting you care about. If a different GPO wins, revisit the precedence rules in Chapter 3

flowchart TB
    accTitle: The three things to look at first in an RSoP report
    accDescr: In a gpresult report, first check whether the GPO you want is in the list of applied GPOs, then check the list of denied GPOs and the reasons, and finally use the winning GPO for each setting to identify whose value won
    rep["Open the RSoP report"] --> one["1. List of applied GPOs"]
    one --> two["2. Denied GPOs and reasons"]
    two --> three["3. Winning GPO per setting"]
    three -.-> review["Revisit if a different GPO wins"]

Figure 11: Read an RSoP report in the order applied GPOs, denied GPOs and reasons, and the winning GPO for each setting.

5.2. The GroupPolicy Operational Log

Tracking Processing Failures and Delays

Failures that gpresult alone does not reveal, and problems where processing takes too long, are checked in the GroupPolicy operational log in Event Viewer.

Its location is Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational. The log name is Microsoft-Windows-GroupPolicy/Operational, and it records everything from the start to the end of processing, the lists of applied and denied GPOs, and the reasons for denial.⁵

Narrow to a Single Processing Run With ActivityID

Each run of policy processing is assigned a unique ActivityID. The procedure Microsoft documents is to pick up the ActivityID from a warning or error in the System log and use a custom view to narrow down to the events of that same run. That way you follow one run from start to finish without mixing in records from another.⁵

flowchart TB
    accTitle: How to narrow down the GroupPolicy operational log
    accDescr: Each run of policy processing is assigned a unique ActivityID in the GroupPolicy operational log, so pick the ActivityID up from a warning or error in the System log and use a custom view to narrow the reading down to the events of that one run
    sys["Warning or error in the System log"] --> aid["Pick up the ActivityID"]
    aid --> cv["Narrow down with a custom view"]
    cv --> one["Read the events of one processing run"]
    one -.-> rec["Applied and denied GPO lists with reasons"]

Figure 12: For the operational log, pick up the ActivityID from the System log and use a custom view to read just one run of policy processing.

5.3. The Relationship to the Registry’s Policies Keys

Administrative template policies, covered in the next chapter, are ultimately written as registry values. As a rule, they are written to the following dedicated policy keys.⁶

• HKEY_LOCAL_MACHINE\Software\Policies (Computer Configuration; the recommended location)
• HKEY_CURRENT_USER\Software\Policies (User Configuration; the recommended location)
• HKLM\Software\Microsoft\Windows\CurrentVersion\Policies and HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

Policy Values Are Read Before an App’s Own Settings

A policy-aware app behaves like this: it reads the Policies key first, uses that value if one is present, and falls back to its own setting or a default if there is none. A policy left “Not Configured” writes no value to the registry.⁶

In other words, an administrative template that uses the dedicated policy keys does not rewrite the app’s own setting and leave a “tattoo” behind; it places an enforced value in a separate location. Stop configuring it and the app returns to following its own setting.

flowchart TB
    accTitle: Precedence between a policy value and an app setting
    accDescr: A policy-aware app first reads the Policies key and uses that value if one is present, otherwise it uses its own setting or a default, and a policy left Not Configured writes nothing to the registry
    app["A policy-aware app reads a setting"] --> haspol{"Is there a value in the Policies key?"}
    haspol -->|Yes| pol["The policy value wins"]
    haspol -->|No| pref["Uses its own setting or a default"]
    notconf["A Not Configured policy"] -.-> nowrite["Writes nothing to the registry"]

Figure 13: A policy does not rewrite the app’s own setting; instead an enforced value placed elsewhere is read with higher precedence.

Watch Out for Settings That Write Outside the Dedicated Keys and Leave Values Behind

Not every policy writes to a dedicated key. “Enable Win32 long paths,” for example, writes to LongPathsEnabled under HKLM\SYSTEM\CurrentControlSet\Control\FileSystem. Older-generation and third-party templates also include ones that write to arbitrary paths.

Settings of this kind leave their value behind even after you stop configuring the policy. Check which key the setting you care about writes to, using the ADMX definition, the setting’s explanatory text, and the gpresult report.

Values written outside the dedicated keys by a script or by Group Policy Preferences are ordinary registry values as well. Unlike the dedicated policy keys, treat them as values that remain after you stop configuring them.

Check Where the Value Was Actually Written

Start by looking at the actual values under the Policies keys. But do not conclude that “GPO has no influence here” just because nothing is there; also check whether the setting is one that writes outside the dedicated keys. The commands below are an example of looking under Policies, where most policies write.

# Example of checking values distributed by policy directly (most policies write under Policies)
Get-ChildItem "HKLM:\SOFTWARE\Policies" -Recurse | Select-Object Name
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -ErrorAction SilentlyContinue

flowchart TB
    accTitle: Triage steps when a setting does not take effect
    accDescr: First check the applied and denied GPOs in the RSoP report from gpresult, then narrow the GroupPolicy operational log down by ActivityID if that is not enough, and confirm the distributed values directly in the registry's Policies keys
    start["The setting does not take effect"] --> rsop["Check the RSoP with gpresult /h"]
    rsop --> found{"Do you see the applied and denied reasons?"}
    found -->|Yes| fix["Revisit precedence and filtering"]
    found -->|No| oplog["Read the GroupPolicy operational log"]
    oplog -.-> aid["Narrow to one run with ActivityID"]
    rsop -.-> reg["Check the actual values in the Policies keys"]

Figure 14: Triage proceeds mechanically from gpresult /h, to the GroupPolicy operational log when that is not enough, and to a direct check of the Policies keys for actual values.

6. Administrative Templates (ADMX) and the Central Store

ADMX Holds the Definitions, ADML the Display Strings

The items listed under “Administrative Templates” in GPMC have their setting definitions written in ADMX files and their per-language display strings in ADML files.

Every PC has the definitions that ship with the OS in C:\Windows\PolicyDefinitions, and the management tools read them to build the settings screen.⁷

In a Domain, Reference a Shared Central Store

For domain operations, create a PolicyDefinitions folder under SYSVOL on a DC. An example is \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions.

The contents are replicated to every DC in the domain, and the Group Policy tools then reference the Central Store by default. It exists to prevent the problem of template versions differing between management machines so that the visible items do not match. ADML files go into per-language subfolders such as ja-JP.⁷

flowchart TB
    accTitle: How the Central Store works
    accDescr: Creating a PolicyDefinitions folder under SYSVOL on a domain controller replicates its contents to every domain controller and makes the Group Policy tools reference the Central Store by default, so definitions no longer differ between management machines
    create["Create it under SYSVOL"] --> cs["PolicyDefinitions"]
    cs --> repl["Replicated to every DC"]
    cs --> ref["GP tools reference it by default"]
    ref -.-> benefit["Definition mismatches between machines disappear"]
    cs -.-> adml["ADML files go into per-language folders"]

Figure 15: The PolicyDefinitions folder in SYSVOL is replicated to every domain controller, and the Group Policy tools reference it by default.

Prepare Updates in a Working Folder, Then Switch Over

Microsoft distributes ADMX files for new Windows versions release by release. What you update is the Central Store. Replacing C:\Windows\PolicyDefinitions on each PC with the downloaded version is not supported.⁷

Update an existing store by working through the following steps rather than overwriting the production folder directly.

1. Prepare a working folder with a version name, such as PolicyDefinitions-24H2.
2. Assemble the full ADMX set for the OS and for apps such as Office and Edge.
3. Rename the current PolicyDefinitions to something like PolicyDefinitions-23H2 to set it aside.
4. Rename the working folder to PolicyDefinitions so it is referenced as production.⁷

The folder that gets referenced is the one named PolicyDefinitions. Simply placing files in a version-named folder has no effect. Keeping the old folder aside lets you roll back if something goes wrong.⁷

flowchart TB
    accTitle: Steps for updating the Central Store
    accDescr: To update, assemble the full ADMX set for the OS and for apps in a version-named working folder, rename the current folder to set it aside, then rename the working folder to the production name PolicyDefinitions, and roll back to the folder you set aside if a problem occurs
    work["Version-named working folder"] --> gather["Assemble the OS and app sets"]
    gather --> evac["Rename the current one and set it aside"]
    evac --> rename["Rename the working folder to the production name"]
    rename --> live["Referenced as production"]
    live -.-> back["Roll back to the old folder on trouble"]

Figure 16: For an update, assemble the full set in a working folder, set the current one aside, and promote by renaming.

7. GPO vs. Intune (MDM/CSP) vs. Manual and Script Distribution — A Decision Table

GPO is no longer the only option for configuration management of Windows devices. MDM, of which Intune is the representative, configures OS settings through a mechanism called a CSP (Configuration Service Provider). Here is a decision table for choosing which one to build around.

Decide on the Device’s Identity Foundation and Location

The basis is whether the device is founded on AD or on Microsoft Entra, and where it is used. GPO is reliable for stationary in-office PCs domain-joined to on-premises AD, while domain GPOs never reach an Entra joined mobile PC.

The important thing is not to treat in-office and off-site devices as having the same reachability conditions.

In a Hybrid Environment, Decide Who Owns Each Setting

Even at small and midsize businesses, hybrid operation that combines domain join with Intune enrollment is common. What you want to avoid here is configuring the same setting through both GPO and MDM.

Policy CSP includes MDMWinsOverGP, which gives MDM precedence in a conflict. It applies, however, only to the corresponding policies inside Policy CSP. Configure a setting that is not under that control twice and there is no guarantee which one wins. Microsoft also advises against duplicate configuration.⁸

The principle is to decide “this area is GPO, that area is Intune” and commit each area to one of them.

flowchart TB
    accTitle: Choosing between GPO and Intune
    accDescr: GPO suits devices whose identity foundation is on-premises AD and that stay in the office, Intune suits Entra joined and off-site devices, and in a hybrid environment you avoid configuring the same setting twice and commit each setting area to one side
    q{"Identity foundation and location?"}
    q -->|AD joined and in the office| gpo["GPO is reliable and fine-grained"]
    q -->|Entra joined or off-site| intune["Intune reaches off-site devices"]
    q -->|Hybrid| split["Commit each area to one side"]
    split -.-> warn["Duplicate configuration has no guaranteed result"]
    split -.-> ana["Use Group Policy analytics to sort"]

Figure 17: Choose based on the device’s identity foundation and location, and in a hybrid environment do not configure the same setting through both GPO and MDM.

Use Group Policy Analytics to Sort Before You Move

The entry point for considering a migration is Intune’s Group Policy analytics. Import GPOs exported as XML from GPMC and it analyzes, setting by setting, what is supported by MDM, what is deprecated, and what cannot be supported. Settings that are supported can be migrated into an Intune settings catalog policy.⁹

Use it not as “a tool that moves everything,” but as a tool for sorting what can be moved, what cannot, and what to drop.

Ownership of Windows Update management is being reorganized in the same context. See also “Windows Update Management After WSUS Deprecation.”

flowchart TB
    accTitle: Sorting with Group Policy analytics
    accDescr: Importing GPOs exported as XML from GPMC into Group Policy analytics sorts each setting by whether MDM supports it or whether it is deprecated or unsupported, and supported settings can be migrated into a settings catalog policy
    exp["Export as XML from GPMC"] --> imp["Import into analytics"]
    imp --> ana["Analyze support per setting"]
    ana --> ok["Supported by MDM"]
    ana --> dep["Deprecated or unsupported"]
    ok --> mig["Migrate to a settings catalog policy"]

Figure 18: Group Policy analytics imports exported GPOs and sorts the settings that can be moved to MDM from those that cannot.

8. Pitfalls From a Developer’s Point of View — The Customer’s GPO Changes How Your App Behaves

Finally, here is what to keep in mind from the position of Custom Software Development. The customer’s GPOs quietly rewrite the assumptions your app depends on. Alongside firewalls and antivirus, GPO is a regular suspect behind “it works on the development machine but not at the customer’s.” Here are examples from practice.

The PowerShell Execution Policy

The execution policy can be centrally configured through GPO, and the MachinePolicy and UserPolicy scopes that come from GPO always take precedence over values set locally or per process.¹⁰ If an installer or an operations script is built on the assumption that “adding -ExecutionPolicy Bypass should make it run,” it will not even start under GPO management. For details, see “PowerShell Execution Policy and Script Signing.”

Firewall Local Rule Merging Turned Off

In environments where the firewall is centrally managed by GPO or Intune, local rule merging (AllowLocalPolicyMerge) can be turned off per profile. Where it is off, inbound rules that an installer registered locally exist but are not applied.¹¹ This is a point to check without fail before deploying a server-style app, and it is covered in detail in “The Windows Firewall and Business Applications.”

Drive Mappings, Proxies, and Other Environment Configuration

Network drive mappings, printers, and the like are typically distributed through Group Policy Preferences.¹⁶ Environmental assumptions such as “there should be a Z drive” or “the proxy should be a direct connection” break down depending on which user signs in and which OU the PC belongs to. Another thing that resident apps easily overlook is that settings distributed through User Configuration are, naturally, not applied to the accounts that services and scheduled tasks run as.

The Setting Cannot Be Changed Back in the First Place

Settings that come from administrative templates normally become impossible for the user to change from the UI; the item is grayed out. The fact that “it will be fixed if you have the customer change the setting” does not work has consequences for how you design your response plan.

flowchart TB
    accTitle: The assumptions a customer's GPO changes
    accDescr: A customer's GPOs change an app's assumptions by enforcing the execution policy, turning off firewall local rule merging, distributing drive mappings and proxy settings, and leaving the user unable to change settings back, which is one reason an app fails only at the customer site
    gpo["The customer's GPOs"] --> ep["Execution policy enforced"]
    gpo --> fw["Local rule merging off"]
    gpo --> env["Drive and proxy distribution"]
    gpo --> lock["Settings cannot be changed back"]
    ep --> sym["One reason it fails only at the customer site"]
    fw --> sym
    env --> sym
    lock --> sym

Figure 19: The customer’s GPOs quietly rewrite an app’s assumptions, including the execution policy, the firewall, and environment configuration.

Decide in Advance What Developers Check Before Deployment and During an Incident

There are three preparations to make.

Where to draw the line on privileges is covered in “When Do You Actually Need Administrator Privileges on Windows?” GPO is not your enemy; it is part of the environment’s specification. Treat it as a specification and line up the items to confirm with the administrator, and triage can proceed mechanically.

flowchart TB
    accTitle: The three preparations on the development side
    accDescr: The three preparations on the development side are to document the environmental assumptions the app depends on as deployment requirements and ask the customer's IT staff to confirm them before deployment, to check the gpresult report and the actual values in the Policies keys during trouble, and to separate the processing that needs administrator privileges at design time
    dev["Preparation on the development side"] --> doc["1. Document the environmental assumptions"]
    dev --> chk["2. Confirm with gpresult and actual values"]
    dev --> priv["3. Separate privilege needs in the design"]
    doc -.-> ask["Ask the customer's IT staff before deployment"]

Figure 20: The three preparations on the development side are documenting the environmental assumptions, confirming with gpresult and actual values, and separating administrator privilege needs in the design.

9. Summary

• Group Policy is a mechanism that processes per-GPO settings in the order local, site, domain, OU (LSDOU), and conflicts are decided by last write wins. The GPO on the OU closest to the target is the strongest and the local GPO is the weakest layer.
• Block Inheritance, Enforced, and security filtering let you control the default flow. Enforced beats Block Inheritance as well, so do not overuse it.
• Application comes in two forms: foreground processing at startup and sign-in, and a background refresh at a default interval of roughly 90 minutes plus a random offset. gpupdate /force reapplies every setting, and it has no effect on settings that are only ever processed at sign-in or restart.
• When a setting does not take effect, triage mechanically in the order gpresult /h, then the GroupPolicy operational log, then the registry’s Policies keys. Denied GPOs come with a reason.
• Administrative template definitions live in ADMX and ADML files, and in a domain they are consolidated into the Central Store in SYSVOL. To update, swap out the Central Store side rather than replacing the local PolicyDefinitions.
• Decide between GPO and Intune based on the device’s identity foundation and location, and in a hybrid environment avoid configuring the same setting twice and commit each area to one owner. Group Policy analytics is useful for sorting a migration.
• For developers, the customer’s GPOs are part of the environment specification. Document the assumptions, such as the execution policy, the firewall, and drive and proxy configuration, and build a practice of confirming them with gpresult, and most cases of “it fails only at the customer site” stop being frightening.

Related Articles

• The Windows Firewall and Business Applications — Register Inbound Rules From the Installer
• Windows Update Management After WSUS Deprecation — How to Choose Between WUfB, Autopatch, and Intune
• PowerShell Execution Policy and Script Signing — A Practical Guide to Graduating From “Papering Over It With Bypass”
• Automating PC Provisioning With winget + PowerShell — Making the Runbook Executable
• A Guide to Breaking Free from IE Mode Dependence
• When Do You Actually Need Administrator Privileges on Windows? - UAC, Protected Areas, and How to Tell by Design

Related Consulting Areas

KomuraSoft LLC handles root cause investigation when a business app fails in a customer environment under GPO management, organizing deployment requirements such as the execution policy, the firewall, and network assumptions, and technical consulting on policy inventories and Intune coexistence strategy for IT staff who have inherited an AD environment. Starting from something like “read this gpresult report with me” is perfectly fine.

• Technical Consulting & Design Review
• Bug Investigation & Root Cause Analysis
• Windows Application Development
• Contact

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

I ran gpupdate /force, but the setting still is not applied. Why not?

First, check whether the setting is one of the kinds that a background refresh never applies. User-targeted software installation and folder redirection are processed only at sign-in, and computer-targeted software installation only at startup, so after gpupdate finishes you need a sign-out (/logoff) or a restart (/boot). Next, run gpresult /h to produce an RSoP report and check whether that GPO appears in the list of applied GPOs, and whether it appears in the list of denied GPOs with a reason. If it is applied but the behavior does not change, suspect that another GPO with higher precedence is overwriting the same setting (last write wins). The report shows the winning GPO for each setting, so you can pin down exactly which GPO is winning.

What does "Denied (Filtering)" mean in a gpresult report?

It means the GPO is in scope as far as its link location goes, but filtering excluded it from being applied. The most common cause is security filtering: for a GPO to apply, the user or the computer must hold both the Read and the Apply group policy permissions on that GPO. By default both are granted to Authenticated Users, but if you restrict them to specific groups, a missing group membership or a forgotten computer account results in a denial. For user-targeted GPOs, granting both permissions to the target user is not enough. Since MS16-072, user policy is retrieved under the computer's security context, so Read (Apply is not needed) has to be left in place for Authenticated Users or Domain Computers. Other causes include a WMI filter whose condition does not match, or the user or computer side of the GPO being disabled. The reason for the denial is recorded both in the gpresult report and in the GroupPolicy operational log.

Should I manage devices with GPO or with Intune?

The basic rule is to match the device's identity foundation. If your devices are mainly domain-joined to on-premises AD and are permanently connected to the internal network, GPO is the most reliable and the finest-grained option. If you have a growing number of Microsoft Entra joined devices, or work-from-home machines that never connect to a domain controller, Intune (MDM/CSP), which delivers configuration outside the office as well, is the better fit. In a hybrid environment where both coexist, configuring the same setting through both GPO and MDM creates a conflict with no guaranteed result, so the principle is to decide, setting area by setting area, which one manages it and to commit to that one. When you start considering migration, importing your existing GPOs into Intune's Group Policy analytics lets you sort settings into those already supported by MDM and those that are unsupported or deprecated.

A setting I configured in the Local Group Policy Editor (gpedit.msc) gets overwritten by the domain setting. Is that by design?

Yes, it is by design. Group Policy is processed in the order local, site, domain, OU (LSDOU), and whichever GPO is processed later wins a conflict, which makes the local GPO the weakest layer. If a domain GPO configures the same setting, your local change is always overwritten. Conversely, if the domain side leaves that setting Not Configured, the local GPO's value stands as it is. Even when you really want the local setting to take precedence for testing, there is no way to reverse this precedence order on a domain-joined PC, so the realistic approaches are to create a test OU and adjust the domain-side GPO, or to use a non-domain-joined test machine.

A business app we developed fails only in the customer's environment. Is there a way to check whether GPO is the cause?

The first step is to ask the customer's administrator to run gpresult /h report.html from an elevated command prompt on the affected PC and to review the RSoP report. Look for settings that change how the app behaves: scripts blocked by the execution policy, local firewall rule merging turned off, or configured proxy settings and drive mappings. It also helps to check whether policy values for the relevant product are written under HKLM\Software\Policies and HKCU\Software\Policies in the registry, which mechanically surfaces any enforced settings that come from administrative templates. On the development side, the preparation you can make is to document the assumptions your app depends on, such as the execution policy, inbound ports, and the folders it writes to, in the deployment guide, and to have the customer's IT staff confirm them before deployment.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.