Group Policy in Practice
If Active Directory is how a Windows organization models who people are, Group Policy is how it controls what their machines do. It is the configuration-management system that predates Ansible, Puppet, and the entire “infrastructure as code” movement by years, and it is still the thing keeping the lights on in the overwhelming majority of Windows estates. For a Linux admin, the closest mental hook is a configuration-management tool — but one that is pull-based, runs on a schedule you mostly cannot see, targets an LDAP directory tree instead of an inventory file, and has been accreting since 2000. Understanding it is less about learning a tool and more about understanding a processing model and the sprawl that model produces over two decades.
This post assumes you have read the Active Directory fundamentals piece, because Group Policy targets the OUs, sites, and domains described there. If “OU” and “domain controller” are not yet solid, start there.
What a GPO actually is
A Group Policy Object (GPO) is a named bundle of settings. Physically it is two halves that AD keeps loosely coordinated: a Group Policy Container (the object in the directory, holding metadata and version numbers) and a Group Policy Template (the actual settings files, living in the SYSVOL share that every DC replicates). When you edit a GPO you are editing files in SYSVOL; when a client applies one it reads those files over SMB after finding a DC via — yes — DNS.
A GPO by itself does nothing. It has to be linked to a scope of management: a site, a domain, or an OU. The link is what activates the policy for the objects in that container. One GPO can be linked in several places; one container can have many GPOs linked to it. This many-to-many relationship between policies and targets is the source of both Group Policy’s power and its confusion — the same setting can be coming from any of several linked GPOs, and working out which one won is a regular diagnostic exercise.
Inside a GPO, settings split into two completely independent halves, and conflating them is the most common beginner mistake.
GPO
├── Computer Configuration → applies to the MACHINE
│ - applied at boot, then refreshed periodically
│ - targets the computer object's location in AD
│ - e.g. firewall rules, services, security baselines
│
└── User Configuration → applies to the USER
- applied at logon, then refreshed periodically
- targets the user object's location in AD
- e.g. mapped drives, desktop settings, login scripts
The crucial implication: computer settings follow the computer object’s OU, user settings follow the user object’s OU. If your users live in OU=Staff and your laptops live in OU=Workstations, a GPO’s computer settings only take effect based on where the laptop sits, and its user settings only based on where the user sits — regardless of who logs into what. People burn hours because they linked a GPO to the user OU and wondered why a computer-side firewall setting never applied. Two halves, two independent targeting paths.
LSDOU: the processing order that explains everything
Multiple GPOs apply to almost every object, and they can set the same thing to different values. Group Policy resolves this with a fixed processing order, and “last writer wins.” The order is LSDOU:
apply in this order, each overriding the previous:
L → Local (the machine's own local policy)
S → Site (GPOs linked to the AD site)
D → Domain (GPOs linked to the domain)
O → OU (GPOs linked to OUs, parent OU before child OU)
later = higher precedence ⇒ the OU closest to the
object wins on conflicts
Local policy first, then site, then domain, then OUs from the top of the tree down to the one the object sits in. Because later application overwrites earlier on any conflicting setting, the most specific link — the OU closest to the object — wins. This is the single most important thing to internalize: a setting in a GPO linked to the object’s own OU beats the same setting in a domain-wide GPO, because the OU is processed later.
Within a single container that has several linked GPOs, link order breaks the tie — the GPO with link order 1 has the highest precedence (counterintuitively, lower number wins, because they are applied in reverse so number 1 is applied last). The Group Policy Management Console shows you the effective precedence directly, which is how you should reason about it rather than re-deriving the order in your head.
Two overrides bend LSDOU, and you will meet both:
- Enforced (formerly “No Override”): mark a link as Enforced and its settings win regardless of LSDOU — they cannot be overridden by a more specific GPO downstream. This inverts the normal “specific wins” rule and is how a security team pins a non-negotiable setting domain-wide that no OU admin can countermand.
- Block Inheritance: mark an OU to block inheritance and it stops processing GPOs from above (site/domain/parent OUs). Except — Enforced links pierce Block Inheritance. The interaction of Enforced and Block Inheritance is where Group Policy precedence stops being intuitive and you genuinely need the GPMC’s “Group Policy Inheritance” tab to tell you the truth.
The honest takeaway: do not try to hold the full precedence calculation in your head for a mature domain with Enforced links, blocked OUs, and dozens of GPOs. Use the tooling (gpresult, the Resultant Set of Policy, below) to ask the machine what actually won, and reserve your mental model for designing simple, predictable layouts in the first place.
When policy applies, and the foreground/background distinction
Computer policy applies at boot; user policy applies at logon. After that, both refresh in the background roughly every 90 minutes (with a random offset up to 30 minutes so DCs are not hammered simultaneously) plus on certain events. You can force it:
|
|
The wrinkle that catches people: some settings — software installation, folder redirection, drive maps in certain modes — only apply in the foreground (at actual boot/logon), not in a background refresh, because they cannot safely change while the user is working. So you push a new GPO, run gpupdate /force, and the setting does not take — not because the GPO is wrong, but because it needs a real logon to apply. When a setting refuses to take via gpupdate, a full reboot-and-logon is the next diagnostic step, not a sign the policy is broken.
ADMX, administrative templates, and the registry
A huge fraction of Group Policy is, under the hood, just writing registry values. The “Administrative Templates” section of a GPO is a friendly front-end over registry keys, defined by ADMX files (XML templates that describe which registry value a setting maps to, its possible values, and its human-readable description). Microsoft ships thousands of these for Windows and Office; vendors ship their own (Google publishes ADMX for Chrome, Mozilla for Firefox) so you can manage third-party apps through the same machinery.
The modern best practice is the ADMX Central Store: a folder in SYSVOL (\\domain\SYSVOL\domain\Policies\PolicyDefinitions) holding one authoritative copy of every ADMX file, replicated to all DCs. Without it, the templates come from whatever was installed on the admin’s local machine, and two admins on different Windows versions see different available settings — a classic “works on my workstation” failure. Setting up the Central Store early is one of those small disciplines that prevents a lot of later confusion.
The registry connection matters for the Linux admin’s intuition: Group Policy’s Administrative Templates are essentially a centrally-managed, OU-targeted way of pushing registry state to machines — a declarative config layer over a key-value store. The non-template parts (security settings, software installation, scripts, preferences) are more bespoke, but “it’s mostly managed registry” gets you a long way toward understanding what an Administrative Template GPO is doing.
Security baselines: the highest-value use
The single most valuable thing Group Policy does is enforce a security baseline across every machine. Microsoft publishes the Security Compliance Toolkit with hardened baseline GPOs for each Windows and Server version — hundreds of vetted settings (password policy, account lockout, audit logging, SMB hardening, disabling legacy protocols, User Rights Assignment) you can import and link rather than hand-deriving. The account and password policy for the domain is itself a GPO setting (historically, exactly one domain-wide policy governed passwords, though Fine-Grained Password Policies later allowed per-group exceptions).
This is where the comparison to Ansible/Puppet is most apt and most favorable to Group Policy: it is continuously enforced. The background refresh means a setting a user changed locally gets reverted at the next cycle, automatically, without an admin running anything. That convergence-on-a-schedule behavior — drift correction built into the platform — is genuinely good, and it is why security teams lean on Group Policy hard even as other config management moves elsewhere.
Loopback processing: the one that confuses everyone
A specific problem: you have a shared machine — a kiosk, a conference-room PC, a Remote Desktop server — and you want user settings to depend on the machine, not on who logged in. Normally user policy follows the user’s OU, so a developer logging into the kiosk would drag their personal user policy along. Loopback processing flips this: enable it on the machine’s GPO and the user-configuration settings are taken from GPOs linked to the computer’s OU instead of (Replace mode) or in addition to (Merge mode) the user’s own.
Loopback is the canonical “advanced Group Policy” topic because it breaks the clean “user settings follow the user” rule that you just spent effort learning. It is the right tool for locked-down shared machines and a frequent source of “why is this user getting these settings here but not on their laptop” head-scratching. If a user’s policy seems to change based on which machine they are on, suspect loopback.
Preferences: drive maps, scripts, and the rest
Beyond the registry-backed Administrative Templates and the security settings, Group Policy Preferences (GPP) handle the everyday IT plumbing: mapped network drives, printer connections, scheduled tasks, shortcuts, environment variables, even local file copies. These are the things that make a corporate Windows logon “just work” — the H: drive that is always there, the departmental printer that appears.
Preferences support item-level targeting — apply this drive map only if the user is in a certain group, only on a certain OS, only on machines in a certain IP range — which is powerful and another layer of “why did this apply here but not there.” Login scripts (PowerShell or batch, run at logon) are the older mechanism for the same kinds of tasks; modern practice favors Preferences over scripts where possible because they are declarative and visible in the GPMC rather than buried in a script’s logic.
One important historical security note: old-style Group Policy Preferences could store passwords (for drive maps, scheduled tasks) in SYSVOL, encrypted with a key Microsoft published. This was catastrophic — any authenticated user could read and decrypt them (MS14-025). Microsoft removed the ability to set new ones, but legacy cpassword values still lurk in old SYSVOLs and are a standard thing attackers and auditors grep for. If you inherit an old domain, search SYSVOL for cpassword.
WMI filtering
Sometimes OU-based targeting is not granular enough — you want a GPO to apply only to laptops, or only to a specific OS build, or only to machines with a certain amount of RAM. WMI filters attach a WMI query to a GPO link; the GPO applies only to machines where the query returns true:
|
|
WMI filtering is flexible and slow — every targeted machine evaluates the query on every policy refresh, which adds logon/boot latency. Use it sparingly; where you can express the targeting with OU structure or Preferences item-level targeting instead, prefer those. Heavy WMI filtering is a recognizable cause of sluggish logons.
Troubleshooting: gpresult and RSoP
When the inevitable “why did/didn’t this setting apply” question arrives, two tools answer it, and they answer it authoritatively by asking the machine what actually happened rather than reasoning about what should have.
|
|
gpresult /h produces the Resultant Set of Policy (RSoP): a readable report of every GPO that applied, every setting that won, which GPO it came from, and — critically — every GPO that was filtered out and why (denied by permissions, blocked by a WMI filter, scope mismatch). When a setting you expected is missing, the report’s “Denied GPOs” section usually names the reason directly. This is the Group Policy equivalent of reading the actual config a host converged to rather than guessing from the playbook, and it is where troubleshooting should always start. The GPMC also has a “Group Policy Modeling” wizard that predicts RSoP for a hypothetical user-in-OU-on-machine combination — useful for testing a design before you deploy it.
The companion diagnostic for security filtering and delegation questions: every GPO has an ACL, and a GPO only applies to principals with both “Read” and “Apply Group Policy” rights. Security filtering — restricting a GPO to apply only to members of a specific group by editing that ACL — is a common and clean targeting technique, and a common reason a GPO mysteriously does not apply to someone (they are not in the filtered group). The RSoP report surfaces this too.
The good, the bad, and the sprawl
The good. Group Policy is mature, free (it comes with AD), continuously enforced, granular to an almost absurd degree, and agentless — every domain-joined Windows machine is a Group Policy client out of the box with nothing to install. For pushing security baselines and standard configuration to a fleet of domain-joined Windows machines, nothing else is as turnkey. The drift-correction-on-a-schedule model is genuinely ahead of where a lot of “modern” tooling lands.
The bad and the sprawl. Two decades of accretion is Group Policy’s defining problem. A mature domain has hundreds of GPOs, many linked in overlapping scopes, some Enforced, some blocked, a few that no one remembers the purpose of and nobody will dare delete. Precedence becomes genuinely hard to reason about by hand. It is online-only — Group Policy assumes a machine that regularly talks to a DC on the corporate network, which fits the badge-in-at-the-office world and fits the remote/laptop/work-from-anywhere world poorly. It is Windows-only and AD-bound. And it has weak native change tracking — without add-on tooling, “who changed this GPO and why” is hard to answer, which is exactly the wrong property for a system that controls security settings fleet-wide.
Where it overlaps with Intune and modern MDM
This is the strategic context every Windows shop is now navigating, and it is worth understanding even from the Linux side. Microsoft Intune (cloud MDM, part of Microsoft’s Entra/365 stack) is the cloud-native successor to Group Policy. Instead of domain-joined machines pulling policy from a DC over the LAN, Intune-enrolled machines pull policy from the cloud over the internet — which fixes Group Policy’s biggest structural weakness, the assumption of constant corporate-network presence. For a fleet of laptops that may never touch the office LAN, Intune’s model simply fits reality better.
The honest state of things in 2026 is hybrid and messy. Most enterprises run both: Group Policy for the on-premises domain-joined estate (servers especially, which are not going to cloud-MDM enrollment any time soon), Intune for laptops and the cloud-managed fleet, with a lot of organizations mid-migration and maintaining overlapping policy in two systems. Intune does not yet cover every setting Group Policy can reach (though “settings catalog” and ADMX-backed policies have closed much of the gap), and the migration is a multi-year slog for any large estate. The take-away for a Linux admin watching from outside: Group Policy is not going away soon — there is far too much of it, and servers still live on it — but new green-field Windows management increasingly starts in Intune, and the configuration concepts (targeted policy, precedence, baselines, drift correction) carry across even as the delivery mechanism moves to the cloud.
If you run a mixed fleet, the practical implication is that “managed Windows configuration” may now come from two sources, and a setting that is fighting you might be coming from Intune, not Group Policy, or vice versa — a new dimension of the same “which layer set this” question that Group Policy always posed internally.
Sources and further reading
- Microsoft Learn — Group Policy overview
- Microsoft — Security Compliance Toolkit and baselines
- Microsoft Learn — Manage ADMX templates and the Central Store
- Microsoft Learn — gpresult and Resultant Set of Policy
- Microsoft Learn — Group Policy vs. Intune / settings catalog
This is the second post in the Windows Server and Active Directory series. Next: Kerberos and Windows Authentication — how sign-on actually works, and how it gets attacked.
Comments