Group Policy

What Group Policy does

Group Policy is the Windows feature for applying settings to computers and users centrally; the Operating Systems topic introduces it, together with gpedit.msc for a single PC. In an Active Directory domain it becomes the main way to configure Windows at scale: one change in the Group Policy Management Console (gpmc.msc) reaches every computer in an OU at its next refresh.

Typical uses:

• Security baselines: firewall profiles, audit policy, which local groups may sign in remotely, Microsoft Defender settings, BitLocker, Windows LAPS (see Privileged Access Management).
• Account policies for the domain: password length, lockout and Kerberos ticket lifetimes.
• User experience: mapped drives, printers, Start menu and browser settings, a locked-down desktop on shared PCs.
• Scripts and software: startup, shutdown, sign-in and sign-out scripts, and basic software installation.

Most settings come from Administrative Templates, ADMX files that describe registry-based settings for Windows, Microsoft Office, browsers and other software. Store them once in the domain's Central Store (\\ad.example.com\SYSVOL\ad.example.com\Policies\PolicyDefinitions) so every administrator edits GPOs with the same, current templates.

Group Policy Objects

A Group Policy Object (GPO) is a named collection of Group Policy settings, with a computer part and a user part, stored in Active Directory and the SYSVOL share and applied wherever it is linked to a site, domain or organizational unit. A GPO has two halves on disk and in the directory:

• the Group Policy Container, an object in AD with the GPO's name, version and permissions, replicated with AD;
• the Group Policy Template, a folder named after the GPO's GUID under \\ad.example.com\SYSVOL with the actual settings files, replicated between DCs by DFS Replication.

Because the two halves replicate by different mechanisms, a DC can briefly have a new container and an old template. If SYSVOL replication is broken, that mismatch lasts, and clients that ask that DC get errors or old settings. "Group Policy works on some PCs but not on others" is often a SYSVOL replication problem on one DC.

Computer and user configuration

Every GPO has a Computer Configuration section, applied to computer accounts at startup and at each refresh, and a User Configuration section, applied to user accounts at sign-in and at each refresh. Which section applies depends on where the object is: a GPO linked to an OU that holds only computers applies its computer settings to them, and its user settings to nobody (unless loopback processing is on, see below). If a GPO only uses one half, disable the other in the GPO's status, which saves a little processing time and makes the intent clear.

Policies and preferences

Both sections contain two kinds of settings, which behave differently:

Use a policy when you mean "must"; use a preference for a sensible default the user may adjust.

Linking GPOs

A GPO link is the connection between a Group Policy Object and an AD site, domain or organizational unit that makes the GPO apply to the computers and users in that container and everything below it. The GPO and its links are separate things. One GPO can be linked in several places, and a link can be disabled without touching the GPO. In the console, "Delete" on a link removes only the link; deleting the GPO itself under "Group Policy Objects" removes it everywhere.

GPOs can be linked to three kinds of containers (the structure is explained in Active Directory Fundamentals):

• Sites: for settings tied to a location, such as a local proxy or printers. Rarely used, because site GPOs are stored in the forest root domain and not every administrator thinks of them.
• The domain: for settings that really apply to everything.
• Organizational units (OUs): where most links belong. A good OU design separates computers from users and workstations from servers, precisely so that GPOs can be linked to the right set of objects.

The built-in CN=Users and CN=Computers containers are not OUs and cannot have GPOs linked. Objects left there only get local, site and domain GPOs. Redirect new computers to a real OU (the redircmp command does that) so a freshly joined PC gets its baseline from the start.

The processing order: LSDOU

LSDOU is the order in which Windows applies Group Policy: the Local policy first, then GPOs linked to the Site, then to the Domain, then to each OU from the top of the tree down to the OU that holds the object. Later GPOs overwrite conflicting settings from earlier ones, so the OU closest to the computer or user normally has the last word. Settings that do not conflict simply add up.

When several GPOs are linked to the same container, the link order decides: link order 1 has the highest precedence, which means it is applied last among that container's links.

Enforced and Block inheritance

Two switches change the normal order, and both are easy to overuse.

Block inheritance is a setting on a domain or OU that stops it from receiving GPOs linked to the containers above it (site, domain and parent OUs), so only its own links, the local policy and enforced links apply to the objects inside. It is meant for a part of the tree that genuinely needs a different configuration, such as a lab or kiosk OU.

An Enforced GPO is a GPO whose link is marked "Enforced" (formerly "No Override"), so it cannot be blocked by Block inheritance below it, and its settings win over conflicting settings from GPOs linked lower in the tree. Windows achieves that by applying enforced links after all others, the one highest in the tree last. Enforced is a property of the link: the same GPO can be enforced at the domain and not enforced elsewhere.

Computing the winning setting

