Every Group Policy mystery ends the same way: somebody finally runs gpresult and reads it. The report lists each GPO the client considered, and for every rejection it records the reason — but only if you know what the verdicts mean. This page is the translation table.
Guessing at Group Policy from the server console is astrology: the console shows what you configured, not what any client did. The resultant set is computed on the client, from what actually downloaded and applied, and gpresult is how the client testifies. Generate the report on the affected PC, in the affected user's session — gpresult /h report.html for the full HTML record, gpresult /r for a quick console summary — and then read the verdicts below, in the order a triage actually flows.
Example report — three rejected GPOs, three completely different problems, three different fixes.
This is the verdict this whole topic revolves around: the client fetched the GPO, evaluated the account's permissions, and the account failed — it lacked Read or Apply Group Policy, or a Deny overruled its Allows. Work it as a checklist, in this order:
whoami /groups against every entry in the GPO's Advanced security. One nested Deny explains the politest mysteries.Denied (Inaccessible) means the client could not properly read the GPO from SYSVOL — permissions on the policy files themselves, a replication problem between domain controllers, or the machine pulling policy from a DC that does not have this GPO yet. The settings were never evaluated, so group memberships are innocent. Check that the GPO exists and matches on the DC the client used, and that SYSVOL replication is healthy.
Denied (Empty) is not an error at all: that half of the GPO contains no settings, so there was nothing to apply — a computer-only GPO will show Empty on the user side, and vice versa. Also expect Denied (Disabled) when the GPO, its link, or that configuration half has been disabled. Half of triage is refusing to chase verdicts that are the system working correctly.
When users swear their settings “ignored their OU”, the report settles it. Under User Settings → Applied Group Policy Objects, look at which GPOs delivered the user configuration. On a loopback PC in Replace mode, the list contains the GPOs from the computer's OU — and the user's own familiar GPOs are absent or listed as filtered out by the loopback mechanism. In Merge mode both families appear, with the computer's GPOs processed after the user's.
That single observation converts an hour of suspicion into a design question: is loopback supposed to be on for this machine? If yes, the report is showing you correct behaviour wearing a scary costume. If no, some GPO in the computer's path is enabling it — usually one named nothing like “loopback”, which is why this set keeps begging you to put the mode in the GPO's name.
Admins read the user section, shrug, and stop. But the report has a full Computer Settings side, and user-GPO mysteries regularly live there: the computer half shows whether the machine could reach and read policy at all, which domain controller served it, and when processing last ran. A user GPO “not applying” on a machine whose computer processing is failing wholesale is not a filtering problem — it is a machine problem wearing a user costume. Generate the computer view with gpresult /scope computer /h report.html from an elevated prompt when the quick summary smells wrong.
Also respect when the report describes: it is the last completed processing. A fix made five minutes ago proves nothing until a refresh or logon completes — run gpupdate /force, wait for it to finish, then regenerate the report before concluding anything.
gpresult /h report.html.gpupdate /force, regenerate the report, confirm the verdict changed.In the video, filtering decisions are proven with the resultant set on a real client — the same five-minute habit this page teaches.
▶️ Watch Full VideoBecause the resultant set of policy is computed on the client from what it actually downloaded, evaluated and applied. The server console only shows intended configuration. Modelling tools on the server can predict, but only the client's own report can testify.
Three checks, in order: have the user sign out and back in so the group membership enters their token; verify the computer account still has Read on the GPO (the MS16-072 trap); then look for a Deny Apply inherited through a nested group, using whoami /groups to see the full membership list.
The client never considered it — which points at scope, not permissions. The GPO is not linked into this user or computer path, the link is disabled, or the client pulled policy from a domain controller the GPO has not replicated to yet. Filtering verdicts only exist for GPOs that were at least evaluated.