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

“This setting is distributed via GPO,” “the customer’s PCs are locked down by Group Policy” — anyone who works with Windows business systems hears the word “GPO” thrown around constantly. Yet when it actually comes to taking over AD administration duties, or deploying an app to a domain-joined PC at a customer site, surprisingly few people can accurately explain when, from where, and in what order of precedence Group Policy is applied.

“I changed the setting, but it hasn’t taken effect,” “I was told to run gpupdate but don’t know what it’s actually doing,” “the app works on my dev machine but not at the customer’s, and it turned out to be GPO” — this article is aimed at business-app developers who run into these situations, and at IT staff at small and midsize businesses who have inherited AD administration. It sets out how Group Policy works (the LSDOU order of application), when it takes effect, how to diagnose it with gpresult and the event log, ADMX and the central store, and how to choose between GPO and Intune (MDM), all based on primary sources as of August 2026.

1. The Bottom Line First

• Group Policy is “last write wins”. It is processed in the order local → site → domain → OU (LSDOU), and whichever GPO is processed later takes precedence in a conflict. The local GPO (gpedit.msc) is the weakest layer.¹
• Application timing is “foreground plus background”. Computer Configuration is always applied at startup and User Configuration always at sign-in; on top of that, by default there is a background refresh roughly every 90 minutes plus a random offset of 0-30 minutes (5 minutes on domain controllers).²
• gpupdate /force “reapplies every setting” — it is not a cure-all. Some settings, such as software installation and folder redirection, are only ever processed at sign-in or restart (which is exactly why the /logoff and /boot options exist).³
• The starting point for diagnosis is the RSoP report from gpresult /h. It shows both the applied GPOs and the denied GPOs, with reasons. For deeper digging, use the GroupPolicy operational log (Microsoft-Windows-GroupPolicy/Operational).⁴⁵
• As a rule, administrative template policies are written to the registry’s dedicated policy keys (Software\Policies and so on). The policy value takes precedence over the app’s own setting, and “Not Configured” writes nothing at all. That said, a few policies do write outside the dedicated keys (Section 5).⁶
• The ADMX central store is the PolicyDefinitions folder in SYSVOL. Once you create it, GPMC starts referencing the domain-wide template definitions from there.⁷
• Choose GPO or Intune based on the device’s identity foundation. Configuring the same setting in both gives no guaranteed outcome. Group Policy analytics can help when you are considering migration.⁸⁹
• For developers, GPO is a classic reason an app “only fails to work at the customer’s site”. Settings that change your app’s assumptions — the execution policy, disabled firewall local-rule merging, proxy and drive configuration, and more — are distributed through centralized management.¹⁰¹¹

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

Group Policy is a mechanism that lets an administrator centrally define Windows settings and enforce them on target computers and users. A bundle of settings is called a GPO (Group Policy Object). A GPO can live in one of two places.

A workgroup (non-domain-joined) PC processes only the local GPO.¹ So in practice, when people say a machine is “managed by GPO,” they almost always mean a domain GPO.

Whatever the GPO, its contents fall broadly into two categories.

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

This axis — “is the setting tied to the PC or to the person” — comes up consistently in both the order of application and how you confirm it took effect, later in this article. Some items exist under both configurations, so make it a habit to always check both branches when you’re hunting for a setting.

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. 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 top-level OU downward, with the GPO on the OU that the target computer/user directly belongs to processed last

Taking the initial letters gives the order its name, LSDOU. The key point is that this is not “highest priority first” but the order in which GPOs are processed. When multiple GPOs configure the same setting, whichever is processed later wins (settings that don’t conflict are simply added together).¹ In other words, 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 not a malfunction — it is this specification working exactly as designed.

When multiple GPOs are linked to the same site, domain, or OU, precedence among them is decided by the link order on GPMC’s “Linked Group Policy Objects” tab. The GPO with the lowest link-order number is processed last and takes highest priority.¹

3.2. Block Inheritance and Enforced

You can create exceptions to the default order.¹

