Learn Active Directory - Group Policy Fundamentals

#Introduction

Imagine having to configure hundreds of computers one by one: changing the wallpaper, locking down the control panel, applying password policy, installing software. No sane admin does that manually. This is where Group Policy becomes the single most productivity-defining tool for a Windows admin. Episode 9 is its foundation: understanding what a GPO is, how it's stored, how its processing order works, and how to troubleshoot problems that arise.

We'll cover the anatomy of a Group Policy Object, the difference between gpedit.msc and GPMC, the LSDOU application order, inheritance and blocking, link order, security filtering and WMI filters, and reading the final result with gpresult.

#What Is Group Policy

Group Policy is Windows' mechanism for pushing centralized configuration to computers and users in a domain. One setting is applied in one place — a GPO — and reaches thousands of machines. Without Group Policy, every policy change must be repeated manually on each computer; with Group Policy, the change only needs to be done once.

#GPO Anatomy: GPC and GPT

Every GPO actually consists of two parts stored in two different places:

The GPC lives in the AD partition under CN=Policies,CN=System, so it replicates like other AD data. The GPT lives at \\domain\SYSVOL\domain\Policies\GUID and replicates via DFSR. The two must always stay in sync — if either is corrupted or missing, the GPO is considered broken. This is why SYSVOL corruption is an admin's nightmare (covered in episode 22).

#gpedit vs GPMC

Beginners often confuse these two tools:

gpedit.msc only edits the local policy of that computer — not replicated and not remotely targetable. Group Policy Management Console (GPMC) is the domain's control center: creating GPOs, linking them to OUs, configuring filtering, backing up, and generating reports. For domain administration, GPMC is the primary tool:

gpmc.msc

#Computer vs User Configuration

Every GPO is divided into two branches:

• Computer Configuration — applied when the computer starts, regardless of who logs in. Examples: firewall, Windows Update, password policy.
• User Configuration — applied when a user logs in, following the user on any machine. Examples: wallpaper, drive mappings, folder redirection.

An important rule: computer settings only apply when computer configuration is processed, and user settings only when user configuration is processed. A setting that logically "belongs to the computer" but is placed in User Configuration will behave strangely — always pick the right branch.

Within each branch there are two entry types: Policies (system-managed, users can't change, will be reverted if manually altered) and Preferences (provide default values that users can still change). This distinction determines how "hard" a setting is.

#Application Order: LSDOU

This is the most important concept in Group Policy. GPOs are applied in this order:

1. Local — the machine's local policy
2. Site — GPOs linked to the site
3. Domain — GPOs linked to the domain
4. OU — GPOs linked to OUs, from the topmost to the deepest

The golden rule: the later it's processed, the more it wins. If two GPOs configure the same setting, the value from the last-processed GPO applies. This means a GPO on the deepest OU beats a domain GPO. The analogy is painting layers: the last layer determines the wall's final color.

#Inheritance and Blocking

GPOs at a higher level are, by default, inherited by all objects below them. Two mechanisms change this inheritance:

• Block inheritance — enabled on a container (OU) to ignore all GPOs from above. Caution: enabling it "isolates" that OU from domain policies such as password policy — use with great care.
• Enforced — enabled on a GPO link so it cannot be blocked by children. An enforced GPO always wins, even if a block inheritance exists below it.

The combination follows one rule: enforced beats block inheritance. This is the admin's "emergency key" when an OU deliberately blocks all policies but a certain security policy must still apply.

#Link Order

A single OU can have many GPOs linked to it. Link order determines priority among them: the GPO with the lowest link order number (topmost in the list) is processed last, so it beats those below it. In practice, admins often shuffle this order — and it becomes a classic source of confusion. Get into the habit of arranging the GPO links on one OU in order and giving them clear names.

#Security Filtering and WMI Filters

By default, a GPO applies to all Authenticated Users beneath the link container. To limit who receives the GPO:

• Security filtering — restrict to specific groups or users. This list can be emptied (GPO applies to no one) or filled with specific groups. This is the most common way to limit scope.
• WMI filters — filters based on machine conditions, e.g. only applied to machines with Windows 11 or more than 8 GB RAM. WMI filters are evaluated at refresh time — adding load if overused.

Example usage: a Printer-Divisi-Marketing GPO is security-filtered to the Marketing group so only that group's members receive the printer policy. Clear filters and scopes prevent GPOs from "leaking" to objects that shouldn't get them.

#Creating and Linking a GPO

In GPMC, the flow is: right-click Group Policy Objects > New, give it a name, then Link an Existing GPO on the target OU. The PowerShell version is one line:

New-GPO -Name "Kebijakan-Password-Strict" | New-GPLink -Target "OU=Karyawan,DC=ad,DC=example,DC=com"

After linking, edit the GPO by right-clicking > Edit, which opens an editor with the same two branches as gpedit — the difference being it's now centralized and applies to the whole scope.

#Applying and Checking Results

GPOs don't apply instantly. Clients refresh policy periodically (default 90 minutes with random jitter) and at logon/startup. To test faster:

gpupdate /force

To see the final result (Resultant Set of Policy) on a client machine:

gpresult /r
gpresult /h C:\gpresult.html

gpresult /r shows a text summary; gpresult /h produces an HTML report you can open in a browser. If a setting "didn't take effect", the first step is always gpresult — check whether the GPO in question appears in the applied list. If it doesn't, the problem is in the link, filtering, or scope; if it appears but the setting doesn't apply, the problem is in GPO order.

#Default Domain Policy

When a domain is created, AD automatically creates two built-in GPOs: Default Domain Policy and Default Domain Controllers Policy. The Default Domain Policy holds the domain's password policy and account lockout policy by default. The industry-agreed rule of thumb:

• Don't put arbitrary settings in these built-in GPOs — keep them focused on their purpose.
• Don't import or delete them carelessly; repairing a broken built-in GPO can hurt more than creating a new one.
• Create new, clearly named GPOs for other needs and link them to the right OU.

#A Quick Troubleshooting Guide

When a GPO misbehaves, check in order: (1) run gpresult /r on the client, (2) confirm the GPO is linked to the right container, (3) check security filtering and WMI filters, (4) check Event Viewer under Applications and Services Logs > Microsoft > Windows > GroupPolicy. Most "GPO not working" cases aren't because the GPO is broken, but because of wrong scope or order.

#Conclusion

Episode 9 builds your foundational understanding of Group Policy: what a GPO is and its two building blocks (GPC and GPT), when to use gpedit.msc and when GPMC, the Computer and User Configuration branches, the LSDOU order that decides who wins, block and enforced mechanisms, link order, security filtering and WMI filters, and reading results with gpresult.

Key takeaways:

• LSDOU order: the later it's processed, the more it wins.
• Enforced beats block inheritance.
• Don't stuff built-in GPOs with arbitrary settings.
• gpresult is always the first troubleshooting step.

Now you understand the mechanism. In episode 10 we cover the contents: Common Group Policy Settings — security settings, password policy, auditing, software deployment, folder redirection, scripts, drive mapping, and printers. See you in episode 10!