A GPO you created is not reaching its PCs, and random clicking will not fix it. There is a disciplined order for this hunt — and the first command takes ten seconds and usually names the culprit.
Every admin knows the feeling: the GPO looks right, the setting is right, and the PC ignores it completely. Group Policy is a chain — account location, link, permissions, replication, client refresh — and the policy breaks at exactly one link of that chain. Guessing wastes the afternoon; the chain itself tells you where to look. Work this order, and use gpresult /r as the witness at every step: it separates the GPOs that applied from the ones filtered out, and filtered-out entries come with reasons printed in plain words.
Example output — the 'filtered out' section is the most valuable part. Here the PC is telling you the GPO exists, was seen, and was refused for a security reason.
The most common cause, and it is not close. GPOs apply to accounts by their position in the tree. The computer half comes from the OUs above the computer account; the user half from the OUs above the user account. Check in Active Directory Users and Computers: is the PC account actually inside the OU you linked to — or still sitting in the default Computers container, which is not an OU and can never receive a linked GPO? Same question for the user in the Users container. Also confirm the setting is in the matching half of the GPO; a user setting linked over computer accounts applies nothing, politely and silently.
In GPMC, find the GPO's link under the OU. A link can exist but be disabled (its icon shows it), and the GPO itself has a status on its Details tab: Enabled, Computer settings disabled, User settings disabled, or All settings disabled — a favourite leftover from somebody's old test. Also check the scope tab honestly: an enabled link to the right OU, a GPO whose relevant half is not disabled, and no Block Inheritance surprise on a child OU between the link and the account. Three glances, thirty seconds.
If gpresult /r lists your GPO under filtered out, it has already told you the answer: Denied (Security) means security filtering refused the account — check group membership, and on user GPOs remember the computer also needs Read (the MS16-072 rule). A WMI reason means the machine failed the filter's query — test the query on that PC. Empty means the GPO contains no settings in that half at all. And if a GPO applies but its settings are mysteriously replaced by different ones, suspect loopback on that PC's OU quietly rewriting whose user settings count.
With more than one domain controller, a brand-new GPO must replicate — both its Active Directory part and its SYSVOL files — before every DC can offer it. A PC asking the "wrong" DC in the first minutes can honestly not see it yet; give it a few minutes, or check replication health if it persists. On the client, confirm the basics that policy depends on: the PC's DNS must point at the domain controllers (a PC using only a public DNS cannot find the domain at all), the clock must be roughly right, and the machine must actually be talking to a DC — echo %logonserver% shows which one answered. Then gpupdate /force and read the result instead of assuming it.
For stubborn cases, the Group Policy Operational log in Event Viewer (Applications and Services Logs → Microsoft → Windows → GroupPolicy) records each processing cycle with event IDs and errors in sequence — it is the client's own diary of exactly what it tried and what failed.
Run gpresult /h report.html and open the report. It lists every applied and denied GPO with reasons, and — most usefully — shows the winning GPO for every setting. Half of all "not applying" cases turn out to be "applying perfectly, then being overwritten by another GPO that was processed later". That is not a failure of your GPO at all; it is LSDOU doing its job, and the report names the GPO you actually need to edit. Diagnose in order, change one link of the chain at a time, and re-check with the same command. The chain is short; the answer is always on it.
gpresult /h for the final truth. Never start at the bottom of this list.
User policy and computer policy explained live on a real domain controller — create, link and test your first GPO with the video.
▶️ Watch Full VideoSecurity filtering refused the account. The user or computer is not in a group that has Apply Group Policy permission on that GPO — or, on user GPOs, the computer account lacks Read permission, which has been required since the MS16-072 update.
Another GPO that processes later is overwriting it — normally a GPO linked to a deeper OU, or an Enforced GPO. Run gpresult /h report.html; it shows the winning GPO for every setting, which is the one you need to change.
Background refresh happens about every 90 minutes with a random offset, plus replication time between domain controllers. For testing, do not wait — restart or gpupdate /force one test PC and verify with gpresult before expecting the fleet to follow.