• Block Inheritance: set on a domain or OU, this stops GPOs from further up from being inherited. It’s the tool for “this one OU should not receive the company-wide standard.”
• Enforced (formerly called No Override): set on a GPO’s link, this makes that GPO always apply, even if a level below has Block Inheritance set, and it can no longer be overwritten by a lower GPO. When Block Inheritance and Enforced conflict, Enforced wins.¹

Enforced is a mechanism that breaks the “last write wins” principle, so overusing it means more and more results in your RSoP reading will feel counterintuitive. The standard practice is to reserve it for security settings the whole company absolutely must observe.

3.3. Security Filtering

Beyond the link location, you can also narrow who a GPO applies to, per GPO. For a GPO to be applied, the target user or computer must hold both the “Read” and “Apply group policy” permissions on that GPO. By default both are granted to Authenticated Users (which includes both users and computers), so the GPO applies to everyone under the link target. Security filtering is how you narrow this down to specific security groups. The filter acts on the GPO as a whole; you cannot vary it per setting within the GPO.¹³

There is one important caveat. When narrowing the scope, do not also strip “Read” from the default Authenticated Users. Since security update MS16-072 (2016), user policy is retrieved under the computer’s security context, so if the computer account cannot read the GPO, the user-targeted GPO will not apply even if the target user has both permissions.¹⁴ The correct way to narrow scope is to grant “Read + Apply group policy” to the target group while leaving just “Read” on Authenticated Users (or Domain Computers).¹⁴

In practice, the two classic stumbling blocks are “I added it to the group but it still isn’t applied (it’s a computer-targeted setting, but I only added the user to the group)” and “I removed it from the group but it keeps applying.” The latter will not clear up even if you wait for a background refresh. Group membership is evaluated from the security token created at sign-in, so a user’s group change only reaches the filter after a sign-out/sign-in cycle, and a computer’s group change only after a restart — once a fresh token has been issued.

There is also a special mode called loopback processing, for situations such as shared PCs or Remote Desktop servers, where you want whoever signs in to that PC to get a replaced User Configuration (a mechanism that applies user settings based on the computer’s location, with Replace and Merge modes).¹⁵ It’s an advanced feature used on kiosk machines and classroom PCs, so this article will simply note that it exists.

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

Half of “I configured it but it hasn’t taken effect” is simply that the application timing hasn’t arrived yet. There are two kinds of application.²

In other words, for a running device that can reach a domain controller, settings that support background refresh will roll out within roughly two hours after you change the GPO, with no further action needed. Offline devices, or laptops taken off-site without a VPN connection, won’t get it until they next reach a DC. Settings that are only applied through foreground processing will additionally have to wait for a startup or sign-in. If you’re in a hurry, run gpupdate on the target PC. By default only settings that changed are applied; adding /force reapplies every setting, regardless of whether it changed.³

rem Update only changed settings (usually sufficient)
gpupdate

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

The thing to watch for is that some settings simply don’t take effect through gpupdate. User-targeted software installation and folder redirection are only processed at sign-in, and computer-targeted software installation only at startup. gpupdate provides the /logoff (sign out after the update) and /boot (restart after the update) options for exactly this.³ Before you complain that “I ran gpupdate /force and it still didn’t take,” check whether the setting is one of the kinds that requires a restart or a sign-in.

5. Diagnosing a Setting That Won’t Apply — gpresult, the Event Log, and the Registry

5.1. Checking RSoP with gpresult /h

gpresult is the standard tool for checking the final outcome (RSoP: Resultant Set of Policy) once multiple GPOs have layered on top of each other. Producing an HTML report from an elevated command prompt is the most readable approach.⁴⁵

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

rem To check just a summary in the console
gpresult /r
gpresult /scope computer /r

The first three things to check in the report are:

1. The list of applied GPOs — is the GPO you’re after present?
2. The list of denied GPOs, with reasons — reasons for non-application, such as security filtering, a WMI filter, or an empty GPO, are shown here⁵
3. The “Winning GPO” for each setting — which GPO’s value decided the setting you’re after. If a different GPO is winning, go back and reconsider the precedence rules in Section 3