This sketch applies the rules above to the tree from the diagram: LSDOU order, link order within a container, Block inheritance on OU Billing, and an enforced baseline at the domain. It prints the order in which GPOs are applied and, per setting, which GPO won.

# Which GPO wins? LSDOU order with Enforced links and Block inheritance.

# Each link: (container, GPO, link order, enforced, settings)
LINKS = [
    ("Local", "Local policy", 1, False, {"screen_lock_min": 30}),
    ("Site Utrecht", "Utrecht printers", 1, False, {"printer": "prn-utr-01"}),
    ("ad.example.com", "Kestrel baseline", 1, True,
     {"firewall": "on", "screen_lock_min": 15}),
    ("ad.example.com", "Kestrel desktop", 2, False,
     {"usb_storage": "allowed", "wallpaper": "kestrel.jpg"}),
    ("OU=Workstations", "Workstation hardening", 1, False,
     {"usb_storage": "blocked", "screen_lock_min": 10}),
    ("OU=Billing", "Billing kiosk", 1, False,
     {"screen_lock_min": 5, "firewall": "off"}),
    ("OU=Billing", "Billing apps", 2, False,
     {"printer": "prn-bil-02", "usb_storage": "read-only"}),
]
BLOCKS_INHERITANCE = {"OU=Billing"}


def processing_order(path):
    """GPO links in the order Windows applies them; the last one wins."""
    normal, enforced = [], []
    for container in path:  # Local, site, domain, then OUs from the top down
        # Within one container, link order 1 is applied last, so it wins.
        links = sorted((l for l in LINKS if l[0] == container),
                       key=lambda l: -l[2])
        if container in BLOCKS_INHERITANCE:
            # Drop non-enforced links from parents; Local is never blocked.
            normal = [l for l in normal if l[0] == "Local"]
        normal += [l for l in links if not l[3]]
        # Enforced links run after all others, the top-most container last.
        enforced = [l for l in links if l[3]] + enforced
    return normal + enforced


def resulting_policy(path):
    result = {}
    for _container, gpo, _order, _enforced, settings in processing_order(path):
        for name, value in settings.items():
            result[name] = (value, gpo)  # a later GPO overwrites an earlier one
    return result


COMPUTERS = {
    "PC-WS-031": ["Local", "Site Utrecht", "ad.example.com", "OU=Workstations"],
    "PC-BIL-014": ["Local", "Site Utrecht", "ad.example.com",
                   "OU=Workstations", "OU=Billing"],
}
for computer, path in COMPUTERS.items():
    print(computer)
    print("  applied:", " > ".join(l[1] for l in processing_order(path)))
    for name, (value, gpo) in sorted(resulting_policy(path).items()):
        print(f"  {name:<16}{value!s:<12}from {gpo}")

PC-WS-031
  applied: Local policy > Utrecht printers > Kestrel desktop > Workstation hardening > Kestrel baseline
  firewall        on          from Kestrel baseline
  printer         prn-utr-01  from Utrecht printers
  screen_lock_min 15          from Kestrel baseline
  usb_storage     blocked     from Workstation hardening
  wallpaper       kestrel.jpg from Kestrel desktop
PC-BIL-014
  applied: Local policy > Billing apps > Billing kiosk > Kestrel baseline
  firewall        on          from Kestrel baseline
  printer         prn-bil-02  from Billing apps
  screen_lock_min 15          from Kestrel baseline
  usb_storage     read-only   from Billing apps

Three results are worth a second look. On PC-BIL-014 the site's printer and the domain wallpaper are gone: Block inheritance on Billing skipped them. The firewall stays on although "Billing kiosk" turns it off, because the enforced baseline is applied last. And the enforced baseline also overrides the stricter 5-minute screen lock of the kiosk GPO: Enforced does not mean "most secure wins", it means "this link wins". In a real domain, security filtering and WMI filters (next section) would be checked before a GPO even enters this list.

Loopback processing

Normally user settings follow the user's OU. On shared machines such as Remote Desktop servers, kiosks or classroom PCs you want the opposite: every user who signs in to these computers gets the same restricted desktop. Loopback processing, a computer setting, does that. In Merge mode the user GPOs from the computer's OU are applied after the user's own, so they win conflicts; in Replace mode only the user GPOs from the computer's OU apply.

Security filtering and WMI filters

Links decide where a GPO can apply. Filters narrow it down further inside that part of the tree.

Security filtering limits a GPO to the users, computers or groups that have the Read and Apply group policy permissions on it, so that objects in a linked OU that are not in those groups skip the GPO. The default is Authenticated Users, which includes every user and computer account. To roll out a new GPO to a pilot group first, replace Authenticated Users in the filter with a group such as GG-GPO-Pilot-Computers.

A WMI filter is a query, in the WMI Query Language, that each computer evaluates against itself; the GPO applies only if it returns a result. The classic example selects workstations and excludes servers and DCs:

