Group Policy Deep-Dive

Early in my career I set up my first real Group Policy Object and wiped out every browser shortcut in the office. Favourites — gone. Replaced with a company intranet page nobody asked for. My manager walked over, didn’t say a word, and just turned his screen round to show me. All his shortcuts. Gone.

That’s the power of Group Policy, and it’s exactly why it’s worth understanding properly. This is Episode 3 of the TrevTech homelab series. Active Directory is running on trevtech.local, we’ve automated user creation with PowerShell, and now we’re going to use Group Policy to govern what those users can actually do — the right way, including the loopback step that broke me the first time.

This post doubles as a full follow-along guide: concepts first, then a click-by-click build of all four GPOs (with a PowerShell version at the end). Link it, bookmark it, send it to the person on your team who keeps asking why their GPO “isn’t working.”

Table of Contents

Why Group Policy Matters

Think about what a sysadmin is actually responsible for: keeping machines configured consistently, enforcing security standards, making sure the right software is on the right machines, and ensuring that when a new PC joins the domain it’s immediately in the right state.

Group Policy does all of that. Without it, you’re manually touching every machine. With it, you define the rules once, link them to the right place in AD, and they apply automatically — to every current and future object in scope.

It’s also a massive interview topic. Every sysadmin role that involves Windows will ask you about GPOs. Knowing how to create, link, troubleshoot, and force-update Group Policy is table-stakes for the job.

How Group Policy Actually Works

Before we build anything, two ideas make the rest of this make sense.

GPOs flow down in a set order. A GPO is a container of settings. You create it, configure settings inside, then link it to a site, domain, or OU. When a machine or user processes Group Policy, it collects every GPO linked above it and applies them in order: Local → Site → Domain → OU. The acronym is LSDOU, and order matters because the policy that applies last wins — unless someone blocks inheritance or sets “Enforced” higher up. That one rule is about 80% of every “why isn’t my GPO working?” question on the internet.

Every GPO has two halves. Computer Configuration applies to the machine at startup, regardless of who logs in. User Configuration applies to the user at login, on whatever machine they use. Knowing which half your setting lives in is half the battle — and as you’ll see in GPO 2, mixing them up is where people lose an afternoon.

The Lab Context

Everything runs on trevtech.local — the domain we built in Episode 1.

Detail	Value
Domain	`trevtech.local`
Domain Controller	`DC01` — 192.168.10.10
OS	Windows Server 2022
Clients	2 × Windows 11 VMs, domain-joined
OUs in scope	Workstations (computer accounts), Users (user accounts)

GPOs are created and managed via the Group Policy Management Console (GPMC) or PowerShell. We’ll use the GUI for the walkthrough since it’s easier to see the structure — the PowerShell version is in the appendix.

Follow-Along: Build the 4 GPOs

Here’s what you’ll build. Swap in your own domain name and OUs as you go.

#	GPO	Linked to	What it does
1	Default Domain Password Policy	Domain root	12-char min, complexity, lockout after 5
2	Workstation Security Baseline	Workstations OU	Block USB, force firewall, lock Control Panel, set wallpaper (+ loopback)
3	Drive Mapping	Users OU	Map `S:` to a shared folder at login
4	Block Downloads Executables	Workstations OU	Stop `.exe` files running from Downloads

Before you start, you’ll need a working AD domain, an account that’s a Domain Admin, the Group Policy Management Console (installed with the AD DS role, or via RSAT), and — for GPO 3 — a shared folder to map to (I use \\DC01\SharedDocs; any share your users can read works).

Open GPMC: Start → type Group Policy Management → open it. You’ll see your forest, domain, and OUs in the left tree.

The one rule that saves you hours: link each GPO where the objects it targets actually live. Computer settings → the OU holding your computers. User settings → the OU holding your users (or use loopback, GPO 2). Get this wrong and you either hit nothing, or you hit everyone — ask me how I know.

GPO 1 — Password Policy (domain level)

Why the domain root? Password and lockout rules for domain accounts only work when set at the domain level. Put them in a GPO linked to an OU and they’ll only affect the local accounts on those machines — not your domain users. So this one edits the policy linked at the top of the domain.

In GPMC, expand your domain. Right-click Default Domain Policy → Edit.

Go to Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Password Policy, and set:

Minimum password length → 12
Password must meet complexity requirements → Enabled
(Optional) Maximum password age → 365 days

Then under Account Policies → Account Lockout Policy, set Account lockout threshold → 5. Accept the suggested 15minutes for the duration and reset counter.

✅ You should see: new passwords are rejected if under 12 characters or not complex, and 5 bad attempts locks the account for 15minutes — across every account in the domain.

GPO 2 — Workstation Security Baseline (+ the loopback fix)