5.2. The GroupPolicy Operational Log

When gpresult isn’t enough — say, processing is outright failing, or it’s taking far too long — look at the GroupPolicy operational log in Event Viewer. It’s at “Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational” (log name Microsoft-Windows-GroupPolicy/Operational). This records the whole span of policy processing, start to finish, together with the list of applied GPOs and the list of denied GPOs (with reasons). Each round of policy processing is assigned a unique ActivityID, so Microsoft’s recommended procedure is to pick up the ActivityID from a warning or error event in the System log, and then use a custom view to filter down to just that one instance.⁵

5.3. The Relationship to the Registry’s Policies Key

Administrative template policies (next chapter) ultimately get written as registry values. As a rule, they’re 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 / HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

There is an important design principle at work here. A policy-aware app behaves by first reading the Policies key; if a value is present there it takes priority; if not, the app falls back to its own setting (preference) or default. A “Not Configured” policy writes nothing to the registry at all.⁶ In other words, administrative template policies don’t rewrite the app’s own setting and leave a “tattoo” behind — instead, an enforced value kept in a separate location is consulted with priority. Stop configuring the policy, and the app reverts to obeying its own setting value.

That said, not every policy writes to a dedicated key. Some built-in OS settings (for example, “Enable Win32 long paths” writes to LongPathsEnabled under HKLM\SYSTEM\CurrentControlSet\Control\FileSystem), along with older-generation or third-party templates, write to arbitrary paths outside the dedicated keys. For settings like this, the value stays put even after you stop configuring the policy. Check the ADMX definition, the setting’s description text, or the gpresult report to see which key a given setting actually writes to.

Put another way, the well-behaved design described above only holds within the boundary of administrative templates (the dedicated policy keys). Values that scripts or Group Policy Preferences write outside the Policies key behave like ordinary registry values, and this framework provides no mechanism to automatically revert them once you stop distributing them. In practice, when diagnosing an issue, the quickest and most reliable approach is to look directly at whether the setting you’re after is written under the Policies key.

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

6. Administrative Templates (ADMX) and the Central Store

The definitions behind the settings listed under GPMC’s “Administrative Templates” are written as ADMX files (the definition body) plus ADML files (the display strings for each language). Every PC has the OS-supplied definitions under C:\Windows\PolicyDefinitions, and the management tools load these to build the settings screen.⁷

If you’re operating within a domain, the basic move is to create a central store. Create a PolicyDefinitions folder under the SYSVOL of a domain controller (for example, \\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions), and its contents are replicated to every domain controller in the domain; Group Policy tools then reference the central store by default.⁷ This eliminates the problem where “the template version differs from one management workstation to the next, and the visible settings don’t match up.” ADML files go into language-specific subfolders (ja-JP for Japanese).⁷

There are two operational cautions. First, Microsoft distributes new ADMX files for each new Windows version, and when you update, you swap out the central store side. Replacing C:\Windows\PolicyDefinitions on each individual PC with the downloaded version is not supported.⁷ Second, when updating an existing central store, the guidance is not to overwrite the production PolicyDefinitions directly. Instead, assemble the full ADMX set — both for the OS and for apps such as Office and Edge — in a version-named working folder like PolicyDefinitions-24H2, rename the current folder aside to something like PolicyDefinitions-23H2, and then rename the working folder to PolicyDefinitions to promote it to production.⁷ Group Policy tools only reference the folder literally named PolicyDefinitions, so simply placing files in a version-named folder has no effect. The advantage of this approach is that if a problem arises, you can roll back to the folder you set aside.⁷

7. GPO vs Intune (MDM/CSP) vs Manual/Scripted Deployment — A Decision Table

GPO is no longer the only option for managing Windows device configuration. MDM, epitomized by Intune, configures OS settings through a mechanism called CSP (Configuration Service Provider). Here is a decision table for which one to build your approach around.

