Group Policy Explained: How a Setting Reaches a Machine, and Why It Sometimes Does Not

The objectWhat a GPO actually contains

A Group Policy Object is two collections of settings in one container, and the split matters more than anything else about it.

Computer configuration applies to the machine, at boot, regardless of who signs in afterward. Security settings, service startup, software installation for the machine, firewall rules.

User configuration applies to the account, at sign in, regardless of which machine it signs in to. Drive mappings, desktop settings, folder redirection, application settings.

The half that applies is decided by where the object is linked. A GPO linked to an organizational unit holding computers applies only its computer half, because there are no user accounts underneath it to receive the other one.

This is the single most common reason a policy that looks correct does nothing at all: the settings are in the user half and the link is over a container of computers.

Underneath, a GPO exists in two places at once. The container lives in Active Directory and holds the metadata and the version number. The template lives in the SYSVOL share on every domain controller and holds the actual settings.

Both have to replicate, and the two replicating separately is the cause of a whole class of problems where a policy applies on one site and not on another.

LSDOUThe processing order, and why the last one wins

Policies are applied in a fixed order, and each one overwrites anything the previous ones set for the same setting. The mnemonic is LSDOU.

Local policy on the Windows machine itself, which applies whether or not the machine is in a domain. Set with the local Group Policy editor.

Site policies, linked to an Active Directory site, which is a physical location. Rarely used, and worth checking precisely because nobody remembers they exist.

Domain policies, linked to the domain and applying to everything in it. The Default Domain Policy lives here.

Organizational unit policies, applied from the top OU downward, so the OU containing the object is processed last. Nested OUs each get their turn on the way down.

Because the last one wins, the OU closest to the object beats everything above it. That is the rule to hold, and every override mechanism is a way of breaking it deliberately.

When several GPOs are linked to the same container, they apply in reverse of the link order shown in the management console: the GPO at the top of the list is processed last, and therefore wins.

OverridesThe four ways to break the order

Each of these exists for a reason, and each is a reason a policy is not doing what the order suggests.

Enforced, formerly No Override, on a link. An enforced GPO cannot be overwritten by anything processed after it, which inverts the usual rule. A domain level policy marked enforced beats every OU policy below it.

Block Inheritance, on an OU. Stops policies from above reaching this container at all, except enforced ones, which pass through anyway.

Security filtering. A GPO applies only to users and computers that have both Read and Apply Group Policy permission on it. Restricting a GPO to one security group is done here, and it is the standard way to target specific people rather than a place in the directory.

WMI filtering. A query evaluated on each Windows machine, and the GPO applies only where it returns true. Useful for targeting a specific operating system version or hardware type, and expensive enough that a slow WMI filter shows up as a slow sign in.

The order of evaluation is worth knowing: link order and inheritance decide which GPOs are candidates, then security and WMI filtering decide which of those candidates actually apply.

LoopbackLoopback processing, the one that confuses everybody

The normal rule is that user settings follow the user and computer settings follow the machine. Loopback breaks that on purpose.

With loopback enabled on a computer's GPO, the user half of the policies linked over that computer is applied to whoever signs in, instead of, or in addition to, their own user policies. It exists for shared machines: a kiosk, a terminal server, a conference room PC, where the configuration should follow the machine rather than the person.

It has two modes and the difference matters. Replace discards the user's own user policies entirely and applies only the machine's. Merge applies the user's policies first and then the machine's on top, so the machine wins on conflicts and everything else survives.

Merge is right far more often than replace, and replace is the default choice people reach for. A terminal server configured with replace strips every drive mapping and folder redirection a user normally gets, and the resulting ticket does not mention Group Policy at all.

PreferencesPreferences, which are not policies

The Group Policy Preferences half of the console looks the same and behaves differently, and the distinction is worth being precise about.

A policy setting is enforced. It writes to a protected part of the registry, the user cannot change it, and if the GPO stops applying the setting reverts.

A preference is a default. It writes to the ordinary registry, the user can change it afterward, and if the GPO stops applying the value stays where it was. Preferences also have item level targeting, which is a per item condition, so one GPO can map a drive for the finance group and a different one for everybody else.

Use preferences for things a user may legitimately change, such as a printer or a shortcut. Use policies for anything that has to stay set. The failure mode of getting this backward is a security setting a user can quietly turn off, and it does not appear in any report as a problem.

One historical note that still bites: preferences could once store a password for a scheduled task or a local account, and that password was recoverable by anyone who could read SYSVOL. Microsoft removed the capability, and old GPOs created before the change may still carry one. It is worth searching SYSVOL for cpassword once, and deleting whatever turns up.

The toolsThe consoles, and which one to open

Three tools, and reaching for the wrong one is why a change made carefully has no effect anywhere except the machine it was made on.