This is the big one. It mixes computer-side settings (USB, firewall) and user-side settings (Control Panel, wallpaper) in one GPO linked to the Workstations OU — and that mix is exactly where people get caught. We’ll fix it properly with loopback at the end.

Create and link it: right-click the Workstations OU → Create a GPO in this domain, and Link it here… → name it Workstation Security Baseline → OK → right-click → Edit.

Computer-side settings (apply to the machines in the OU):

Block USB storage: Computer Configuration → Policies → Administrative Templates → System → Removable Storage Access → All Removable Storage classes: Deny all access → Enabled.

Force the firewall on: Computer Configuration → Policies → Windows Settings → Security Settings → Windows Defender Firewall with Advanced Security → right-click → Properties → for the Domain, Private, and Public profiles set Firewall state = On.

User-side settings (these need loopback — step 5):

Lock the Control Panel: User Configuration → Policies → Administrative Templates → Control Panel → Prohibit access to Control Panel and PC settings → Enabled.
Set a standard wallpaper: User Configuration → Policies → Administrative Templates → Desktop → Desktop → Desktop Wallpaper → Enabled → enter a UNC path (e.g. \\DC01\SharedDocs\wallpaper.jpg).

⚠️ Step 5 — turn on loopback (the part everyone misses). Steps 3 and 4 are User Configuration settings, but this GPO is linked to the Workstations OU, which only holds computers. A user’s policy is normally read from wherever their account lives (the Users OU) — so without an extra step, those two settings apply to nobody. Loopback tells the computer “apply the user settings from the GPOs linked to my OU.” Set it in this same GPO:

Computer Configuration → Policies → Administrative Templates → System → Group Policy → Configure user Group Policy loopback processing mode → Enabled → Mode: Merge.

Merge — the user’s normal settings apply first, then these workstation settings layer on top and win conflicts. Best for shared work machines; use this.
Replace — only the workstation’s user settings apply; the user’s own are ignored. Use for kiosks/locked-down terminals.

✅ You should see: on a domain-joined workstation, USB drives are blocked, the firewall is on, and any user who logs in gets the Control Panel lockdown and wallpaper — regardless of which OU their account sits in. If the user settings don’t apply, loopback is the first thing to check.

GPO 3 — Drive Mapping (Users OU)

Linked to the Users OU — where the accounts live — so no loopback needed. It’s a Group Policy Preference, and it’s the one users actually notice: they log in and the drive’s just there.

Right-click the Users OU → Create a GPO in this domain, and Link it here… → name it Drive Mapping - S Drive → Edit.
Go to User Configuration → Preferences → Windows Settings → Drive Maps → right-click → New → Mapped Drive. [SCREENSHOT: New → Mapped Drive under Drive Maps]
On the General tab: Action = Update (more forgiving than Create) · Location = \\DC01\SharedDocs · Reconnect ticked · Drive Letter = Use → S: → OK.

✅ You should see: at next login, every user in the Users OU gets an S: drive pointing at the share — no manual setup on the machine.

GPO 4 — Block Executables from Downloads (Workstations OU)

A simple, cheap first layer against someone double-clicking the wrong thing. A computer-side Software Restriction Policy linked to the Workstations OU, so it protects the machine for every user.

Right-click the Workstations OU → Create a GPO in this domain, and Link it here… → name it Block Downloads Executables → Edit.
Go to Computer Configuration → Policies → Windows Settings → Security Settings → Software Restriction Policies → right-click → New Software Restriction Policies.
Click Additional Rules → right-click → New Path Rule… → Path = %UserProfile%\Downloads\*.exe · Security level = Disallowed → OK.

✅ You should see: double-clicking an .exe saved in any user’s Downloads folder is blocked with a policy message.

Modern alternative: on Windows Enterprise editions, AppLocker is the more robust, current tool for the same job — an Executable deny rule on %OSDRIVE%\Users\*\Downloads\*. Software Restriction Policies are simpler and work everywhere, which is why I use them here.

Test That It Worked

On a domain-joined Windows 11 client, in an elevated terminal:

# Pull the new policies down now instead of waiting for the 90-minute refresh
gpupdate /force

# Some computer-side settings (like the USB block) only take effect after a reboot:
gpupdate /force /boot

# See exactly which GPOs applied — and which were filtered out, and why
gpresult /r

# Full HTML report you can open in a browser or send to a teammate
gpresult /h C:\GPReport.html

gpresult /r is your best friend. If a setting didn’t apply, this tells you whether the GPO even reached the machine before you go digging. If I’d known about it before the intranet incident, I’d have caught my mistake in thirty seconds instead of from the look on my manager’s face.

The Gotchas (the silent ones that catch everyone)