SELECT * FROM Win32_OperatingSystem WHERE ProductType = "1"

(ProductType is 1 for a workstation, 2 for a domain controller and 3 for a member server.) WMI filters run on every computer at every refresh, so keep them simple; a slow query delays startup and sign-in. A good OU structure removes the need for most of them.

Refresh: when settings arrive

Group Policy refresh is the periodic background re-application of Group Policy on a running computer, without a restart or new sign-in. According to Microsoft's documentation, member computers refresh by default every 90 minutes plus a random offset of up to 30 minutes, so that thousands of PCs do not hit the DCs at the same moment; domain controllers refresh every 5 minutes.

Not everything can change in the background. Software installation and folder redirection, for example, only apply at startup or sign-in (the "foreground" processing), and some security settings need a restart. When you test a change:

gpupdate /force          # reapply all computer and user policy now
gpupdate /target:computer /force /boot   # computer part only, restart if needed

/force reapplies every setting, not only the changed ones. On thousands of machines at once that is a load on the DCs, so use it for testing, not as a scheduled task. The Group Policy Management Console can also trigger a remote update for all computers in an OU, which runs gpupdate on each of them at a random moment within ten minutes.

Troubleshooting with gpresult

When a setting does not arrive, ask the computer what it received. gpresult reports the Resultant Set of Policy (RSoP): the GPOs that were applied, those that were filtered out and why, and the groups the computer and user were in at the time. Run it in an elevated prompt to see the computer part:

gpresult /r                        # summary in the console
gpresult /h C:\Temp\rsop.html      # full HTML report with every winning setting

COMPUTER SETTINGS
------------------
    CN=PC-BIL-014,OU=Billing,OU=Workstations,DC=ad,DC=example,DC=com
    Last time Group Policy was applied: 10/1/2026 at 9:12:40 AM
    Group Policy was applied from:      DC01.ad.example.com
    Domain Name:                        AD

    Applied Group Policy Objects
    -----------------------------
        Kestrel baseline
        Billing kiosk
        Billing apps
        Local Group Policy

    The following GPOs were not applied because they were filtered out
    -------------------------------------------------------------------
        Billing printers (pilot)
            Filtering:  Denied (Security)

        Workstation inventory
            Filtering:  Denied (WMI Filter)

The filtering reasons point straight at the cause: Denied (Security) means security filtering excluded this computer, and Denied (WMI Filter) means the WMI query returned nothing on this computer. The HTML report from /h also shows, for each setting, which GPO won.

Where to look next:

• The event log Applications and Services Logs › Microsoft › Windows › GroupPolicy › Operational records each processing run, the DC used and how long each part took.
• In the Group Policy Management Console, Group Policy Results collects the same report remotely, and Group Policy Modeling predicts the result for a computer or user before you move them to another OU.
• If the computer cannot find a DC at all, the problem is not Group Policy; start with DNS and Active Directory.

Group Policy and cloud management

Group Policy needs a domain-joined computer that can reach a DC. Devices that are only joined to Microsoft Entra ID, the cloud directory, never process domain GPOs. They are configured through mobile device management (MDM), in Microsoft's case with Intune (see mobile device management and Microsoft Entra ID). As of 2026, Microsoft positions Intune as the direction for new Windows deployments, with configuration profiles, a settings catalog and security baselines; Intune also has a Group Policy analytics feature that imports a GPO backup and shows which settings have an MDM equivalent.

Many organizations are in between: devices joined to both AD and Entra ID, receiving GPOs and Intune policies at the same time. That works, but make one system the owner of each setting. Two systems configuring the same firewall rule or update policy give results that depend on timing and on conflict-resolution settings, which is no better than nested Enforced links.

Common mistakes and security

• Linking everything at the domain root. A GPO linked to the domain also reaches servers, DCs and service accounts it was never meant for. Link to the OU that needs it.
• One GPO per setting, or one GPO for everything. Hundreds of tiny GPOs slow processing and nobody can find anything; one giant GPO cannot be tested or rolled back in parts. Group by purpose and audience: "Workstation – Defender baseline".
• Testing in production. Link a new GPO to a pilot OU, or filter it to a pilot group, before widening. Back up GPOs (Backup-GPO or the console) before large changes.
• Forgetting the computer/user split. User settings in a GPO linked to an OU that holds only computers do nothing without loopback processing.

Group Policy is also an attack path. Whoever can edit a GPO linked to an OU can run code on every computer in it; attackers who gain that right use it to spread malware or create accounts (MITRE ATT&CK T1484.001, Group Policy modification). Treat edit rights on GPOs linked to DCs and servers as highly privileged, review the Delegation tab of important GPOs, and audit directory changes so that modifications to GPO objects raise alerts. More on detection is on Attacks on Identity and Monitoring and Troubleshooting Identity.