Group Policy Management Console, gpmc.msc. The domain wide tool. This is where GPOs are created, linked to organizational units, ordered, enforced, filtered and backed up. It runs on a domain controller or on any Windows machine with the remote administration tools installed. Everything in this article that involves a domain happens here.

Group Policy Editor, gpedit.msc. The local editor. It edits the policy of the machine you are sitting at and nothing else. It is genuinely useful on a standalone machine and for testing a setting before writing it into a domain GPO.

It is also the trap: a setting made here on one machine applies to that machine, is overwritten by any domain policy touching the same value, and does not appear in any central report.

PowerShell, the GroupPolicy module. Get-GPO -All lists every object, Get-GPOReport produces the same HTML report the console does, Backup-GPO and Restore-GPO handle the backups that should be running on a schedule. Anything you would do to a hundred GPOs belongs here rather than in the console.

The practical rule: if a machine is domain joined, open the management console. Use the local editor only for a standalone machine, or deliberately, knowing a domain policy will win over whatever you set.

DiagnosisWhy it did not apply, in diagnostic order

The order below finds the cause faster than reading the GPO, because the settings are almost never the problem.

Run gpresult /h report.html on the machine, as the affected user. This is the whole diagnosis most of the time. It lists every GPO applied, every GPO filtered out, and the specific reason each one was filtered. Read the denied list first.

The second row is the one to reach for first. The report it writes names every GPO that was denied and why, and that answer is faster to read than any amount of clicking through the console.

Check which half the setting is in. A user setting in a GPO linked over computers does nothing. This is the most common cause and the easiest to see once you look.

Check security filtering. Since a change Microsoft made in 2016, the computer account needs Read access to the GPO as well, and a GPO filtered to a user group without Authenticated Users retaining Read will silently stop applying.

Check for Enforced and Block Inheritance above the object. Either one changes the outcome and neither is visible from the setting itself.

Force a refresh and watch the event log. gpupdate /force on the machine, then read the Group Policy operational log. Some settings, folder redirection and software installation among them, only apply at sign in or boot, so a refresh alone will not show them.

Check Active Directory replication if it works in one site and not another. SYSVOL and the directory replicate separately, and GPOs whose version numbers disagree between domain controllers apply inconsistently depending on which controller a machine talked to.

PitfallsWhere people go wrong

Editing the Default Domain Policy. It applies to everything and it is where the account and password settings live. Put new settings in a new GPO linked where they are needed, and leave the default alone so a problem is always attributable.

Creating a GPO per setting. Two hundred GPOs with one setting each is slower to process, harder to reason about and impossible to hand over. Group settings by purpose and by which OUs they apply to.

Using Block Inheritance to solve a problem. It works and it hides the cause. The next person will not know why an OU behaves differently, and enforced policies pass through it anyway, so it is not even reliable.

Forgetting that some settings need a reboot. Software installation, folder redirection and drive mappings under some configurations apply at boot or sign in only. A refresh that reports success and changes nothing is usually this.

Leaving disabled halves enabled. A GPO with no user settings should have its user half disabled in the properties. It removes a lookup from every sign in, and across a large estate that is measurable.

Not backing them up. GPOs are the configuration of the entire Windows estate and they live in two replicated places. Back them up with Backup-GPO in PowerShell, on a schedule, to somewhere that is not a domain controller.

ComparisonA policy setting, a preference and a startup script, on what each one is for

The second row is the one that decides most cases. A setting that must not survive the policy being removed is a policy. Anything else is probably a preference.

FAQFrequently asked questions

Keep readingRelated concepts

Read next · Identity and access What Is MFA? Authentication policy is one of the things a GPO sets, and one of the things it cannot set for cloud accounts. Open this next16 min

• Directory and identity · 15 min Active Directory Explained Group Policy is applied through the directory, and the organizational unit structure is what decides who gets what.
• Firmware and boot · 15 min How to Enable Secure Boot, and What to Check Before You Do Firmware settings are one of the few things Group Policy cannot reach, which is why they are done per machine.
• Windows administration · 10 min How to Stop Windows Update Without Leaving Your PCs Unpatched The Windows Update policies that pause, defer or disable updates, and which ones to avoid.
• Tools · 11 min Free Active Directory Tools, Starting With the Ones Already Installed Where the console it lives in comes from, at no cost.
• Endpoint management · 13 min MDM Explained What manages the devices that never touch a domain controller.
• Windows administration · 11 min The DISM Command, and What Each Repair Switch Actually Does The repair command that fails when a policy points it at the wrong source.
• Operations · 13 min Patch Management, and Why the Hard Part Is Not the Patching Where the reboot rules that make staged patches take effect are written.
• Windows administration · 10 min MSI vs EXE, for the Person Who Has to Deploy the Software MSI and EXE installers compared, and why only one of them deploys without extra work.
• Operations · 8 min PowerShell vs Bash, and Why the Platform Decides for You The two shells an administrator scripts in, and what the platform decides for you.