1. gpupdate /force isn’t always instant. Computer-config changes that need a reboot (like the USB block) won’t take effect until the machine restarts. Use gpupdate /force /boot to confirm in the lab — don’t assume it applied just because the command finished.

2. Conflicting GPOs. If two policies set the same thing, the one lower in the LSDOU order wins — unless someone set Enforced on a higher-level GPO, which overrides everything below. Know your order before you debug for 45 minutes.

3. Linking to the wrong OU. Link the GPO where the affected objects live. Computers in the Workstations OU? Link there — not the domain root. Link at the root and it hits everything: users, servers, domain controllers, the lot. (That’s my intranet story in one line.)

4. Security filtering silently blocks. By default GPOs apply to Authenticated Users. Restrict the filter to a group, and if the object isn’t in that group, the GPO does nothing — no error, no warning, just nothing. Check the Scope → Security Filtering tab first when something won’t apply.

5. User settings on a computer OU do nothing — until loopback. A GPO linked to an OU that only holds computers won’t apply its User Configuration half to anyone, because users read their policy from wherever their account lives. Enable loopback processing (Merge or Replace) to make the user-side settings apply based on the computer’s location. This is the one that got me on the workstation baseline — settings right there, GPO linked, filtering fine, and it’s doing nothing. Loopback to Merge, gpupdate, log back in — done.

Is It Worth Learning?

Yes — especially for any sysadmin or IT admin role. GPO is one of those topics that’s slightly confusing until it clicks, and then it becomes one of the most satisfying parts of managing a Windows environment. You write the policy once, link it to the right place, and every machine and user in scope — the ones there now and the ones you haven’t built yet — just gets it. Automatically. That is the job.

Appendix — PowerShell version

Run on the DC with the GroupPolicy and ActiveDirectory modules (Import-Module GroupPolicy, ActiveDirectory). Adjust the domain/OU paths to yours.

# ── GPO 1 — Domain password + lockout policy (applies at the domain level) ──
Set-ADDefaultDomainPasswordPolicy -Identity trevtech.local `
  -MinPasswordLength 12 `
  -ComplexityEnabled $true `
  -LockoutThreshold 5 `
  -LockoutDuration "00:30:00" `
  -LockoutObservationWindow "00:30:00"


# ── GPO 2 — Workstation Security Baseline ──
$gpo = New-GPO -Name "Workstation Security Baseline"
New-GPLink -Name $gpo.DisplayName -Target "OU=Workstations,DC=trevtech,DC=local"

# Block USB storage (Computer side): USBSTOR Start = 4 disables it
Set-GPRegistryValue -Name $gpo.DisplayName `
  -Key "HKLM\SYSTEM\CurrentControlSet\Services\USBSTOR" `
  -ValueName "Start" -Type DWord -Value 4

# Lock the Control Panel (User side)
Set-GPRegistryValue -Name $gpo.DisplayName `
  -Key "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" `
  -ValueName "NoControlPanel" -Type DWord -Value 1

# Loopback processing = Merge (Computer side). 1 = Merge, 2 = Replace
Set-GPRegistryValue -Name $gpo.DisplayName `
  -Key "HKLM\Software\Policies\Microsoft\Windows\System" `
  -ValueName "UserPolicyMode" -Type DWord -Value 1

# Firewall + wallpaper are easiest in the GUI (steps 2 and 4 above).


# ── GPO 3 — Drive mapping ──
# Drive Maps are a Group Policy Preference (stored as XML), so they don't map
# cleanly to Set-GPRegistryValue. Create this one in the GUI (GPO 3 above).
New-GPO -Name "Drive Mapping - S Drive" |
  New-GPLink -Target "OU=Users,DC=trevtech,DC=local"


# ── GPO 4 — Block Downloads executables ──
# Software Restriction Policies aren't exposed through Set-GPRegistryValue.
# Create the shell here, then add the path rule in the GUI (GPO 4 above),
# or use AppLocker on Enterprise editions.
New-GPO -Name "Block Downloads Executables" |
  New-GPLink -Target "OU=Workstations,DC=trevtech,DC=local"

A few settings (firewall, GPP drive maps, SRP path rules) are genuinely cleaner in the GUI than in PowerShell — I’ve flagged those rather than fake a one-liner that doesn’t exist. The point is to be correct, not to force everything into a script.

What’s Next

Episode 4: DNS & DHCP from scratch. We’ll look at how name resolution and IP management work on trevtech.local — already running because AD stood it up for us, but there’s a lot more to understand beyond the defaults. “It just worked” is fine right up until it doesn’t, and then you really want to know how it works.

Watch it on TrevTech-IT on YouTube and tell me in the comments what GPOs you’re running in your own lab or at work.

— Trev | I broke it. Fixed it.