Server · Group Policy
Group Policy: create, link, and troubleshoot policies that apply — and diagnose the ones that don't
Group Policy is how you make hundreds of Windows machines behave consistently without touching each one: standard settings, security baselines, scripts, and software, pushed from a domain controller to the computers and users that need them. It is also one of the most "invisible" systems an administrator owns — when a policy applies, nothing dramatic happens, and when one doesn't, the failure is silent until something is wrong and someone asks why.
This is a 40-tutorial series in five modules. It moves from the fundamentals (what a GPO is, where it lives, how it's processed) through safe creation and linking, then into the part most guides skip: proving which policies actually apply to a given user or computer, and a complete, evidence-based workflow for the policies that don't. Every tutorial is written to stand alone — a real problem, the underlying behavior, a concrete procedure, the evidence that confirms it worked, and the failure modes to expect.
A note on scope and safety before you start: Group Policy changes are organization-wide configuration changes. A single mis-scoped GPO can lock users out of a console, break remote management, or change authentication behavior across an entire domain. This series consistently recommends a test OU and a lab first, explains who a change affects, and shows how to roll each one back. Use the fictional contoso.test domain in the labs; substitute your own names, and never assume a specific server version, IP, or group exists in your environment.
How it fits together
One domain controller, many GPOs, a client that decides what to apply
Keep this picture in mind through all 40 tutorials. A GPO has two halves that live in two different places: its metadata (the object, its links, its permissions) in Active Directory, and its files (settings, scripts, templates) in SYSVOL. A client doesn't get pushed a policy — it pulls from a domain controller at startup and logon, then works out, from its own location and the target's location, which GPOs are in scope, which are filtered out, and which setting wins. Troubleshooting is almost always about one of those decisions going wrong, which is why the later modules are built around evidence rather than guesswork.
The traces show the two directions that matter: policy out (controller → GPOs → the OU a target sits under → the client) and evidence back (the client telling you, via gpresult, RSoP, and the event log, exactly which GPOs applied and which were denied, and why). That read-back is the backbone of Modules 3 and 4 — you never argue about a policy; you read the decision.
The index
Browse all 40 tutorials
Search by title or keyword and narrow by module — the two combine (a search only returns results in the selected module). Every entry links straight to its tutorial below.
40 tutorials
Module 1 · Fundamentals
Group Policy fundamentals
Tutorials 1–8 establish the mental model: what a GPO is, where it physically lives, how a client decides what to apply, and the processing order that makes "last wins" more complicated than it sounds. Everything later in the series depends on getting these right.
1 · What is Group Policy? Understanding GPOs and their purpose
Group Policy is the mechanism Windows Server uses to manage computers and user accounts by policy rather than by hand. Instead of configuring each machine — setting a password rule, applying a security template, mapping a drive, restricting a control — an administrator configures it once in a Group Policy Object (GPO) and attaches (links) that GPO to a place in Active Directory. Every computer or user in that place then picks up the settings automatically at startup or logon. The whole value proposition is scale and consistency: the same correct configuration on hundreds of machines, changed in one place, without a technician at every desk.
A GPO is a bundle of settings, and the settings span several categories you'll meet repeatedly in this series. Administrative Templates control how Windows and its features behave (desktop restrictions, security options, device install rules). Security Settings cover password policy, local user rights, and audit policy. Scripts (logon/logoff for users, startup/shutdown for computers) run code at defined times. Software installation and drive maps / folder redirection deploy and redirect resources. Understanding that a GPO is a container of many setting types — not one thing — is what stops people from being surprised when a single GPO changes more than they expected.
The real-world problem Group Policy solves is drift and effort. On a handful of machines you can configure by hand and it holds; on a few hundred, hand configuration becomes impossible to keep consistent, and any change becomes a multi-day project. Group Policy turns "configure a machine" into "configure a policy and point it at the right group," which is also why a mistake is equally scalable — the same mechanism that rolls a good setting out everywhere can roll a bad one out everywhere. That symmetry is the reason this series treats scope and testing as first-class concerns, not footnotes.
2 · How Group Policy works in a Windows Server domain
A GPO has two physical halves in two different stores, and confusing them causes most "but I changed it, why didn't it apply" problems. The metadata — the GPO object itself, its display name, its links, and its permissions — lives in Active Directory, in the domain partition. The files — the actual settings, scripts, and administrative templates, organized into computer\ and user\ folders with a gpt.ini version stamp — live in SYSVOL, specifically under \\<domain>\SYSVOL\<domain>\Policies\<GUID> and served to clients over the NETLOGON share. When you edit a GPO in the console, you are updating both: the AD object and the SYSVOL files, and the gpt.ini version number is how a client knows the policy has changed since it last applied it.
Policy storage is not policy application — that distinction is the heart of the topic. Storing a GPO and linking it only make it available; the client still has to (a) reach a domain controller, (b) determine which GPOs are in scope for it, (c) evaluate security filtering and any WMI filters, and (d) actually process the settings. A GPO can be perfectly stored and linked and still not apply to a given machine for any of reasons (c) or (d). The client pulls policy on a schedule — at computer startup and user logon, plus a background refresh roughly every 90 minutes (with random offset) for both computer and user policy — rather than being pushed on every change, which is why changes are not always instantaneous.
Because the client does the evaluation locally against what it can read, the domain controller's job is really to serve the AD metadata and the SYSVOL files reliably and consistently across every DC. That's why DNS (finding a DC), replication (the same GPO files on every DC), and SYSVOL availability keep reappearing in the troubleshooting modules: if the client can't find a DC, or a DC is serving an older copy of the GPO files, the client will either fail to apply or apply stale settings — and from the user's desk it looks identical to "the GPO is broken."
3 · Local Group Policy vs. domain Group Policy
Local Group Policy is the policy a single computer applies to itself, edited with gpedit.msc (on Pro/Enterprise editions; the Local Security Policy secpol.msc covers the security subset). It has no domain, no replication, and no other machines — it is that one machine's own settings. Domain Group Policy is managed centrally with the Group Policy Management Console, lives in AD and SYSVOL, and applies to computers and users across the domain based on where they sit. The practical difference is scope and audience: local policy affects one box that you can walk to; domain policy affects a population you manage remotely.
Where people get confused is precedence. A domain-joined computer processes both local and domain policy, and for most settings the domain-processed GPOs are applied after local policy in the LSDOU order, so the domain settings generally win — but this is not an absolute guarantee for every setting, and a setting that isn't configured in any domain GPO will fall back to the local value. You can also disable local policy entirely from the domain (a computer-configuration policy setting), which is how a site forces machines to obey central policy and ignore local edits. So "local vs domain" isn't a either/or; it's a layered thing where domain policy normally takes precedence and local policy fills the gaps it doesn't.
Use the right tool for the job. Local policy is for a standalone machine, a domain controller itself (which doesn't receive domain GPOs for itself in the usual way), or a quick isolated test. Domain policy is for anything you want standardized, audited, and changeable without touching each machine. A common mistake is making a "temporary" local change on a domain-joined machine and being surprised when the next policy refresh silently reverts it — on a domain-joined box, treat local edits as provisional unless you've also disabled local policy.
4 · Group Policy Objects explained: settings, links, and storage
Break a GPO into its parts and three things keep coming back. First, the two configuration sections: Computer Configuration and User Configuration. Every setting in a GPO belongs to one of these, and which one it belongs to determines when and to whom it applies (a topic that becomes critical in Tutorial 24). Second, the link — a GPO does nothing until it's linked to a site, domain, or OU; the link is what puts the GPO into scope for the objects under that container. Third, storage: the AD object (metadata) plus the SYSVOL files (the actual content), versioned by gpt.ini.
In the SYSVOL files you'll see the shape that maps to the console: a GPO.xml that describes the GPO, then computer\ and user\ trees holding the settings (and, in the classic template model, .adm/.admX files) plus a scripts\ folder for the script entries. The gpt.ini at the root carries a VersionNumber; each time you save a change the number bumps, and that's the client's cheap way of knowing "this GPO changed, re-read it" without comparing every file. When you "copy" or "backup" a GPO you're really capturing both the AD object and these files — which is why a backup is more than a folder copy and why restoring needs to re-establish the link and permissions, not just the files.
One structural fact saves a lot of later confusion: a GPO is not the same as its link. You can have one GPO linked in several places, or a GPO with no links at all (created but not applied anywhere — a common source of "orphaned" GPOs). The GPO is the what (the settings); the link is the where (the scope). Keeping that separation in your head makes Module 3's "which applies" questions much easier, because you'll naturally ask both "does this GPO contain the setting?" and "is it linked somewhere this target can see it?"
5 · Group Policy Management Console: a practical interface guide
The GPMC is the standard console for domain Group Policy (installed as a Windows feature / RSAT role). Its tree has two views that people mix up: the Domains and Forests view, where you see the AD hierarchy and, on each container, the GPOs linked to it, and the GPOs view (under the domain), where you see every GPO object and its contents. The rule of thumb: links live on the container; contents live on the GPO. To edit settings, right-click a GPO in the GPOs view and choose Edit. To add or remove a link, right-click the site/domain/OU and choose Link an Existing GPO or Create GPO in this location and Link It Here.
A few safe-administration habits matter more here than any single feature. First, use a dedicated test OU for anything new — create the GPO, link it to OU=GP-Lab, put one test computer and one test user there, and verify before ever linking broadly. Second, treat the Default Domain Policy with care: it holds domain-wide password and account policies and is linked to the domain root, so an edit there affects everyone; many teams deliberately avoid editing it and use fine-grained policy instead (Tutorial 12). Third, the GPMC's Scope tab on a linked GPO is where security filtering, WMI filters, and the Enforced / Block inheritance checkboxes live — it's the single most useful place in the console for Module 3, and the Link Order list shows the processing order for that container.
Finally, know what the console doesn't show you quickly: it tells you what's configured and where it's linked, but not what a specific user or computer actually received — that's gpresult/RSoP on the client (Module 3). The GPMC's Group Policy Modeling wizard does a simulation ("what would apply to user X"), which is powerful for planning, but a simulation is not the same as the actual result on a live machine. Pair the console (authoring + scope) with the client-side tools (verification) and you have the complete workflow this series builds toward.
6 · Active Directory sites, domains, and OUs for GPOs
How you organize Active Directory directly shapes what Group Policy can target, so the directory design and the policy design are the same design. A domain is the security and policy boundary — domain-linked GPOs apply to every computer and user in that domain. A site is a network-location concept (based on IP subnets) used mainly for replication and for site-scoped deployment; site-linked GPOs apply based on where a computer physically logs in (its site), which is a different axis than its OU. An organizational unit (OU) is the workhorse for policy: you design OUs to match how you want to manage (by department, location, function), and you link GPOs to OUs so the right settings reach the right population. Inheritance then carries parent-OU GPOs down to child OUs automatically.
Because targeting follows structure, a common failure is a policy that's correct but aimed at the wrong shape of the tree. If you link a GPO to OU=Sales but your sales computers are actually in OU=Sales,OU=East, the GPO still applies (inheritance) — but if someone later blocks inheritance on the child, or you meant to exclude a subgroup, the structure decides the outcome. This is why "which OU is this computer actually in?" is a standing question in Module 4: you can answer it definitively with dsquery or by looking at the computer object's path, and it resolves a large share of "it's not applying" tickets faster than any other single check.
A practical design guideline: keep a management OU structure separate from the default Users and Computers containers, because domain-level GPOs apply to objects in those default containers and those objects don't inherit from your management OUs. Move the computers and users you manage into purpose-built OUs, and your GPOs will target them cleanly. Sites matter less for everyday GPO targeting but become important when you deploy by physical location (for example, different settings per branch office) or when you need to understand why a computer's user policy is coming from an unexpected place (a user roaming between sites).
7 · Computer Configuration vs. User Configuration
Every GPO setting lives in one of two sections, and the section decides who it's for and when it's processed. Computer Configuration settings apply to the computer object, are processed at startup (and on the computer background refresh), and are determined by where the computer sits in AD. Typical computer settings: Security Settings, Windows Defender Firewall, startup/shutdown scripts, drive maps, and most Administrative Templates that affect the machine. User Configuration settings apply to the user object, are processed at logon (and on the user background refresh), and are determined by where the user sits in AD. Typical user settings: logon/logoff scripts, desktop and Control Panel restrictions, folder redirection, and software the user runs.
The decision rule when you're choosing a section: ask "does this need to be true about the machine regardless of who sits at it, or about the person regardless of which machine they use?" A firewall rule, a startup script, or a disk-quota policy is about the machine → Computer Configuration. A desktop restriction, a mapped "My Documents" redirection, or a logon script that drops per-user files is about the person → User Configuration. Getting this wrong produces the classic symptom "it works for my account but not theirs" — you put a user setting in the computer section (or vice versa) and it's processed against the wrong object at the wrong time.
| Attribute | Computer Configuration | User Configuration |
|---|---|---|
| Applies to | The computer object | The user object |
| Processed at | Startup (and computer refresh) | Logon (and user refresh) |
| Determined by location of | The computer in AD | The user in AD |
| Typical settings | Security, firewall, startup/shutdown scripts, drive maps | Logon/logoff scripts, desktop restrictions, folder redirection, software |
| "True about…" | The machine, whoever uses it | The person, on any machine |
8 · Processing order: Local, Site, Domain, and OU (LSDOU)
When a client applies policy, it processes GPOs in a fixed order, remembered as LSDOU: Local, then Site, then Domain, then OU. Within each level, multiple linked GPOs are processed in their link order (the order shown in the GPMC's Link Order list — lower in the list is processed later). The working rule most admins start with is that, for a given setting, the last-processed value generally wins, so an OU GPO typically overrides a domain GPO, which overrides local policy. That rule is a good starting point and is correct for many settings.
But "last wins" has real limits, and over-trusting it is a source of misdiagnosis. Three caveats: (1) Enforced links break the simple order — a GPO marked Enforced (No Override) at a higher level can win over a later, non-enforced GPO at a lower level, so a domain GPO can override an OU GPO if it's enforced. (2) Some settings accumulate or combine rather than replace — for example, logon scripts and some security settings from multiple GPOs can all apply rather than one overwriting the others, so "which wins" isn't the right question; "which all apply" is. (3) A setting only "wins" if it's actually configured in the later GPO — if the later GPO leaves a setting Not Configured, it doesn't override the earlier value; it simply doesn't touch it. So the honest statement is: processing order determines the sequence, and the effective result depends on which GPOs actually configure each setting, plus any enforcement.
| Level | Scope | Processed | Notes |
|---|---|---|---|
| Local | Single machine (gpedit.msc) | First | Domain-joined: normally overridden by domain GPOs |
| Site | By the computer's physical site | Second | Site-linked GPOs, in link order |
| Domain | Every object in the domain | Third | Includes Default Domain Policy |
| OU | The OU (and inherited children) | Last | Typically highest precedence; Enforced links can override |
Module 2 · Creating & linking
Creating, linking, and managing policies
Tutorials 9–16 are the hands-on deployment module: build a GPO the safe way, link it at the right scope, and configure the specific policy types people actually deploy — password policy, restrictions, firewall, scripts — plus the change-control discipline (backup, restore, document) that keeps a growing GPO estate manageable.
9 · Create your first Group Policy Object safely
The safe version of "create a GPO" has a deliberate order: name it, link it to a test OU, configure one benign setting, verify it applied, then consider broader deployment. In the GPMC, right-click the GPOs node → New, give it a meaningful name (a convention like SG-Win10-Baseline — scope-group-style naming pays off later), and create it unlinked. Then create or pick a test OU (say OU=GP-Lab), right-click it → Link an Existing GPO, and select your new GPO. Now put one test computer object and one test user object into OU=GP-Lab. Only now do you open Edit and configure a single, safe setting — a harmless Administrative Template or a benign message — so the blast radius of any mistake is one test machine.
New-GPO -Name "SG-GP-Lab-Test" -Domain "contoso.test" |`
New-GPLink -Target "OU=GP-Lab,DC=contoso,DC=test"The GroupPolicy module must be available (RSAT on a workstation, or a DC). This creates the GPO and links it to the test OU in one pipeline. Confirm with Get-GPLink on the OU.
Verify before you scale. On the test computer run gpupdate /force, then gpresult /h gp.html /f and open the report — your GPO should appear under Applied Group Policy, and the setting should be visibly in effect. If it doesn't appear, you've learned the diagnostic loop early (it's usually the object not being in the OU, or security filtering — both covered in Module 3). The point of the test-OU discipline is that every time you create something new, your first question is always "does it apply to the one machine I intended?" — and you get to answer that with zero risk to production.
Safe-admin habit. Do not create your first GPO by editing the Default Domain Policy or by linking a new GPO to the domain root. Both are domain-wide in effect. The test OU is your sandbox; everything in this module assumes you've got one.
10 · Link a GPO to an Active Directory domain
Linking a GPO to the domain (rather than a site or OU) makes it apply to every computer and every user in that domain — including the default Users and Computers containers, and everything that inherits. That's occasionally exactly what you want (a domain-wide baseline you intend to apply universally), but it's also the highest-blast-radius link you can make, so the skill here is recognizing when domain-level is right and when it's a shortcut you'll regret. A domain link is appropriate for genuinely universal settings; it's the wrong tool when you actually want to target a subset, because there's no per-group granularity at the link itself — you'd have to fall back on security filtering to narrow it.
The safer alternative for "broad but not everything" is to link to a broad management OU that contains the population you mean, or to keep the GPO domain-linked but apply security filtering so only a specific security group has Read + Apply (Tutorial 18). Each has trade-offs: an OU link is structurally scoped and easy to reason about; security filtering keeps one domain-wide GPO but adds a permissions layer that must be maintained. Whichever you choose, the principle is the same as Module 1: the link defines scope, and you should be able to state in one sentence who this GPO affects. If you can't, the scope is too broad or too ambiguous to link broadly yet.
Before you make a domain link, run the two checks that prevent most disasters. First, can you describe the affected population precisely? If the answer is "everyone," confirm that's intended. Second, is there a test path? For a genuinely domain-wide change, a common pattern is to link to a test OU first, prove it, then — only after review — add the domain link, and to keep a backup (Tutorial 16) so you can roll back. Remember the rollback is simply removing or disabling the link (and, for a mistake inside the GPO, restoring from backup), which is why the backup step isn't optional for domain-scoped changes.
11 · Link a GPO to an Organizational Unit
Linking to an OU is the default, lowest-risk way to deploy: the GPO applies to every computer and user in that OU and in any OU nested under it (via inheritance), and to nothing else. The procedure is short — right-click the OU → Link an Existing GPO (or Create GPO in this location and Link It Here) — but the step that actually determines success is verifying the target is really where you think it is. A GPO linked to OU=Sales will not apply to a sales computer that lives in OU=Sales,OU=London only if inheritance is intact; it will apply there normally, but it will not apply to a sales computer that's in OU=Marketing by mistake. "Where is this object, really?" is the question to answer with evidence, not assumption.
dsquery computer -name "WS-Sales-01" -o | dsget computer -memberofReturns the computer object's container path, so you can confirm it sits under the OU your GPO is linked to (or under a child of it). Equivalent checks exist for user objects.
After linking, the verification is the same loop as Tutorial 9 but now scoped: confirm the GPO shows in Applied Group Policy for a test object in the OU, and — just as important — confirm it does not apply to a test object outside the OU. That negative test is what proves your scope is actually contained and that you haven't accidentally linked at a higher level. If an in-OU object isn't getting the GPO, the usual suspects (in link-order of likelihood) are: the object isn't actually in that OU, Block inheritance is set on the OU, or security filtering is excluding it — each has a specific evidence-based check in Module 3, so you'll already know where to look.
12 · Configure password and account lockout policies correctly
Password and account-lockout policy is the classic "the setting exists in the editor but it does nothing where you put it" trap, so get the scope rule firmly in mind: domain-wide password/lockout policy is domain-scoped and is set in the Default Domain Policy GPO (under Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies). If you configure password settings in a GPO linked to an OU, they are ignored — password policy is one of the few setting families that only takes effect at the domain level. To have different password rules for, say, administrators versus standard users, you use Fine-Grained Password Policy (Password Settings Objects), configured in the GPMC under the domain's Fine-Grained Password Policy node, which lets you assign a Password Settings object to a group or user with a defined precedence.
The distinction to internalize is domain account policy (one set of rules for the whole domain, in the Default Domain Policy) versus fine-grained policy (per-group/per-user overrides, applied to the objects they're assigned to, with lower-precedence-number winning). Lockout settings (threshold, duration, observation window) live in the same Account Policies area and follow the same domain-vs-fine-grained split. When you change these, the change is authentication-affecting for a population, so the same discipline applies: state who it affects, test with a non-critical account first, and keep a record of the before-values so you can restore them (a lockout that's too aggressive can lock people out; too loose undermines security).
Verify with the right tool, not the GUI: on a domain controller, net accounts shows the effective domain password and lockout policy, and Get-ADDefaultDomainPasswordPolicy / Get-ADFineGrainedPasswordPolicy (Active Directory module) show domain and fine-grained settings respectively. If you set fine-grained policy and net accounts hasn't changed, that's expected — net accounts reports the domain default, and the fine-grained value applies to the assigned group on top of it. Confirm the fine-grained assignment is actually on the group you expect before concluding it "didn't work."
Get-ADDefaultDomainPasswordPolicy | Format-List *
Get-ADFineGrainedPasswordPolicy -Identity "Admins-Policy" |
Select-Object Name, Precedence, MinPasswordLength, LockoutThreshold, AppliesToRequires the Active Directory module on a DC (or a workstation with RSAT and AD permissions). The first line is the domain default; the second shows a fine-grained object's settings and, crucially, what it Applies To.
13 · Deploy desktop and user restrictions through Group Policy
Desktop and user restrictions (mostly under User Configuration → Administrative Templates → Control Panel / Start Menu / Desktop, and the classic "System" restrictions) are how you standardize the user experience and limit what a user can change: hide Control Panel, prevent adding/removing programs, disable the Registry Editor, lock the desktop, prevent Task Manager, and so on. These are user-scoped, so they follow the user (Tutorial 7) and process at logon. The craft here is judgment, not command syntax: each restriction is a trade-off between control and usability, and a well-designed set is the minimum needed for your security and support posture, not a maximal lockdown.
Three considerations keep a restrictions GPO from becoming a support nightmare. Security: some restrictions are genuine hardening (disabling Registry Editor for standard users prevents a class of self-inflicted breakage). Usability: a restriction that blocks a legitimate task generates tickets and workarounds — before you deploy, ask what the blocked action was for. Compatibility and reversibility: a restriction applied domain-wide to everyone is hard to unwind per-person, so scope it to the population that needs it, and test on a real user account (not just a machine) to feel the effect. A particularly common mistake is disabling something a support or admin workflow depends on, then being locked out of the fix by the very policy you just deployed — which is exactly why the test-OU + test-user discipline from Tutorial 9 matters here more than anywhere else.
Deploy the way you deploy everything in this module: create the GPO, link it to a test OU, put a test user in it, log on as that user, and confirm both that the restriction is enforced and that nothing the user legitimately needs is broken. Then scope it to the real population (usually a security group via security filtering, or a "standard users" OU) and document each restriction and why it's there. Restriction GPOs accumulate fast and "why is Task Manager disabled?" becomes a real question in six months; a one-line rationale per setting is cheap insurance. Rollback is trivial (remove the link or set the setting back to Not Configured) — set to Not Configured, not to Disabled, if you want the setting to simply stop applying and defer to whatever else does.
14 · Configure Windows Defender Firewall using Group Policy
Firewall policy is under Computer Configuration → Policies → Windows Settings → Security Settings → Windows Defender Firewall with Advanced Security, and it's one of the highest-risk settings you'll deploy, because a mis-scoped firewall rule can cut off remote management — including the very RDP session you're using to manage the box. The structure to understand: firewall policy is evaluated per network profile — Domain, Private, and Public — and a computer uses whichever profile matches its current network. A rule you add under the Domain profile won't apply when the machine is on a Public network, and the default posture for Public is the most restrictive. So "which profile" is as important as "which port."
Rule design follows a safe pattern. Decide direction (inbound vs outbound), program or port, profile, and action (allow or block). The dangerous direction to get wrong is inbound allow on a broad scope, and the dangerous omission is blocking the port you use to administer. If your machines are RDP-managed, any firewall change must keep inbound 3389 allowed from your management subnet (scope the rule to that source range rather than "Any") — otherwise you can deploy a policy that locks you out of the machines you're configuring. This is the single best argument for the test-OU approach on firewall GPOs: deploy to one test machine, from a different machine, so that if the test machine loses connectivity you're not locked out of your own session.
Test and verify deliberately. On the test computer, after gpupdate /force, confirm the rule exists with netsh advfirewall firewall show rule name=all (or Get-NetFirewallRule) and that it's enabled for the intended profile, and test the actual behavior (can you reach the service? is RDP still up from your management host?). Because a firewall GPO is computer-scoped and connectivity-affecting, always keep the rollback ready: a documented list of the rules you added, and the ability to remove the GPO link or restore the firewall policy. The rule of thumb: never deploy a firewall change to a broad scope while your only access path goes through the machines you're changing, and never without a scoped allow for your management path.
Get-NetFirewallRule -DisplayGroup "Domain Profile" -Enabled True |
Select-Object DisplayName, Direction, Action, Profile | Format-Table -AutoSizeRun on the target machine after a refresh. Confirms the GPO-deployed rules actually exist and are enabled for the expected profile — the evidence that the firewall policy applied.
15 · Deploy logon, logoff, startup, and shutdown scripts
Scripts are the workhorse of "do something at a defined moment," and there are two pairs with different contexts. Logon / Logoff scripts (User Configuration → Policies → Windows Settings → Scripts) run in the user's security context at logon and logoff. Startup / Shutdown scripts (Computer Configuration → … → Scripts) run in the computer's context (effectively the local system) at boot and shutdown. That context difference is decisive: a logon script can drop per-user files or run a per-user agent; a startup script can do machine-wide housekeeping that shouldn't depend on who logs on. Put a script in the wrong pair and it either runs with the wrong identity or at the wrong time — the most common symptom being "the script ran but couldn't write to the place I expected," which is almost always a context/permissions mismatch.
Three practical requirements make scripts reliable. Location and access: scripts typically live on a file share (historically the NETLOGON share or a dedicated admin share) and must be readable by the accounts that run them; a logon script on a share the user can't reach simply won't run, and a slow share makes logon crawl. Path and arguments: the script entry is a path plus optional arguments, and relative assumptions break — use paths that resolve for the running context. Logging: a script that fails silently is undiagnosable, so write output to a per-machine log file (and, where relevant, an Event Log entry) so that "did it run, and what did it see?" has an answer. These three — reachable location, correct context, and a log — account for the vast majority of "my script doesn't work" problems.
Test the way scripts actually behave: on a test machine in a test OU, run gpupdate /force, then log off and back on (logon scripts don't run on a plain refresh — they run at the next logon), and check the log file. For startup scripts, a restart is the honest test. Confirm the script ran as the right identity (the log should show who ran it and what it could access). Rollback is removing the script entry from the GPO (the script file can stay on the share). Because scripts run code at scale, the same caution as everywhere else applies: review what the script does before it runs on many machines, and scope new scripts to a test OU first — a script that works on one machine but writes to a fixed path can collide when it runs on fifty at once.
16 · Back up, restore, import, and document Group Policy Objects
Group Policy is configuration, and configuration changes need change control. The backup story has two granularities: per-GPO (right-click a GPO in the GPMC → Backup, to a folder you control) and all-GPO (back up the whole domain's GPOs in one operation). A backup captures the GPO's settings and structure to a portable folder — it does not capture the live links or the AD object in a way you can "just drop back," which is why restore is a deliberate re-creation: you restore a backed-up GPO to a domain, and it comes back as (or over) a GPO with its settings, after which you re-verify its links and permissions. The discipline is: back up before you change, keep the backup in a location that survives the domain (a file share or off-DC storage, not only on the DC), and test that a restore actually works before you need it.
Import vs restore are related but different. Restore puts a backed-up GPO back into a domain (by GUID or name). Import brings a GPO's contents into a different existing GPO — the standard tool for migration (moving a GPO to a new domain or a renamed GPO) and for merging settings. Migration is where documentation and a tested import matter most, because a GPO that references share paths, group names, or software that differ between environments won't behave identically on import — you need to know what it references. This is also why documenting each GPO (owner, purpose, scope/links, last change, and its backup location) is not bureaucracy: when you're restoring or migrating under pressure, the note that says "this GPO links to three OUs and references \\file01\appshare" is the difference between a clean recovery and an hour of reverse-engineering.
A minimal, repeatable change-control loop: (1) back up the GPO you're about to touch (and note the backup path); (2) make the change in a test-scoped way where possible; (3) verify on a test object; (4) update the GPO's documentation (what changed, when, who); (5) keep the pre-change backup until you're confident. For restores, the safe test is to restore the backup to a test GPO or a lab domain and compare its settings to what you expect, rather than restoring straight over production on a hunch. Treat the backup like a rollback point you may have to use — because in a mis-scoped domain-wide change, it's the thing that gets you home.
Backup-GPO -AllGPOs -Path "\\file01\gpo-backups\2024-06"
Restore-GPO -BackupGPOName "SG-Win10-Baseline" -TargetDomain "contoso.test"Backup-GPO writes to the path you specify; Restore-GPO recreates the named GPO in the target domain. After a restore, re-check the GPO's links and scope — the backup preserves settings, not necessarily the live link configuration.
Module 3 · Which applies
Diagnosing which policies apply
Tutorials 17–24 are the analytical core: a repeatable method for determining the effective policy for any target, and a precise understanding of the mechanisms that decide inclusion and exclusion — security filtering, WMI filters, inheritance, enforcement, loopback, permissions, and the user/computer split. These are the concepts that turn "it's not applying" from a mystery into a list of checkable hypotheses.
17 · Determine which GPO applies to a user or computer
Make "which GPO applies" a repeatable procedure rather than a vibe, and it stops being the hardest question in the domain. The process has four questions in order, each with a specific tool. (1) Who is the target, and where is it? Identify the exact computer object and user object, and their OU paths (dsquery/dsget, or the ADUC). (2) Which GPOs are linked in its path? For the computer, every GPO linked to the domain, its site, and each OU from the root down to the computer's OU (and inherited). (3) Of those, which pass the filters? Security filtering (does the target's group have Read + Apply?) and WMI filters (does the target match the query?). (4) What's the effective result? The last-processed setting per LSDOU, adjusted for enforcement — which is exactly what gpresult computes for you.
gpresult /scope computer /v
gpresult /h C:\temp\gpc.html /f
Get-GPLink "OU=Sales,DC=contoso,DC=test"gpresult /v on the target is the authoritative "what applied and what was denied, and why." Get-GPLink lists what's linked at a container (run where the AD module is available). The HTML report is the most readable form for a human.
The output you're looking for in gpresult is two lists: Applied Group Policy (the GPOs that took effect) and Denied Group Policy (the GPOs that were in the target's scope but were excluded, each with a reason — "Security Filtering," "WMI Filter," or "Computer/User not in scope"). That denied list with reasons is the single most useful artifact in Group Policy troubleshooting, because it converts "why didn't it apply?" into a named cause you can act on. The habit to build: when someone says a policy isn't applying, your first move is to generate the report on the affected target and read the denied list — not to start editing the GPO. The rest of this module is, in effect, a catalog of the reasons that show up in that list and what to do about each.
18 · Security filtering: why a GPO applies to some users but not others
Security filtering is the permissions gate on a GPO, and it's the most common reason a GPO "applies to some but not others." By default, a new GPO has Authenticated Users with Read and Apply Group Policy — so it applies to everyone. The moment you change that list, you start excluding people. Two permissions matter, and they're different: Read lets the target read the policy, and Apply Group Policy (a write permission) lets it be applied. To apply to a target, the target (or a group it's a member of) needs both. A classic failure: you remove Authenticated Users and add a group with Read only — the group can read the GPO but it isn't applied, so it shows in the denied list. Or the target simply isn't a member of any group that has the rights.
The diagnostic signature is specific, which is what makes it tractable: in the target's gpresult, the GPO appears under Denied Group Policy with the reason "Security Filtering". That single line tells you the GPO was in scope but the target lacked the rights — so the fix is a permissions fix, not a settings fix. Confirm the target's group membership (is it actually in the group you think?), then check the GPO's Scope tab / security descriptor (which groups have Read and which have Apply). The correction is to grant the intended group Read and Apply Group Policy on the GPO (in the GPMC Scope tab, check Authenticating Users handling carefully, or add the specific group with both rights). Then re-run gpupdate /force on the target and confirm the GPO moved from Denied to Applied.
One nuance prevents a whole class of confusion: security filtering is evaluated against the security principal — for computer settings, the computer's account and its groups; for user settings, the user's account and its groups. So "the user is in the group" isn't enough for a computer-scoped setting; the computer (or its groups) must have the rights. When a GPO with both computer and user settings behaves inconsistently, check each side's filtering separately. And keep the default in mind as your mental model: a GPO you haven't touched applies to everyone; a GPO that suddenly applies to fewer people almost always means someone edited that list, and the denied-reason in the report will point straight at it.
$acl = Get-Acl (Get-ADObject -Identity "CN=SG-Kiosk,DC=contoso,DC=test").LDAPDisplayName
Get-ADObject -Identity "CN=SG-Kiosk,DC=contoso,DC=test" |
Get-Acl | Select-Object -ExpandProperty Access |
Where-Object { $_.IdentityReference -like "*Kiosk*" -or $_.IdentityReference -like "*Authenticated*" }Shows which principals hold which rights on the GPO object, so you can see who has Read vs Apply. The exact AD path of the GPO object varies; confirm it first. The point is to read the actual ACL rather than assume the Scope tab's display.
19 · WMI filters: target devices using verified conditions
A WMI filter targets a GPO by a WQL query evaluated against the computer — things like OS version, whether it's a 64-bit system, free disk space, or a specific hardware attribute. If the filter evaluates to false for a computer, the GPO doesn't apply to that computer (and, importantly, WMI filters are evaluated in the computer's context even for the GPO's user settings — a filter on "is this a Windows 10 machine" gates the user side of the GPO by the machine it's running on). This makes WMI filters powerful for "apply only to this class of device," but it also means a subtly-wrong query silently excludes machines, and a query that's expensive to evaluate slows down policy processing.
Two things separate a WMI-filter problem from a permissions problem, and you should learn to tell them apart. First, the signature: a GPO excluded by a WMI filter shows in gpresult denied list with the reason "WMI Filter", whereas a security-filtering failure says "Security Filtering" — different reasons, different fixes. Second, the test: you can evaluate the query directly against a machine (the WMI Query Language can be run via wmic or PowerShell Get-CimInstance with the same query) to see whether the machine actually matches. If the query returns no rows on a machine you expect to be targeted, the query is wrong (a version-string mismatch, a wrong class, a typo) — that's a query bug, not a rights bug.
Performance is the reason to use WMI filters deliberately, not by default. Every WMI filter on a linked GPO is evaluated during processing, and there's a cap on how many filters will be evaluated per refresh (beyond it, GPOs with extra filters are skipped) — so a domain with dozens of GPOs each carrying a WMI filter is a slow, and eventually silently-excluding, environment. The guidance: prefer OU structure and security filtering for population targeting (they're free to evaluate), and reserve WMI filters for conditions that genuinely can't be expressed by structure or group membership (a property of the machine rather than its AD location or group). When you do use one, keep the query simple and tested, and remember the denied-reason + direct-query test from above is how you prove whether a machine is being filtered out.
| Aspect | Security filtering | WMI filter |
|---|---|---|
| Basis | Permissions (Read + Apply) on the GPO | A WQL query evaluated on the computer |
| Targeted by | Group membership / principals | A property of the machine (OS, hardware, etc.) |
| Evaluated in context of | The target (computer or user) | The computer (even for user settings) |
| Denial reason in gpresult | "Security Filtering" | "WMI Filter" |
| Cost / default use | Cheap — prefer for populations | Has evaluation cost + a cap — use for machine properties |
20 · GPO inheritance and Block Inheritance explained
By default, a GPO linked to a parent container inherits down to every child container: a GPO on the domain applies to every OU unless something stops it. This is both the feature (link once at a high level, cover everything below) and a recurring source of surprise (a child "inherited" a setting nobody intended to be there). Block Inheritance is a checkbox on a container (in the GPMC, on the OU's Group Policy tab) that tells that container to stop inheriting GPOs from its parent containers. The critical, frequently-missed limits: Block Inheritance does not block domain-level GPOs (domain GPOs always apply regardless), and it does not block Enforced links (an enforced GPO overrides a block). So "I blocked inheritance" is not the same as "no parent policy applies here" — it's "no inherited, non-domain, non-enforced policy applies here."
The practical effect of a block is that the blocked OU is governed only by (a) GPOs linked directly to it, (b) domain GPOs, and (c) any enforced GPOs above it. Teams use Block Inheritance to carve out a special OU (a lab, a specific server tier, a kiosk pool) from a broad set of inherited user policies. The diagnostic value: when a machine in a certain OU is missing a setting that every other machine has, "is Block Inheritance on this OU or an ancestor?" is a fast, definitive check. You can see it in the GPMC (the OU's Group Policy tab) or with Get-GPInheritanceBlock — and the fix is to unblock, or to re-link the needed GPO directly to the OU, depending on the intent.
Because a block changes what an entire subtree receives, treat it like any scope change: state what will stop applying where, test on a machine in that OU, and document why the block exists (so a future admin doesn't remove it by mistake, or — worse — add it without understanding the domain-GPO/enforced exceptions). The mental model to keep: inheritance is the default flow; a block is a dam with known holes (domain + enforced); and the effective policy for any object is what flows past all the dams on its path. That's the framing Module 4 uses when a "should be inherited" setting is missing.
Get-GPInheritanceBlock "OU=Kiosk-Pool,DC=contoso,DC=test"Returns whether the specified container has inheritance blocked. Check the container itself and its ancestors, since a block at any level on the path affects what reaches the object.
21 · Enforced GPO links and link order
Two levers control precedence within the LSDOU framework, and together they decide the effective result when GPOs set the same thing. Link order is the sequence of GPOs linked to a single container (the GPMC Link Order list) — processed top-to-bottom, so the one lower in the list is processed later and, for a conflicting setting, generally wins. Enforced (the No Override / Enforced checkbox on a link) is a stronger statement: an enforced GPO's settings are applied after all non-enforced GPOs at its level and override conflicting settings from lower levels. The combined effect: within a container, non-enforced GPOs run in link order, and then enforced GPOs run and take precedence over the non-enforced results (including, crucially, over GPOs linked at lower AD levels that would normally be processed later).
This is where "last wins" needs its caveat made concrete. In pure LSDOU with no enforcement, an OU GPO beats a domain GPO. But if the domain GPO is enforced, it beats the OU GPO despite being processed "earlier" in the level order — because enforcement reorders things so enforced settings land last. So the question "which GPO controls this setting?" has a three-part answer: (1) which GPOs actually configure it, (2) their relative level and link order, and (3) which of them are enforced. Reasoning about effective configuration means walking those three, which is exactly what a gpresult /v report's per-setting "defined in" / "applied from" lines show you — the report tells you not just the value but which GPO it came from, which is how you confirm your precedence reasoning against reality.
| Mechanism | What it controls | Key behavior |
|---|---|---|
| LSDOU level order | Local → Site → Domain → OU | OU typically processed last (highest normal precedence) |
| Link order | Order of GPOs on one container | Lower in the list processed later; later generally wins per setting |
| Inheritance | Parent → child flow | Child receives parent GPOs unless blocked |
| Block Inheritance | Stops inherited flow at a container | Does not block domain GPOs or enforced links |
| Enforced link | Overrides lower-level conflicts | Enforced settings applied last; beat non-enforced lower levels |
Use enforcement intentionally, because it's the tool that lets a higher-level policy win where you'd otherwise need to fight the OU. Typical legitimate uses: a domain security baseline that must not be overridden by any OU, or a compliance GPO that takes precedence everywhere. The risk is the same as with any broad power — an enforced GPO is hard for downstream admins to see "winning," so when a lower-level team sets a value and it silently doesn't stick, an enforced GPO higher up is a prime suspect. Verify with the report (the setting's "defined in" line names the controlling GPO) before assuming the lower-level edit is broken. Rollback for an unwanted enforcement is simply clearing the Enforced checkbox — low-risk and immediate.
22 · Group Policy Loopback Processing: Merge vs. Replace
Loopback processing solves a specific problem: applying user settings based on the computer the user logs onto, rather than the user's own AD location. Normally, user GPOs follow the user (wherever they log in, they get their user policy). On shared or kiosk machines, you often want the opposite: the machine's context should determine the user experience (every user at a kiosk gets the kiosk's locked-down desktop, regardless of who they are). Loopback, enabled in a GPO's user-configuration Computer Settings ("Configure user Group Policy loopback processing mode"), tells the computer to apply user settings from the GPOs in the computer's scope at logon.
The two modes are the crux, and they behave very differently. Merge: the user's normal user GPOs and the computer-scope user settings from loopback are both processed, and per setting the last-processed wins — so it's a combination, and a user's own settings can still influence the result. Replace: the user's own user GPOs are ignored for this logon, and only the loopback (computer-scope) user settings apply — a hard, machine-defined experience. Choose Replace for true kiosk/shared machines where the machine fully defines the session, and Merge when you want the machine to add to or override the user's normal settings without discarding them. Getting the mode wrong is a common "why do kiosk users still see their personal settings?" (you used Merge) or "why did kiosk users lose settings they need?" (you used Replace) bug.
Because loopback inverts the normal user/computer relationship, it's also a frequent source of the "applies to the wrong people" confusion in Module 5: a user who normally gets policy A from their own OU can, on a loopback machine, get policy B defined by the machine's OU instead. When diagnosing, first establish where the user logged on and whether that computer has loopback enabled, because that changes which user policy is in play entirely. Verify the effective result with gpresult on the shared machine while logged in as the test user — the report will reflect the loopback-processed user settings. Rollback is simply disabling loopback (set the mode back to Not Configured), which returns user policy to following the user.
23 · GPO permissions and delegation: Read, Edit, and Apply
Group Policy has two different kinds of permission that get conflated, and separating them is the key to safe, least-privilege administration. Administrative permissions are the rights to change a GPO — edit its settings, manage its links, back it up. These are the ACLs on the GPO object itself (the "Modify"/"Write" side), and they're what you delegate to a team that should be able to manage some GPOs without being a full domain admin. Application permissions are the Read + Apply Group Policy rights that determine who the GPO applies to (security filtering, Tutorial 18) — these are on the target side, not the admin side. "Can this person edit the GPO?" and "does this GPO apply to this user?" are two different ACL questions with two different answers, and mixing them up is how you either over-grant admin rights or accidentally change who a policy reaches.
Delegation in practice means: give a team the least administrative rights that let them do their job. A support team that manages "desktop experience" GPOs should get edit rights on those specific GPOs (and perhaps the ability to create GPOs in a designated container), not domain-wide GPO management and not the ability to touch the Default Domain Policy. In the GPMC, right-click a GPO → Delegation → Delegation of Control to grant specific permissions to a group; in PowerShell, Add-GPOWmiFilter-adjacent ACL cmdlets or direct AD ACL edits achieve the same. The discipline: scope the delegation to named GPOs or a container, use a dedicated security group for the team (so you grant the group, not individuals, and can add/remove members without re-doing ACLs), and never delegate "full control" broadly — the combination of edit rights plus link rights plus the ability to change security filtering is effectively "can change what applies to anyone," which is a powerful grant to give narrowly.
The audit question to keep askable: for any GPO, who can edit it, who can link/unlink it, and who does it apply to? Those three should each have a named, intentional answer. When you inherit a domain, a quick pass over the high-impact GPOs (domain-linked, enforced, or touching authentication/firewall) to confirm their administrative ACLs match intent is worthwhile — an orphaned GPO with a departed admin's individual account as its only editor is both a maintenance and a security problem. And remember the application side is separately auditable: the same report that shows who a GPO applies to (its security filtering) is distinct from who can edit it, so a "review GPO permissions" task should deliberately check both dimensions.
24 · Why user and computer policies behave differently
This is the conceptual payoff of Tutorial 7, stated as a diagnostic principle: computer policy is decided by the computer's AD location and processed at startup; user policy is decided by the user's AD location and processed at logon. They travel on different "rails." A user who logs onto a computer in a different OU than their own gets that computer's computer-policy (from the computer's OU path) but their own user-policy (from the user's OU path) — unless loopback is in play (Tutorial 22). This single fact explains a large family of confusing behaviors: "my settings are right on my office PC but different at home," "the server got a user setting it shouldn't have," and "why does this machine's policy not match its neighbors?" — usually because you were looking at one rail while the symptom was on the other.
The timing difference is the second half. Computer settings apply at startup (and the computer's background refresh), so a change to a computer GPO may not be visible until the machine restarts or the computer refresh runs — a plain gpupdate /force re-runs computer processing, but some computer settings genuinely only take effect at boot. User settings apply at logon (and the user refresh), so a user GPO change typically needs a logoff/logon to fully materialize. When someone reports "I refreshed but it didn't change," the first question is which side: if it's a user setting, did they log off and back on? If it's a computer setting that requires boot, did the machine restart? Matching the change to the right processing event is half the answer.
Turn this into a habit: whenever a policy behaves unexpectedly, explicitly name which object (the computer or the user) the setting is about, where that object sits in AD, and when it last processed. Those three facts pin down the rail, the scope, and the timing — and they're all directly observable (the object's OU path, the GPO's section, and the last-processed timestamps in the event log / gpresult). Most "user vs computer" mysteries resolve the moment you stop assuming the user's location and the computer's location are the same place, because in a roaming or heterogeneous environment, they almost never are.
Module 4 · Not applying
Troubleshooting policies that don't apply
Tutorials 25–32 are the field manual. The through-line is evidence over guessing: every diagnosis starts from what the tools actually report (gpresult, the event log, replication state) and treats likely causes as hypotheses to be confirmed. Tutorial 25 gives the complete workflow; the rest drill into the specific failure classes — refresh limits, report reading, RSoP vs modeling, filtering, scope, connectivity, and logs.
25 · Troubleshoot a GPO that does not apply: a complete diagnostic workflow
Here is the end-to-end workflow, built so each step produces evidence that either confirms the cause or eliminates a hypothesis — not a list of things to "try." It runs in a deliberate order from cheap/likely to expensive/rare, and it ends at a verified root cause, not a guess.
- Pin down the exact symptom and target. Which GPO, which setting, which computer and which user, and where does the setting live (computer vs user configuration)? Capture the target's exact object paths. If "it's not applying" is vague, make it specific — a named GPO, a named setting, a named target.
- Confirm the target's location and the GPO's link. Is the target actually in the OU (or an inheriting child) the GPO is linked to? Is the GPO linked at all, and at the level you think? (Get-GPLink, the object's path.)
- Read the report's denied list. On the target, gpresult /h /f. Is the GPO in Applied (then the problem is a conflicting/later GPO — go to the precedence checks) or Denied? If denied, the reason (Security Filtering / WMI Filter / not in scope) points straight at the next step.
- Eliminate inheritance blockers. Is Block Inheritance on the target's OU or an ancestor? Is a competing GPO enforced or later in order, overriding this one?
- Check the plumbing if scope looks right. Can the target reach a DC (DNS)? Is the GPO's SYSVOL files present and current on the DC it contacted (replication)? Any slow-link or processing errors in the GroupPolicy event log?
- Force a clean re-process and re-verify. gpupdate /force, then re-read the report. If still wrong, the event log and (for connectivity) the DC side are where the cause now lives.
The table below is the same workflow as a symptom → evidence → action map, which is how to use it under time pressure: match the observed symptom, gather the named evidence, take the named action. Note the recurring theme — the gpresult denied-reason and the event log do the diagnosing; your job is to read them and act on what they say.
| Symptom | Likely causes (hypotheses) | Evidence to gather | Action |
|---|---|---|---|
| GPO in "Denied", reason "Security Filtering" | Target/group lacks Read + Apply | gpresult reason; GPO ACL; target group membership | Grant Read + Apply to the intended group |
| GPO in "Denied", reason "WMI Filter" | Query false on this machine | gpresult reason; evaluate the WQL on the machine | Fix the query or re-target by OU/group |
| GPO not in Applied or Denied at all | Not linked / wrong OU / not in scope | Get-GPLink; object's OU path; inheritance | Link to the correct container; fix placement |
| GPO applied but setting is "wrong" | Conflicting/enforced/later GPO overrides | gpresult /v per-setting "defined in" | Adjust link order, enforcement, or the setting |
| Nothing changes after gpupdate /force | Setting needs restart/logon; or plumbing | Setting type; event log; DC reachability | Restart/logon; check DNS, SYSVOL, replication |
| Works on some DCs, not others / stale | Replication or SYSVOL out of sync | repadmin/DFS state; gpt.ini version on each DC | Force/verify replication; fix SYSVOL |
26 · Use gpupdate correctly: refresh, force, and its limits
gpupdate triggers a policy refresh on demand instead of waiting for the background schedule. Plain gpupdate re-processes policy that's due; gpupdate /force re-processes everything, including GPOs whose version stamp hasn't changed, which is what you want when you've changed a GPO and want the target to pick it up now. It also runs in foreground, so you see it complete (and its errors) in the console rather than it happening silently in the background. That makes /force the right tool during active troubleshooting: it's immediate, visible, and repeatable.
But gpupdate /force is not a universal fix, and believing it is a classic misdiagnosis. Three honest limits. First, some settings only apply at a specific event: many user settings need a logoff/logon, and some computer settings need a restart, to fully take effect — a force-refresh re-runs processing but won't, for example, re-run a startup script or re-apply a setting that's boot-only. Second, it only helps if the policy is actually in scope and reachable: if the GPO is denied by filtering, or the target can't reach a DC, or the files haven't replicated, forcing a refresh just re-confirms the same "not applied" result faster. Third, it changes nothing about precedence: if a later or enforced GPO legitimately overrides the one you edited, /force will faithfully apply the overriding value. So the correct mental model is: gpupdate /force is a re-test tool, not a repair tool — you use it to see the current effective result after you've made or suspected a change, and if the result is still wrong, the cause is upstream (scope, filtering, plumbing, or precedence), and you go find it.
gpupdate /force
gpresult /h C:\temp\after.html /fForce the refresh, then immediately capture a fresh report. Compare before/after reports to see exactly what changed — if the setting you expected didn't move, the problem isn't "it needs a refresh," it's scope, filtering, plumbing, or precedence.
27 · Generate and interpret gpresult HTML reports
The gpresult HTML report is the single most useful artifact in this entire series, so learn to read it deliberately. Generate it on the target with gpresult /h report.html /f (the /f overwrites an existing file). The report has several regions that answer different questions: the headers tell you the computer name, the domain, the DC it contacted, and — crucially — the site and the logon user. The Applied Group Policy list is the GPOs that took effect, in order. The Denied Group Policy list is the GPOs that were in scope but excluded, each with a reason. And the verbose setting sections show, for individual settings, the value and which GPO defined it.
Read it in a specific order to avoid being overwhelmed. (1) Headers first — is it talking to the DC you expect, in the site you expect? A wrong site or an unexpected DC can explain a lot (roaming, replication lag). (2) Applied vs Denied — is your GPO applied (then the issue is precedence/conflict, and you read the per-setting "defined in"), or denied (then the reason is your next step: Security Filtering → Tutorial 29; WMI Filter → Tutorial 19; not-in-scope → Tutorial 30)? (3) The specific setting — for the exact setting that's wrong, find its line and note which GPO it came from; that names the controller. The discipline is to trust the report over the memory: "I'm sure I linked it" is less useful than the report's statement of what actually applied and why not.
Two interpretation cautions keep you from misreading. First, "Denied" is not "broken" — a GPO is denied for legitimate reasons all the time (it was never meant for this target); denied is just "in scope but excluded," and the reason tells you whether that's intended or a bug. Second, the report is a snapshot of the last successful processing — if the target hasn't refreshed since your change, the report shows the old state, which is why you pair it with gpupdate /force (Tutorial 26) when actively debugging. Used that way — force, then report, then read the denied reasons and the per-setting source — gpresult converts almost every "it's not applying" into a named, actionable cause.
gpresult /h C:\temp\gpo-report.html /f
gpresult /scope user /vThe HTML report is for human reading (open in a browser); /scope user /v targets the user side specifically. Use /scope computer for the machine side. Capture both when a problem spans user and computer settings.
28 · Use Resultant Set of Policy and Group Policy Modeling
There are two "what's the effective policy?" tools, and they answer different questions — knowing which one you need prevents a lot of confusion. Resultant Set of Policy (RSoP) — rsop.msc, or the effective-set view of gpresult — answers "what is actually applied to this real user/computer right now?" It's observational: it reads the live, processed result on a specific object. It's the tool for diagnosis ("why does this machine have this setting?"). Group Policy Modeling — the GPMC's Group Policy Modeling Wizard — answers "what would apply to user X / computer Y if they were here?" It's a simulation: you pick a target (even one that doesn't exist yet) and it walks the scope, filtering, and precedence to predict the result without touching a live machine.
Use each where it's strong. Reach for RSoP / gpresult when you have a real, affected object and need ground truth — it reflects reality including the quirks (a machine that's actually in a different OU than you assumed, a filter that actually evaluated false). Reach for Modeling when you're planning — "before I link this GPO to the domain, what would it do to a standard user in Sales?" — or when you can't easily get on the affected machine. Modeling is also excellent for testing the effect of a change in your head before making it: model the current state, model the proposed state, and compare. The limitation to respect: a simulation is only as good as its inputs and its model of the environment; if the real machine's actual location, membership, or WMI state differs from what you told the wizard, the prediction won't match reality. So for a live problem, confirm with RSoP/gpresult on the actual object; for a planned change, start with Modeling and then verify on a test object after you deploy.
The pairing is the workflow: Model to plan, RSoP to verify. Before a broad change, model it to predict the blast radius and catch surprises (an unintended group, an unexpected override). After you deploy to a test scope, use RSoP/gpresult on a real test object to confirm the prediction held. When the two disagree, that disagreement is itself diagnostic — it means the real environment differs from your model in a way worth finding (usually object placement or a filter). This is the same evidence-over-assumption principle as the rest of Module 4, applied to the "what would happen" question instead of the "what happened" question.
29 · Troubleshoot security filtering and access-denied errors
This is the focused repair path for the single most common "applies to some, not others" cause, using evidence rather than trial-and-error. The trigger is specific: the target's gpresult shows the GPO in Denied Group Policy with the reason "Security Filtering." That reason means the GPO was in the target's scope but the target lacked the rights to apply it — so you're not going to fix this by editing settings; you're going to fix it by fixing permissions or membership. The whole diagnosis is three confirmations, each with a tool.
Confirmation 1 — is the target actually in the group you think it is? Security filtering works through group membership (the target or its groups need Read + Apply). Check the target's real group membership (for a user, their groups; for a computer setting, the computer's groups — don't assume the user's groups cover a computer-scoped setting). A "missing" apply is often a target that's simply not in the intended group, or was removed from it. Confirmation 2 — does the group actually have both Read and Apply? Read the GPO's security descriptor / Scope tab. The classic bug is a group granted Read only — visible, readable, but not applied. Confirmation 3 — is there a conflicting deny or a more-specific entry? Occasionally an explicit deny or an unexpected principal ordering causes the failure even when the group "should" have rights; reading the actual ACL (not just the Scope tab's summary) surfaces this.
The repair, in the order of least to most invasive: if the target just isn't in the group, add it to the group (often the real fix — the GPO was right, the membership was wrong). If the group lacks Apply, grant Read + Apply Group Policy to the intended group on the GPO. Then gpupdate /force on the target and re-read the report to confirm the GPO moved from Denied to Applied. Rollback is the reverse (remove the group, or the right). The lesson that generalizes: an access-denied on a GPO is a permissions/membership problem with a named, checkable cause — and the denied-reason plus the actual ACL and actual membership are the three pieces of evidence that pin it down without guessing.
30 · Diagnose broken links, incorrect OU placement, and scope problems
The "scope" failure class covers the cases where the GPO is fine and the permissions are fine, but the geometry is wrong: the GPO isn't linked where the target can see it, the target isn't where the GPO is linked, or an inheritance blocker sits between them. The diagnostic signature is that the GPO is absent from the target's report entirely — not in Applied, not in Denied — because it was never in the target's scope to begin with. (Contrast with Module 3's filtering failures, where the GPO is in scope but denied.) So the first move is to establish the geometry with two facts: the GPO's actual link location(s), and the target's actual location in the tree.
Walk the geometry deliberately. (a) Where is the GPO linked? Get-GPLink on candidate containers, or the GPMC, tells you the real link location(s) — sometimes a GPO is linked to a differently-named OU than the one you assumed, or it was unlinked, or it's linked but disabled. (b) Where is the target, really? Get the object's exact container path — the classic error is a computer in OU=Sales,OU=London while you think "Sales" means the top Sales OU, or an object still sitting in the default Computers container (which doesn't inherit from your management OUs). (c) Is anything between them blocking or overriding? Block Inheritance on an ancestor, or an enforced/later GPO, can make a correctly-scoped GPO not be the effective one. Match (a) and (b): if the GPO is linked to an OU that is not an ancestor of the target, the target can't see it — and the fix is either to move the target to the right OU, or to link the GPO to a container that is actually on the target's path (or to the target's own OU). Each fix has a rollback (move the object back, or remove the added link), and each is verifiable by re-reading the target's report to confirm the GPO now appears in scope.
Get-GPLink "OU=Sales,DC=contoso,DC=test"
dsquery computer -name "WS-Sales-01" -o | dsget computer -memberofThe first shows what's linked to a container; the second shows the computer's true container. Comparing the two reveals most "not in scope" problems: the link and the target simply aren't on the same path.
31 · Troubleshoot DNS, SYSVOL, replication, and DC connectivity
When scope and permissions all check out and a GPO still won't apply — or applies stale — the cause has moved from "policy logic" to "the client can't get the policy." This class has four distinct sub-problems, and the skill is telling them apart, because each has a different fix. (1) Name resolution / DC discovery: a client finds domain controllers via DNS SRV records (ldap._tcp.dc._msdcs.<domain>); if DNS is broken, the client can't find a DC at all and policy processing fails. (2) Network access to SYSVOL: even with a DC found, the client must read the GPO files from the SYSVOL/NETLOGON share; a blocked path or a permissions problem on the share stops file retrieval. (3) Replication: GPO metadata replicates via AD and GPO files replicate across SYSVOL (via DFS Replication in modern domains); if the DC the client contacted is lagging, it serves an older copy of the GPO, so the client applies stale settings. (4) Client-side processing: the client reached the DC and got the files but failed to process them (a corrupt local policy cache, a slow-link condition, a processing error) — visible in the event log.
Diagnose in that order, because each is cheaper and more common than the next. DNS first: can the client resolve the domain and locate a DC? (nltest /dsgetdc:<domain> reports which DC it finds and its status; a failure here is a DNS/DC problem, not a GPO problem.) Access second: can the client actually read the SYSVOL path (\\<domain>\SYSVOL) and the specific GPO folder? Replication third (on the DC side): is the GPO's gpt.ini version the same on the DC the client used as on the authoritative DC? A version mismatch means replication lag — repadmin / DFS diagnostics and, where appropriate, forcing replication resolve it. Client processing last: with DNS, access, and replication all confirmed, the GroupPolicy event log on the client is where a local processing failure (corrupt cache, slow-link, a specific error) will show, and clearing the local policy cache (%systemroot%\System32\GroupPolicy and the Registry gupdate keys, per Microsoft's documented procedure) plus a forced refresh is the documented recovery for a corrupted local cache. The through-line: confirm each layer before blaming the next — a "GPO not applying" that's really a DNS problem won't be fixed by touching the GPO at all.
nltest /dsgetdc:contoso.test
echo \\contoso.test\SYSVOL\contoso\Policies
repadmin /showrepl
repadmin /repsummarynltest confirms which DC the client can find; the SYSVOL path checks file reachability; repadmin (run on a DC) shows replication health and summary. Together they separate discovery, access, and replication failures from client processing failures.
32 · Read Group Policy event logs and diagnose conflicting settings
The client's GroupPolicy operational log (under Application and Services Logs → Microsoft → Windows → GroupPolicy → Operational) is the time-stamped record of what the client attempted, what succeeded, and what it skipped — and it's the authoritative source when the gpresult snapshot isn't enough. Rather than memorizing a list of event numbers (which vary by build), read the log by category: events indicating a policy applied successfully; events indicating a GPO was skipped because it was filtered (security or WMI); events indicating it was out of scope; and events indicating slow-link mode (where settings marked as slow-link-excluded are deferred). Each category maps to a different Module 3/4 cause, so the log is really just the denied-reason list from gpresult, with timestamps and more detail.
Use the log for two jobs that gpresult doesn't do as well. Timing: "when did this last process, and did it succeed then?" — the timestamps let you correlate a reported problem with a specific processing event (did the failure start after a change, after a DC failover, after a link was added?). Conflicting settings: when a setting has the "wrong" value, gpresult /v tells you which GPO defined it, and the log can confirm the sequence in which GPOs were processed — together they let you trace a specific value back to its controlling GPO and confirm whether that GPO is legitimately winning (later in order, or enforced) or whether your edit landed in a GPO that's being overridden. The discipline: for a conflicting setting, name the value you expect, name the value you see, and use the report + log to name the GPO that produced the value you see — that's the controller, and it's the thing to adjust (its order, its enforcement, or its setting).
A slow-link note, because it's a genuine, under-appreciated cause: Group Policy processing has a "slow link" threshold, and when a client determines it's on a slow connection, settings flagged as slow-link-excluded are not applied that cycle (they wait for a faster connection). On a genuinely slow or congested link, a GPO can look "broken" when it's actually being deferred by design — the log's slow-link events are how you confirm that. The corrective actions here are environmental (fix the link, or review which settings are marked slow-link-excluded) rather than a GPO edit. The overall habit: the event log turns "it's not applying" into a dated, categorized, evidence-backed statement — and matching that statement to the right Module 3/4 cause is what makes the diagnosis a verification, not a guess.
| Log finding (category) | What it indicates | Next diagnostic step |
|---|---|---|
| GPO applied successfully | Processing worked for that GPO | If a setting is still wrong, check for a later/enforced overriding GPO |
| GPO skipped — security filtered | Target lacks Read + Apply | Tutorial 29: verify membership and the GPO ACL |
| GPO skipped — WMI filtered | WQL false on this machine | Tutorial 19: evaluate the query on the machine |
| GPO not in scope | Not linked on the target's path | Tutorial 30: check link location vs target location |
| Slow-link mode | Slow-link-excluded settings deferred | Check the link / review slow-link-excluded settings |
| Processing error / cache issue | Local processing failed | Review the error; clear local policy cache per docs; force refresh |
Module 5 · Advanced & labs
Advanced administration, automation, and hands-on labs
Tutorials 33–40 pull the series together at operational scale: correcting mis-scoped policies, automating with PowerShell, building inventories and clean precedence, a reusable checklist, an enterprise structure design, and two complete hands-on labs (one to create and verify, one to break and repair) using the clearly-fictional contoso.test domain.
33 · Fix GPOs that apply to the wrong users or computers
"Applies to the wrong people" is almost always one of a small set of geometry or targeting errors, and each has a specific fix. Work through them as a checklist, because they stack: (1) Wrong link location — the GPO is linked to an OU broader or different than intended (a domain link when you meant an OU, or a parent OU that also contains people you didn't mean to include). Fix: move the link to the precise container, or split the GPO. (2) Wrong security filtering — the apply-permissions group is broader than the intended population (e.g., a group that includes more members than you realized). Fix: tighten the group or the permissions (Tutorial 29). (3) Wrong OU placement of targets — the people/computers you're trying to reach (or exclude) are in a different OU than assumed. Fix: move the objects, or re-link to match reality. (4) Inheritance you didn't account for — a parent GPO is reaching into this OU and its settings are combining with or overriding yours. Fix: re-order, enforce deliberately, or block where appropriate. (5) Loopback on a shared machine — user settings are coming from the machine's scope, not the user's (Tutorial 22), so "the user" is getting a different policy than their own OU would give. Fix: adjust the loopback mode or the machine-scoped user settings.
The method is the same evidence-first loop, applied to the population: take one affected target (someone who got a setting they shouldn't have) and one unaffected target (who should have but didn't), and for each, read the report to see which GPOs actually applied and why. The difference between the two targets usually names the cause immediately — one is in the OU/group, the other isn't; one has a filter matching, the other doesn't; one is on a loopback machine. Then apply the matching fix from the list above, scoped as narrowly as possible, and re-verify on both targets (the one that should now be excluded, and the one that should now be included). Because "wrong people" problems often reveal a design weakness (an OU that mixes populations that need different policy), the durable fix is frequently a structural one — a new OU or a dedicated security group — rather than a pile of ad-hoc filters, which is exactly the direction Module 5's design tutorial (38) takes.
34 · Manage Group Policy Objects with PowerShell
The GroupPolicy PowerShell module (available on domain controllers and on workstations with RSAT) turns the GPMC's click-workflow into scriptable, repeatable, auditable commands — which is what makes a large GPO estate manageable and automatable. The high-value commands cluster into five groups: inspect (Get-GPO, Get-GPLink, Get-GPOReport), create/modify (New-GPO, Rename-GPO, Set-GPLink, New-GPLink), scope control (Set-GPInheritanceBlock, Set-GPLink -Enforced, WMI filter cmdlets), backup/restore (Backup-GPO, Restore-GPO, Import-GPO), and reporting (Get-GPResultantSetOfPolicy, Get-GPOSimulatedGroupPolicy). The pattern to internalize: the same operation you did by clicking in the GPMC has a cmdlet, and scripting it means it's testable, reviewable, and re-runnable.
Use PowerShell where it earns its keep: repetition (link the same GPO to ten OUs), auditing (enumerate every GPO, its links, and its backup status — Tutorial 35), and idempotent change (a script that sets the desired state, safe to re-run). Keep the same safety discipline as the console work: script against a test OU first, dry-run by reading before writing (a Get-* before a Set-*/New-*), and keep the script itself versioned like the GPO it manages. A few cautions specific to automation: a New-GPLink to the wrong target is as instant and as broad as a click, so parameterize the target and validate it; Set-GPLink -Enforced is a powerful, easy-to-misuse flag, so gate it behind an explicit, reviewed parameter; and remember the module must be imported/available and you need the AD permissions to perform the operation — a script that "works" on your admin box may fail on a machine without the module or the rights, which is itself worth handling explicitly (test the precondition, then act).
| Cmdlet | Purpose | Typical use in this series |
|---|---|---|
| Get-GPO | List GPOs | Inventory (35), audit |
| Get-GPOReport | Export a GPO's settings (HTML/XML) | Document / compare a GPO |
| New-GPO / Rename-GPO | Create / rename a GPO | Safe creation (9), standardization |
| Get-GPLink / New-GPLink / Set-GPLink / Clear-GPLink | Read / add / change / remove links (incl. -Enforced, -LinkOrder) | Linking (10,11), precedence (21,36) |
| Get-GPInheritance / Set-GPInheritanceBlock | Read / set inheritance blocking | Inheritance (20,30) |
| Backup-GPO / Restore-GPO / Import-GPO | Back up / restore / import GPOs | Change control (16) |
| Get-GPResultantSetOfPolicy / Get-GPOSimulatedGroupPolicy | Actual RSoP / simulated modeling | Verification (17,28) |
Get-GPO -Domain "contoso.test" | Select-Object DisplayName, Owner, CreationTime |
Sort-Object DisplayName | Format-Table -AutoSize
Get-GPLink "OU=GP-Lab,DC=contoso,DC=test" | Format-ListRead-only starting point: enumerate the estate, then inspect one container's links. Replace the domain/OU with yours. This is the shape of an auditable, re-runnable inventory step.
35 · Inventory and audit domain Group Policy configurations
An unmanaged GPO estate rots silently: GPOs whose owner left, GPOs linked nowhere (orphaned), GPOs that duplicate each other, and GPOs with no backup. A repeatable inventory is the control that stops that, and it's a good first PowerShell project because it's read-only and immediately useful. The record you want for every GPO: its display name and GUID, its owner (and a named human owner, since the AD "owner" is often a stale admin account), its links (which containers, in what order, enforced or not), its security filtering (who it actually applies to), any WMI filter, and its last backup and backup location. Capture it with Get-GPO (name/owner), Get-GPLink (links), the GPO ACL (filtering), and your backup store's timestamps, into a single table you can diff over time.
Then audit for the specific failure patterns an inventory is meant to catch. Orphans: GPOs with no links — harmless but confusing; decide to delete or link them. Unowned / stale-owner: GPOs whose owner is a departed account — reassign a current owner. Overlap: two GPOs setting the same policy on the same scope — a precedence landmine (Tutorial 36). No backup: any GPO without a current backup is a single point of failure for a change you might need to roll back. Broad scope without review: domain-linked or enforced GPOs that no one can currently explain — these are the highest-risk items to document first. The output of the audit isn't a report for its own sake; it's a work list (reassign these owners, back up these, consolidate these, document these), and running the inventory on a schedule turns Group Policy from a pile of unknowns into a known, owned, backed-up set — which is the precondition for the safe, fast changes the rest of the series assumes.
Get-GPO -All -Domain "contoso.test" | ForEach-Object {
[pscustomobject]@{
Name = $_.DisplayName
Owner = $_.Owner
Links = (Get-GPLink $_.Guid).Count
}
} | Format-Table -AutoSizeProduces a per-GPO name/owner/link-count table — the skeleton of an inventory. GPOs with a link count of zero are your orphan candidates. Extend the columns (filtering, backup date) as the audit deepens.
36 · Detect conflicting settings and design effective policy precedence
Conflicts are inevitable in any real estate — multiple GPOs legitimately touch the same settings — so the goal isn't to eliminate them but to make the outcome predictable and explainable. Detection has a concrete method: pick a setting that's "wrong," and use gpresult /v to read the "defined in" line for that setting — that names the GPO that actually produced the value you see. Then list every GPO in the target's scope that also configures that setting (from their reports), and order them by the LSDOU + link-order + enforcement rules (Tutorial 21). The GPO that wins is your controller; the others are losers whose values are being overridden. Once you can name the controller and the reason it wins, the conflict is understood — and you can decide whether the winner is supposed to win.
Designing effective precedence is the durable fix, and it's a structuring decision, not a per-conflict hack. A few principles that keep precedence sane: fewer GPOs, each with a clear single purpose, beats many overlapping ones (consolidate GPOs that set the same scope's settings). Use link order deliberately so that, within a container, the intended winner is processed last — and document that order. Reserve enforcement for genuine must-win baselines (a domain security floor), because every enforced GPO is a silent override that downstream teams will hit and not understand. Prefer scope-by-structure (OUs, security groups) over scope-by-filter for populations, since structure is visible and cheap to evaluate. The test of a good precedence design is the same as everywhere in this series: for any setting on any target, you can state which GPO controls it and why in one sentence — and gpresult confirms it. When you can't, you've found a conflict that needs resolving, and the defined-in trace is how you find it.
37 · Build a repeatable Group Policy troubleshooting checklist
The whole of Module 4 compresses into a checklist you can run the same way every time, so that "troubleshoot a GPO" is a procedure with evidence gates rather than a sequence of hunches. The design principle: each step produces evidence that either confirms the root cause or eliminates a hypothesis, and you don't move to a fix until a cause is verified. The checklist below is written to be copied into your own runbook — the copy button gives you the text. Note the deliberate ordering (cheap/likely first) and the "record the evidence" note on each step, because the record is what turns a one-off fix into a diagnosis you can explain and repeat.
1. Name it: which GPO, which setting, which computer AND user. Record exact object paths.
2. Location: is the target in the linked OU (or an inheriting child)? (Get-GPLink + object path)
3. Report: gpresult /h /f on the target. Applied or Denied? Read the DENIED reason.
- "Security Filtering" -> check membership + GPO ACL (Read AND Apply)
- "WMI Filter" -> evaluate the WQL on the machine
- not in scope at all -> link location vs target location
4. Inheritance/enforcement: block on an ancestor? enforced or later GPO overriding?
5. If applied but wrong value: gpresult /v -> which GPO "defined in" this setting?
6. Plumbing (if scope is right): DNS/DC discovery (nltest), SYSVOL access, replication
(repadmin / gpt.ini version), then client event log (slow link / processing error).
7. Re-test: gpupdate /force, re-read report. Did the expected value change?
8. Record: the verified root cause + the fix + the evidence that confirms it.
Rollback for any change made: note it here before applying.Copy into your runbook. The gates are the point: don't skip from symptom to fix — the denied-reason and the defined-in trace are what make the cause a verification.
Two practices make the checklist stick. First, keep the "record the evidence" habit non-negotiable: a fix you can't show evidence for is a guess, and the next time the same symptom appears you'll start from zero. The evidence is cheap (a saved report, a command output) and it's what lets you say "this was a security-filtering gap, confirmed by the denied reason and the ACL," rather than "I added the group and it worked." Second, treat the checklist as a loop, not a ladder: step 3's denied-reason often jumps you straight to the relevant sub-procedure (29, 19, or 30), you resolve it, and you return to step 7 to confirm. That "act, then re-verify" rhythm — make the change, force a refresh, re-read the report — is the same verify-loop from Tutorial 9, now generalized into a repeatable diagnostic discipline.
38 · Design a secure, maintainable enterprise GPO structure
A GPO estate that's easy to operate is designed to be, not one that accumulated. The components of a maintainable design: Naming standards — a consistent scheme (a common pattern is a prefix by purpose plus scope, e.g. SG- security, WG- workstation, plus a short descriptor) so a GPO's name tells you its intent and rough scope at a glance, and so the inventory (Tutorial 35) is readable. Separation of duties — the people who author a GPO are not necessarily the only ones who can see what it does; use delegation (Tutorial 23) so a team manages their GPOs without domain-admin rights, and so a change requires the right pair of hands, not just one. OU design for targeting — structure OUs so that the population a policy should reach is a natural container, which makes links precise and inheritance predictable (and makes the "wrong people" problems of Tutorial 33 rarer by construction).
The operational controls are what keep the design from decaying. Change management: a defined path for a GPO change — propose, back up (Tutorial 16), test in a scope, deploy, verify, document — so that no change reaches a broad scope untested and unbacked. Testing: a standing test OU (and ideally a lab domain) where every new or changed GPO is proven before production, exactly the discipline from Tutorial 9, promoted to policy. Rollback: because every change has a backup and a documented before-state, rolling back is a known, fast operation rather than a fire-fighting session. Review cadence: a scheduled inventory + audit (Tutorial 35) and a periodic precedence review (Tutorial 36) so orphans, stale owners, and new conflicts get caught while they're small. The measurable goal of all of it is the same sentence from the whole series: for any setting on any target, you can name the controlling GPO and why — a design that makes that true by default is a maintainable one.
The one-sentence test. If you can't answer "which GPO controls this setting on this machine, and why?" in one sentence — confirmed by gpresult — the structure (or that GPO) needs work. Every practice in this tutorial exists to make that answer easy, fast, and reliable.
39 · Hands-on lab: create, link, apply, and verify a GPO
This lab runs the full happy path end to end in a safe, isolated scope, so you experience the create → link → configure → verify loop with real evidence. Scenario: in the fictional contoso.test domain, you need a small set of desktop restrictions applied to a pilot group of standard users. Prerequisites (all fictional — substitute your own): a domain controller with the GPMC/GroupPolicy module, an OU OU=GP-Lab,DC=contoso,DC=test, at least one test computer object and one test user object in that OU, and a domain admin account to author the GPO. Nothing here touches production populations.
Steps. (1) Create the GPO: New-GPO -Name "WG-GP-Lab-Desktop" -Domain "contoso.test". (2) Link it to the test OU: New-GPLink -Name "WG-GP-Lab-Desktop" -Target "OU=GP-Lab,DC=contoso,DC=test". (3) Configure one benign user restriction (for example, prevent access to the Control Panel, set to Enabled) — deliberately one setting so the effect is unambiguous. (4) On the test computer, gpupdate /force. (5) Log on as the test user and confirm the restriction is enforced. (6) Generate gpresult /h /f and confirm the GPO is in Applied Group Policy and the setting shows the expected value. Expected result: the single restriction is in effect for the test user, the GPO appears as applied, and no other setting changed. Failure condition to recognize: if the GPO shows as Denied (not applied), you've hit a Module 3 cause (most likely the test user not actually in the OU, or a security-filtering default you changed) — that's the lab working as intended, and you now debug it with Module 4. Cleanup: Clear-GPLink on the OU, then Remove-GPO, confirming with Get-GPO that it's gone. The cleanup matters as much as the build — leaving a lab GPO linked is exactly the kind of orphan the inventory (Tutorial 35) exists to catch.
| Check | Expected (success) | If it fails, it points to |
|---|---|---|
| gpresult: GPO present | In "Applied Group Policy" | Module 3 scope / filtering (Tutorial 17, 29, 30) |
| The single restriction | Enforced for the test user at logon | Wrong section (user vs computer) / needs logon |
| Other settings | Unchanged | Over-broad edit / wrong GPO |
| Cleanup | GPO gone from Get-GPO, link cleared | Incomplete cleanup (orphan risk) |
40 · Hands-on lab: diagnose and repair a GPO that does not apply
The second lab is the diagnostic one: you deliberately introduce a controlled failure, then use the Module 4 workflow to find and fix it from evidence — the closest thing to a real incident you can practice safely. Scenario (fictional contoso.test): a GPO WG-GP-Lab-Desktop (from Lab 1) "should" apply to a pilot user in OU=GP-Lab, but it isn't. You'll introduce one of three controlled failures, diagnose which it is without being told, repair it, and re-verify. The three are chosen because they're the three most common real causes and each has a distinct signature.
Choose one failure to introduce (and keep it secret from yourself — diagnose it): (A) Security filtering — remove the pilot user's group from the GPO's Apply rights (or remove the group from the user). Signature: GPO in Denied with reason "Security Filtering." Fix: restore the group's Read + Apply (or re-add the user to the group) — Tutorial 29. (B) Wrong placement — move the pilot computer/user out of OU=GP-Lab to a different OU. Signature: GPO absent from the report (not in scope). Fix: move the object back, or re-link to the object's actual OU — Tutorial 30. (C) WMI filter — attach a WMI filter that's false on the test machine. Signature: GPO in Denied with reason "WMI Filter." Fix: correct or remove the filter — Tutorial 19. Method: run the Tutorial 37 checklist — name it, check location, read the denied reason, and let the reason route you to the right sub-procedure. Repair and re-verify: make the fix, gpupdate /force, re-read the report, and confirm the GPO moved from Denied (or absent) to Applied with the expected setting. The learning outcome is the loop itself: a controlled failure you can only resolve by reading evidence and acting on it, then proving the fix held. That's the skill the entire series is building — and now you've run it, safely, against a known target.
| Introduced failure | Signature in gpresult | Diagnosis path | Fix / rollback |
|---|---|---|---|
| Security filtering removed | Denied — "Security Filtering" | Tutorial 29: membership + GPO ACL | Restore Read + Apply (or group membership) |
| Object moved out of the OU | GPO absent from report | Tutorial 30: link location vs object path | Move object back / re-link to real OU |
| False WMI filter attached | Denied — "WMI Filter" | Tutorial 19: evaluate the WQL on the machine | Correct or remove the filter |