The same GPO has two halves, and they wake up at two different moments. Computer settings fire when the PC boots; user settings fire when a person logs on. Understand this one clock and half of all GPO confusion disappears.
A young admin once set a desktop wallpaper inside Computer Configuration, waited a day, and declared Group Policy “broken”. It was not broken — the wallpaper setting simply does not exist in the computer half, because a wallpaper belongs to a person, not a machine. Every GPO setting has an owner: the PC or the user. This page draws the line cleanly — which half fires when, which settings live where, and what happens when a PC and a user bring conflicting instructions to the same desk.
Example timeline — computer settings belong to the boot, user settings belong to the logon.
Computer settings are read from the domain controller while Windows is starting, before the logon screen appears. They apply to the machine no matter who sits down at it — the director, a trainee, or nobody at all. That is why machine-level jobs live here: blocking USB storage, installing software for the whole PC, setting Windows Update behaviour, password and security options, firewall rules, and startup scripts that must run before any user arrives.
Practical consequence: after changing a computer setting, the honest test is a restart of the PC (or at least a gpupdate /force plus patience for settings that truly need boot time). Logging off and back on does nothing for this half, because no new boot happened.
User settings process when a user logs on, and they follow that person from PC to PC. Priya gets her mapped drives and wallpaper on the accounts PC, and the same settings appear if she logs on at reception. User-half jobs are the personal environment: drive mappings, folder redirection, desktop and Start settings, Control Panel restrictions, logon scripts, and printer connections.
The mirror-image consequence: after changing a user setting, test with a logoff and fresh logon (or gpupdate /force). Restarting the PC also works — a logon happens after the boot — but it is the logon, not the boot, that does the job.
Some setting families appear in both halves — scripts, Administrative Templates for Office and Windows components, and security-adjacent options — but they are separate settings with separate effects. A startup script and a logon script are different scripts, run at different times, with different permissions: startup scripts run as the machine (SYSTEM), logon scripts run as the user, with only that user's rights. A script that works at logon can fail at startup simply because the machine account cannot reach the network share it points to.
When a setting seems to be "in the GPO" but nothing happens, open the editor again and look at which half you are standing in. This is the single most common GPO mistake, and it costs nothing to check.
Can the computer half and the user half fight? On the same setting, mostly they cover different ground, so true head-on collisions are rare. The real conflict pattern is different: the user's GPOs say one thing and the computer's location should override it — think of a training-room PC where any user who logs on must get the locked-down training desktop, not their normal one. Normal processing cannot do that, because user settings follow the user. That special case is exactly what loopback processing exists for, and it has its own guide in this series. In ordinary offices, leave loopback off.
Also remember both halves refresh together in the background about every 90 minutes — so a setting can quietly arrive mid-day, which is why users sometimes say "it fixed itself at lunch".
Before creating any GPO, ask one question: "Should this still be true if a different person logs on?"
Then verify with gpresult /r on a test PC: it prints the computer's applied GPOs and the user's applied GPOs in two separate lists — a perfect picture of the two halves doing their separate jobs.
gpupdate /force refreshes both halves immediately, but settings that are only processed at boot or logon — folder redirection, software installation, drive mappings in some cases — still wait for the real event. A restart plus a logon is the only test that covers everything.
User policy and computer policy explained live on a real domain controller — create, link and test your first GPO with the video.
▶️ Watch Full VideoYes. Computer policy is processed at startup, before the logon screen, and applies to the machine itself. That is why things like USB blocking and Windows Update settings work on a PC sitting empty at the logon screen.
Usually a gpupdate /force is enough for simple settings, but some user settings — folder redirection, logon scripts, drive mappings in certain setups — only process at a real logon. A logoff and fresh logon is the reliable test.
Yes, every GPO has both halves and you can use both. Just remember the computer half is read from the OUs of the computer account and the user half from the OUs of the user account, so one GPO linked to one OU may only deliver half of what you configured.