The deciding axis is simple: the device’s identity foundation (AD, or Microsoft Entra) and where the device is located. GPO is most reliable for a fleet of desk-bound office PCs fully joined to on-prem AD; GPO simply doesn’t reach Entra-joined mobile PCs at all.

In reality, most small and midsize businesses sit in between, in a hybrid setup (domain-joined plus Intune-enrolled), and the worst thing you can do here is “configure the same setting through both GPO and MDM.” Policy CSP has a policy called MDMWinsOverGP that lets MDM win when GPO and MDM conflict, but its scope is limited to the corresponding policies within Policy CSP. Microsoft itself is explicit that configuring a setting outside that control through both GPO and MDM produces a race condition with no guarantee of which one wins, and that double-configuration should be avoided.⁸ The first principle of hybrid operation is to decide, setting area by setting area, “this one’s GPO, this one’s Intune,” and commit to a single management authority.

Once you’re at the stage of considering a migration from GPO to Intune, Intune’s Group Policy analytics is the entry point. Import GPOs exported from GPMC (XML), and it will analyze whether each setting is supported by MDM, or unsupported/deprecated; settings that are supported can be migrated into an Intune settings catalog policy.⁹ It’s more accurate to think of this as a tool for “sorting what can be moved, what can’t, and what to discard” than for “moving everything.” The management authority for Windows Update is being reorganized along the same lines, too — see also “Managing Windows Update After WSUS Deprecation.”

8. A Developer’s Blind Spot — How the Customer’s GPO Changes Your App’s Behaviour

Lastly, something worth knowing if you do contract development. The customer’s GPO quietly rewrites your app’s assumptions. Alongside firewalls and antivirus software, GPO is a regular offender behind “it works on my dev machine but not at the customer’s site.” Here are some concrete examples.

• PowerShell’s execution policy: the execution policy can be configured centrally through GPO, and the GPO-derived MachinePolicy/UserPolicy scopes always take priority over a value set locally or on the process.¹⁰ If an installer or operational script is built on the assumption that “adding -ExecutionPolicy Bypass will make it work,” it won’t even launch under GPO management. See “PowerShell Execution Policy and Script Signing — A Practical Guide to Graduating From "Papering Over It With Bypass"” for details.
• Disabled local rule merging on the firewall: in environments where the firewall is centrally managed through GPO/Intune, “local rule merging” (AllowLocalPolicyMerge) can be disabled per profile. Where it’s disabled, an inbound rule an installer registered locally exists but is not applied.¹¹ This is a point you must confirm before deploying a server-type app; it’s covered in detail in “Windows Firewall and Business Apps.”
• Environment configuration such as drive mappings and proxies: mapping network drives, printers, and the like is commonly distributed through Group Policy Preferences.¹⁶ Assumptions about the environment — “the Z drive should exist,” “the proxy should be a direct connection” — can be undone depending on the signed-in user or the PC’s OU membership. It’s also easy to overlook, for a resident-type app, that settings distributed through User Configuration naturally don’t apply to the account a service or scheduled task runs under.
• The setting simply “can’t be changed back”: settings that come from administrative templates typically can’t be changed by the user through the UI at all (the item is greyed out). The fact that “just have the customer change the setting” doesn’t work has real implications for how you design your support approach.

There are three realistic precautions on the development side. First, document as a deployment requirement the environmental assumptions your app depends on — execution policy, listening ports, where it writes, proxy path, and so on — and have the customer’s IT staff confirm them before deployment. Second, when trouble arises, check the actual gpresult /h report and the real values under HKLM\Software\Policies, rather than guessing (Section 5). Third, separate at the design stage which operations need administrator privileges and which don’t (this line is drawn in “When Do You Actually Need Administrator Privileges on Windows? - UAC, Protected Areas, and How to Tell by Design”). GPO isn’t the enemy — it’s a specification of the environment. Treat it as a specification, and diagnosis becomes mechanical.

