3.3Group Policy (GPO) — basics
The essentials in 30 seconds
- GPOs apply rules and configurations to an entire fleet centrally, without going workstation by workstation.
- A GPO is created, then linked to an AD container (domain, site or OU); it applies at start-up (machine) or at logon (user).
- gpupdate /force forces reapplication to test; in case of conflict, precedence decides (site → domain → OU).
Running mini-case — Sofiane imposes a rule on a whole department
Sofiane, a systems administrator in a distribution SME in Algiers, must automatically lock the workstations' screens after a few minutes of inactivity, for the whole shipping department. He refuses to go workstation by workstation: he creates an “Auto-Lock” GPO, links it to the department's organisational unit, and lets the policy apply at start-up and at logon. He first tests on a pilot workstation with a gpupdate /force, checks the result, then rolls it out. He notes the reflex: few GPOs, well named, linked at the right level and always tested before deployment.
Standalone case for this section: it returns in the lesson, the diagram, the script and the 48h challenge of section 3.3.
1. Configuring 200 workstations without touching them
Group Policy Objects (GPOs) make it possible to apply configurations and rules to a set of users or computers, centrally, without going workstation by workstation. Corporate wallpaper, password rules, network drives, software restrictions: all this is driven by GPO. Sofiane sees in it the tool that turns a policy into configuration actually applied.
2. How a GPO applies
A GPO is created, then linked to an AD container (domain, site or OU). It then applies to the objects of that container, at the computer's start-up (machine settings) or at logon (user settings). The gpupdate /force command forces an immediate reapplication, invaluable for testing on a pilot workstation.
3. Scope and precedence
Because several GPOs can apply, there is an order of precedence (site → domain → OU, the closest generally winning). A good practice: few GPOs, well named, linked at the right level — rather than a forest of policies that contradict each other and become impossible to debug.
gpupdate /force. Linking a GPO too high widens the impact well beyond the need. And multiplying GPOs that contradict each other makes precedence unreadable: better a few clear policies. Sofiane always tests on a pilot workstation.🔎 Concrete example — 🔎 Concrete example — Imposing an automatic session lock
Security: locking the screen after a few minutes of inactivity, across a whole department.
1. Create a GPO "Auto-Lock"
2. Link it to the OU "Shipping"
3. Setting : lock after inactivity
4. gpupdate /force on a test workstation -> checkReading: a rule defined once applies to all the workstations of the OU.
Lesson: GPOs turn a security policy into configuration actually applied.
Section vocabulary
- GPO
- Group Policy Object: a set of rules and configurations applied centrally.
Simple example: Sofiane imposes screen locking by GPO.
What it is not: a setting made workstation by workstation by hand.
Reflex: impose a rule → GPO.
- Link
- Attachment of a GPO to a domain, a site or an OU.
Simple example: Sofiane links the GPO to the shipping department's OU.
What it is not: a GPO created but attached to nothing.
Reflex: target a GPO → link it.
- Machine / user settings
- Settings applied at the PC's start-up (machine) or at logon (user).
Simple example: Screen locking is a machine setting.
What it is not: a preference the user changes themselves.
Reflex: machine or user → the right pane.
- gpupdate /force
- Command that forces the immediate reapplication of GPOs.
Simple example: Sofiane runs it on the pilot workstation to check.
What it is not: waiting for the next natural refresh.
Reflex: test right away → gpupdate /force.
- Precedence
- Order that determines which GPO wins in case of conflict.
Simple example: The closest OU's GPO generally wins.
What it is not: a single GPO that never runs into conflict.
Reflex: GPO conflict → precedence.
In practice — In practice — Planning a GPO
- Choose a simple rule to impose (wallpaper, password, network drive), like Sofiane.
- Determine the target (which users or workstations) and the corresponding OU.
- Decide whether the setting is “machine” or “user”.
- Note how you would test with gpupdate /force on a pilot workstation.
Step-by-step script — deploying a GPO cleanly like Sofiane (4 min)
1) Choose the rule and name the GPO clearly (e.g. “Auto-Lock”). 2) Link it to the right container (the department's OU, not the root). 3) Set the setting, distinguishing machine and user. 4) Test on a pilot workstation with gpupdate /force. 5) Check the result, then roll it out.
Keep this sheet: fewer well-named GPOs = fewer precedence conflicts and simpler troubleshooting.
Copy-paste template — my GPO sheet
GPO : "Auto-Lock"
Target : OU "Shipping" (not the root)
Pane : machine setting (or user)
Setting : lock after inactivity
Test : gpupdate /force on a pilot workstation
Rule : few GPOs, well named ; test before deployingA corporate wallpaper
Sofiane deploys the shared wallpaper with a GPO linked to the workstations' OU.
A password policy
Sofiane imposes the length and renewal of passwords across the whole domain.
A network drive
Sofiane maps a shared drive for the accounting department with a targeted GPO.
A pilot-workstation test
Sofiane applies the GPO to a single workstation first, checks with gpupdate /force, then rolls it out.
✓ Best practices
- Few GPOs, well named and linked at the right level.
- Always test on a pilot workstation (gpupdate /force).
- Distinguish machine and user settings.
✗ Common pitfalls
- Multiplying GPOs that contradict each other.
- Linking a GPO too high (impact too broad).
- Deploying without a prior test.
Key takeaways
- GPOs apply rules and configs to a fleet, centrally.
- A GPO is created, linked to an OU, then applied at boot/logon.
- gpupdate /force forces reapplication to test.
- In case of conflict, precedence decides; better a few clear GPOs.
48h challenge — apply it tomorrow
Like Sofiane, design a GPO for a simple rule (screen locking, password, network drive): name it, state the target (which OU), specify whether the setting is machine or user, and describe the test you would run with gpupdate /force on a pilot workstation.
- I can explain what GPOs are for.
- I describe the cycle: creation, linking to an OU, application, test.
- I know that a pilot-workstation test and precedence matter.
Frequently asked questions
Does a GPO apply instantly?
Not always: GPOs refresh at start-up, at logon and periodically. For an immediate test, you use gpupdate /force, then check the result on the pilot workstation.
What to do if two GPOs contradict each other?
Precedence decides (often: the GPO linked to the OU closest to the object wins). In practice, you simplify: fewer GPOs, explicit names and a test avoid most conflicts.
What are Group Policy Objects (GPOs) for?