Open a well-run domain's Group Policy console and you can read it like a table of contents. Open a struggling one and there is a single GPO called something like Final-Policy-NEW containing the entire company's rules - and nobody dares touch it.
The top-10 list in this series is deliberately built as ten separate GPOs, not one GPO with ten sections. That is not tidiness for its own sake - it is the difference between a system you can operate and a system you merely possess. This page makes the case for one GPO per job, shows the naming scheme that makes a console readable at 2 AM during an incident, and explains what to do with the two built-in policies every domain already has.
Same settings, different structure. Only one of these can be operated during an incident.
The operational fact that decides everything: a GPO link can be enabled or disabled in seconds, and a GPO's individual settings cannot. When the USB block starts biting the wrong department, the admin with a Block-USB-Storage GPO disables one link and the incident is over. The admin with a giant GPO opens the editor and starts hunting through two hundred settings while the office waits.
Every GPO you create is a future switch you may desperately need. Create them at the granularity of things you might one day need to turn off separately - which is to say, one job each.
Name GPOs by job and scope, in the plainest words available: Block-USB-Storage, Screen-Lock-10-Min, Updates-After-Hours. The person reading the console during an incident may be you in six months, or a colleague who inherited the domain - neither has your memory of what New-Policy-Final2 meant.
Banned words in GPO names: new, final, test (outside the pilot OU), dates, and people's names. A GPO's name is documentation that never gets separated from the thing it documents - treat it with that respect.
Every domain ships with two GPOs. The Default Domain Policy is linked at the root, so everything in it touches everything - which is why the discipline is to keep it to the account policies (password, lockout, Kerberos) that genuinely must be domain-wide, and almost nothing else.
The Default Domain Controllers Policy gets the same respect: DC-specific settings only. The junk-drawer failure from the cautionary tales in this series - two years of quick fixes layered into the root policy - begins the first time someone edits the Default Domain Policy because it was already open. It is always already open. Close it and create the proper GPO.
With one GPO per job, the standard complaint - ye setting kahan se aa rahi hai? - answers itself. Run gpresult /h report.html on the affected PC: the report names the winning GPO for every applied setting. Winning GPO Block-USB-Storage is a complete diagnosis in three words.
Compare the giant-GPO world, where the winning GPO is always the same unhelpful name and the setting could be any of two hundred. Structure is not bureaucracy; it is what makes the built-in troubleshooting tools actually work.
Balance, as always. One GPO per job does not mean one GPO per setting - four hundred micro-GPOs slow logon processing and turn the console into confetti. A job is a natural unit an admin would test, filter and disable together: drive maps for staff is one job with five drives in it; the Accounts department's S: drive is not a separate job.
The top ten list lands in the sweet spot: ten jobs, ten GPOs, each independently pilotable. If your console is somewhere between ten and forty named GPOs for a normal office, the structure is healthy.
Inheriting a giant GPO is normal; here is the exit. Export or back up the GPO first (GPMC backup is one right-click). Then create the new per-job GPOs, link them at a pilot OU, and prove with gpresult /h that the pilot PCs receive identical settings from the new structure. Only then unlink the giant for the pilot, watch for a week, and repeat ring by ring.
Never edit the giant down and split it in the same afternoon - if anything breaks you will not know which half did it. The migration is a rollout like any other, and it obeys the same pilot discipline as everything else in this series.
The Top 10 GPO video builds the list as separate, named policies - watch how the console reads when the structure is right from the start.
▶️ Watch Full VideoThere is no magic number, but the failure mode at the top end is slow processing and an unreadable console, and it usually arrives in the hundreds, not the tens. Ten to forty clearly-named GPOs is a healthy office. If two GPOs would always be enabled, filtered and disabled together, they are one job and can merge.
A single GPO has both halves, and using both is fine when the job genuinely spans them. The convention that keeps consoles readable: disable the unused half in the GPO's status (it speeds processing slightly), and split when the user part and the computer part would ever be rolled out or filtered differently.
The account policies - password policy, account lockout and Kerberos policy - which only take effect properly at the domain level, and very little else. Everything else deserves its own named GPO. If you inherit a Default Domain Policy full of extras, migrate them out gradually using the refactor routine on this page.