One setting, applied from the server, reaching every PC and every user in the office — that is Group Policy. This tutorial explains GPOs properly: the user half, the computer half, where a GPO can be linked, and how to prove a policy actually applied.
Group Policy is how an Active Directory admin controls hundreds of computers without walking to any of them. Block USB drives, set the wallpaper, map drives, lock the screen after five minutes — all of it is one Group Policy Object (GPO) edited once on the server. But beginners hit the same wall: they configure a setting, link the GPO, and nothing happens. Nine times out of ten the reason is one of the basics on this page — the setting was put in the wrong half of the GPO, the GPO was linked to the wrong place, or nobody checked the result. Learn the model first and every GPO after that becomes predictable.
How a real GPMC tree looks — OUs hold the accounts, GPOs are linked to OUs, and the settings live inside the GPOs. Example names shown.
A GPO is simply a named bundle of settings. It does nothing by itself. It starts working only when you link it to a container — a site, the domain, or an Organisational Unit (OU) — and it then applies to the user or computer accounts inside that container. Two facts follow from this, and they explain most beginner confusion. First, editing a GPO and linking a GPO are two separate jobs; a perfectly configured GPO that is not linked anywhere changes nothing. Second, one GPO can be linked to several OUs, and one OU can receive many GPOs — which is why the processing order (covered in its own guide) decides who wins when settings conflict.
Open the console with gpmc.msc on the domain controller or any PC with the RSAT tools installed. Everything in this tutorial happens in that one console.
Open any GPO and you will see the same two sections: Computer Configuration and User Configuration. They are not two views of one list — they are two different toolboxes with different settings, applied at different times to different accounts.
The honest rule: the account must sit under the linked OU, and the setting must be in the matching half. A wallpaper configured in Computer Configuration does nothing; a user setting linked to an OU that contains only computer accounts also does nothing. This single check fixes most "policy not working" cases.
GPOs link at three levels: site (a physical office location), domain (everyone), and OU (one department or group). In small and medium offices almost all linking happens at OU level, because you first organise accounts into OUs — one for office PCs, one for staff users, one for laptops, and so on.
One trap deserves bold type: the built-in Computers and Users containers are not OUs, and you cannot link a GPO to them. New accounts land there by default, which is why a freshly joined PC ignores your policies. Move the account into a proper OU first. The two GPOs that exist by default — Default Domain Policy (password and account rules) and Default Domain Controllers Policy — are best left mostly alone; create your own GPOs for your own settings so you can switch them off without touching the defaults.
gpmc.msc, right-click Group Policy Objects → New → give it a name that says what it does, like Block-USB-Drives.Naming honestly matters: after six months an office has forty GPOs, and names like "New GPO" or "test2" tell you nothing. Name by job, not by date.
Policies refresh on their own roughly every 90 minutes (with a random offset), but nobody tests that slowly. On the client PC, run:
gpupdate /force — reapply all policies now. Some settings still honestly need a restart (computer settings, software installs) or a fresh logon (user settings); /force cannot skip physics.gpresult /r — the receipt. It lists exactly which GPOs applied to the computer and to the user, and which were filtered out and why.gpresult /h report.html creates an HTML page showing every winning setting and which GPO it came from.Never judge a GPO by hope. gpresult /r is the proof, and it should be the first command you run whenever a policy "does not work".
One safety habit before you edit any working GPO: back it up first (right-click the GPO in GPMC → Back Up). Thirty seconds of backup is the difference between an experiment and an incident.
gpresult /r show the GPO as applied? Run these before changing anything else.
User policy and computer policy explained live on a real domain controller — create, link and test your first GPO with the video.
▶️ Watch Full VideoComputer policy applies to the computer account and is processed at PC startup; user policy applies to the user account and is processed at logon. A setting only works when it is placed in the matching half of the GPO and the GPO is linked to an OU containing that kind of account.
Member PCs and servers refresh in the background roughly every 90 minutes with a random offset of up to 30 minutes. You do not have to wait — run gpupdate /force on the PC to refresh immediately, though some settings still need a restart or a new logon.
Check that the account is actually inside the linked OU (the default Computers and Users containers cannot receive linked GPOs), that the setting is in the correct half of the GPO, and then run gpresult /r on the PC — it will show whether the GPO applied or was filtered out, and why.