9. Summary

• Group Policy is a mechanism that processes GPO-level settings in the order local → site → domain → OU (LSDOU), and conflicts are resolved on a last-write-wins basis. The GPO on the OU closest to the target is the strongest layer, and the local GPO is the weakest.
• Block Inheritance, Enforced, and security filtering let you control the default flow. Enforced beats Block Inheritance too, so it should not be overused.
• Application happens through two channels: foreground processing at startup/sign-in, and a background refresh roughly every 90 minutes plus a random offset by default. gpupdate /force reapplies every setting, but it has no effect on settings that are only ever processed at sign-in or restart.
• When a setting won’t apply, diagnose it mechanically in the order gpresult /h → the GroupPolicy operational log → the registry’s Policies key. Denied GPOs are shown with a reason.
• Administrative template definitions are ADMX/ADML, and domain operation should consolidate them in the SYSVOL central store. When updating, swap out the central store side rather than replacing the local PolicyDefinitions folder.
• Whether to use GPO or Intune is decided by the device’s identity foundation and location; in a hybrid setup, avoid double-configuring the same setting and keep management authority on one side. Group Policy analytics can help with sorting a migration.
• For developers, a customer’s GPO is part of the environment’s specification. Document the assumptions around execution policy, firewall, drive mappings, and proxy configuration, and build a habit of confirming them with gpresult — and most cases of “it only fails at the customer’s 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 investigating why a business app won’t run in a customer environment under GPO management, organizing deployment requirements (execution policy, firewall, network assumptions), and technical consulting on policy inventories and Intune co-management plans for IT staff who have inherited an AD environment. It’s fine to start from a stage as early as “come read a gpresult report with us.”

• Technical Consulting and Design Review
• Bug Investigation and Root Cause Analysis
• Windows App Development
• Contact Us

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 isn't applied. Why not?

First check whether the setting is one of the kinds that a background update never applies. User-targeted software installation and folder redirection are only processed 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 among the 'Applied GPOs', or whether it appears among the 'Denied GPOs' with a reason. If it is applied but the behaviour hasn't changed, suspect that a different 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 has excluded it from actually being applied. The most common cause is security filtering: for a GPO to apply, the user or computer must hold both the 'Read' and 'Apply group policy' permissions on that GPO. By default both are granted to Authenticated Users, but if you have restricted this to specific groups, a missed group membership — forgetting to add the group, or forgetting to add the computer account — will cause a denial. For user-targeted GPOs, granting both permissions to the target user alone is not enough. Since MS16-072, user policy is retrieved under the computer's security context, so 'Read' (not 'Apply') needs to be left in place for Authenticated Users or Domain Computers. Other causes include a WMI filter that doesn't match, or the user/computer configuration being disabled on the GPO itself. The reason for denial is recorded both in the gpresult report and in the GroupPolicy operational log.

Should I manage a device 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 permanently connected to the internal network, GPO is the most reliable and finest-grained option. If you have more Microsoft Entra-joined devices, or work-from-home machines that never touch a domain controller, Intune (MDM/CSP), which can deliver configuration outside the office too, is the better fit. In a hybrid environment where both coexist, configuring the same setting through both GPO and MDM causes a conflict with no guaranteed winner, so the principle is to decide, setting area by setting area, which one manages it, and commit to that one. Once you are 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 through the local Group Policy editor (gpedit.msc) keeps getting overwritten by the domain setting. Is that expected?

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

The business app we developed just won't run 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 review the RSoP report. Look for settings that would change your app's behaviour: scripts blocked by the execution policy, local firewall rule merging disabled, or configured proxy and drive mappings. It also helps to check whether policy values for the relevant product have been written under HKLM\Software\Policies and HKCU\Software\Policies in the registry, which lets you mechanically flag any enforced settings coming from administrative templates. On the development side, the practical preparation is to document the assumptions your app depends on — execution policy, listening ports, the folder it writes to, and so on — as a deployment requirement, and 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.