A GPO can be perfectly written and correctly linked — and still reach the wrong people, or nobody at all. Two controls decide the real audience: loopback processing, which chooses whose user settings apply on a PC, and security filtering, which decides who is allowed to apply the GPO in the first place.
Every Group Policy application silently answers three questions. Scope: is this GPO linked where the user or the computer actually lives? Filter: does the account hold permission to apply it? And when loopback is in play, a third: whose user settings count here — the person's, or this machine's? Most “my GPO is not applying” tickets are not broken policies at all. They are one of these three answers being different from what the admin assumed. This guide takes the two controls from the video — loopback and security filtering — and goes deep, because together they decide who really gets a policy.
Example overview — scope, filtering and loopback are evaluated in this order on every client, at every refresh.
Out of the box, a new GPO carries one security filter: Authenticated Users, holding both Read and Apply Group Policy. Authenticated Users is wider than it sounds — it includes every signed-in user and every domain computer account. That default is why a fresh GPO “just works” for everyone in its linked OU: users can apply the user settings, computers can apply the computer settings, and nobody has to think about permissions at all.
Processing then follows the familiar order — local, site, domain, OU — with user settings taken from GPOs in the user's path and computer settings from GPOs in the computer's path. Everything else in this guide is a deliberate deviation from that default story, and every deviation is where the surprises live.
Loopback processing is a computer setting (Computer Configuration → Administrative Templates → System → Group Policy → Configure user Group Policy loopback processing mode). When a PC has it enabled, the user settings for anyone logging on there are taken from the GPOs linked to the computer's OU instead — in one of two flavours:
Loopback never touches the computer half — computer settings always process normally. It exists for machines whose location matters more than their visitor: kiosks, labs, classrooms and Remote Desktop servers.
Security filtering is simply the GPO's access list doing its job. To receive a GPO, the processing account needs both Read and Apply Group Policy. Remove Authenticated Users from the filter and add a group, and only that group's members receive the policy — the standard way to pilot a change or target one department without moving a single account between OUs.
One fact rules this whole topic, and it has bitten admins since June 2016: since the MS16-072 security update, the computer account retrieves user GPOs from the domain controller, in the computer's security context. So the computer must be able to Read every GPO it fetches — including user GPOs filtered to a group the computer is not in. Take Read away from computers and the GPO is never even downloaded, for anyone. A dedicated page in this set walks through that trap and its one-minute fix.
Loopback and filtering interact, and the interaction is where experienced admins get caught. The user settings that loopback delivers live in GPOs linked to the computer's OU, but they are still user settings — the person logging on still needs Apply Group Policy on that GPO, and the computer still needs to read it. Tighten the filter on a loopback GPO to a computer group only, and the machine dutifully fetches a GPO whose user settings nobody at the keyboard is allowed to apply. Result: a perfectly configured kiosk GPO that silently delivers nothing.
The mirror-image mistake is just as common: filtering a user GPO to a pilot group of users and forgetting the computers — the pilot group's members get nothing, because their PCs could not read the GPO to fetch it.
Every claim in this guide can be verified on the affected PC in under a minute. Run gpresult /h report.html in the affected user's session and read the verdicts: Applied GPOs are listed at the top, and every rejected GPO carries its reason — Denied (Security) for a filtering decision, Denied (Inaccessible) for a fetch or permissions failure, Denied (Empty) when that half of the GPO simply has no settings. With loopback, the fingerprint is unmistakable: the GPOs listed as delivering user settings are the ones from the computer's OU.
Work on evidence, in this order — scope, filter, loopback — and the average “GPO not applying” ticket shrinks from an afternoon of superstition to a single permission change.
Both controls shown on a real domain controller in the video — loopback modes, the Scope tab, the Delegation tab, and the gpresult proof, step by step.
▶️ Watch Full VideoIt checks the GPO permissions of the account doing the processing. The account needs both Read and Apply Group Policy. For user settings since MS16-072, the computer account performs the retrieval, so the computer needs Read on the GPO even when the user settings are filtered to a user group.
No. Loopback only changes which GPOs supply the user settings on that PC. Computer settings always come from the GPOs in the computer's own path, exactly as they do without loopback.
Almost always the MS16-072 rule: with Authenticated Users gone, the computer accounts lost Read permission, so the GPO could not be downloaded at all. Add Authenticated Users or Domain Computers back with Read only (not Apply) on the Delegation tab, and keep Apply restricted to your target group.