What Is Group Policy? GPOs, Settings & Processing Order

Our Windows Server support team manages Group Policy in every Active Directory environment we run. This page documents how Group Policy works: what a GPO contains, the order in which policies apply, the settings most environments deploy, refresh behavior, and how to troubleshoot a setting that is not applying.

What Group Policy is

Group Policy is the configuration management system built into Windows and Active Directory. An administrator defines settings once, in a Group Policy Object (GPO), and links that GPO to a site, domain, or organizational unit (OU) in Active Directory. Every computer and user within the scope of the link then receives those settings automatically. The Group Policy overview describes the components: the Group Policy engine on each client, client-side extensions (CSEs) that apply specific setting categories, and the GPOs themselves stored partly in Active Directory and partly in the SYSVOL share on domain controllers.

The practical effect: password requirements, drive mappings, firewall rules, update settings, and thousands of other configuration items are enforced centrally instead of being set per machine. A domain-joined machine applies computer policy at startup and user policy at logon, then refreshes both in the background on a timer.

Anatomy of a GPO

Every GPO has the same internal structure, visible when you edit one in the Group Policy Management Editor:

• Computer Configuration — settings that apply to the machine regardless of who logs on. Applied at startup and during computer policy refresh. Machine-scoped settings (security options, services, update behavior) live here.
• User Configuration — settings that apply to the user account regardless of which machine the user logs on to. Applied at logon and during user policy refresh.
• Policies vs Preferences — each configuration half is split again. Policies are enforced: the setting is locked, the corresponding UI control is typically greyed out, and the value reverts under policy control at each refresh. Preferences (drive maps, printers, registry values, shortcuts, scheduled tasks) set an initial value that the user can change unless the item is configured to reapply, and preferences support item-level targeting (apply only when conditions such as group membership or OS version match).
• ADMX templates — Administrative Templates settings are defined by ADMX/ADML files. These are registry-based policies: each Administrative Templates setting writes values under the policy keys in HKLM or HKCU. Environments with more than one administrator should store ADMX files in a central store in SYSVOL so all editing consoles show the same set of settings.

Processing order: LSDOU

GPOs apply in a fixed order, documented in Group Policy processing. The order is local, site, domain, OU — commonly abbreviated LSDOU:

1. Local — the local Group Policy object on the machine itself.
2. Site — GPOs linked to the Active Directory site the computer belongs to.
3. Domain — GPOs linked at the domain level.
4. OU — GPOs linked to OUs, processed from the OU closest to the domain root down to the OU that directly contains the computer or user object.

Later wins. When two GPOs configure the same setting to different values, the GPO processed last takes effect, so an OU-linked GPO normally overrides a domain-linked one. When multiple GPOs are linked to the same container, link order within that container decides: the link with the lowest number is processed last and therefore wins.

Three mechanisms modify the default order:

Enforced. A GPO link marked Enforced cannot be overridden by GPOs processed later, and it also applies through containers that block inheritance. Domain-level GPOs that must apply everywhere — a security baseline, for example — are the typical use.

Block Inheritance. Set on an OU, this stops GPOs linked at higher levels (site, domain, parent OUs) from applying to objects in that OU. Enforced links pass through it anyway.

Loopback processing. Normally the user's own OU location determines which user settings apply. Loopback processing (a Computer Configuration setting) makes user settings depend on the computer's location instead. In replace mode, the user gets only the user settings from the GPOs that apply to the computer; in merge mode, the computer-scoped user settings are applied after, and win over, the user's normal settings. It is used for kiosks, session hosts, and lab machines where the machine role should dictate the user experience.

Common settings administrators deploy

Management tools: GPMC and gpedit

The Group Policy Management Console (GPMC, gpmc.msc) is the domain management tool: it creates and links GPOs, sets Enforced and Block Inheritance, controls security filtering and WMI filtering, backs up and restores GPOs, and runs modeling and results reports. It is installed as a feature on Windows Server or through RSAT on a workstation. Editing a GPO from GPMC opens the Group Policy Management Editor for that GPO.

The Local Group Policy Editor (gpedit.msc) edits only the local GPO of the machine it runs on. It has no view of domain GPOs and cannot manage them. Its scope is standalone machines and one-off local exceptions; domain settings applied through LSDOU override conflicting local policy, because local is processed first.

Refresh behavior

Computer policy applies at startup and user policy at logon. After that, both refresh in the background every 90 minutes by default, with a random offset of up to 30 minutes added per machine so clients do not query domain controllers simultaneously. Domain controllers refresh computer policy every 5 minutes. These intervals are themselves configurable through Administrative Templates settings under System > Group Policy.

During a background refresh, a client-side extension reapplies its settings only if the GPO list or a GPO version has changed. Some categories never apply in the background: software installation and folder redirection only process at startup or logon, because changing them mid-session is unsafe.

To apply changes immediately, run gpupdate on the client, which applies only changed settings, or gpupdate /force, which reapplies all settings — reference: gpupdate. GPMC can also trigger a remote refresh for every machine in an OU (right-click the OU, Group Policy Update), and PowerShell has Invoke-GPUpdate for the same purpose. Note that a new or edited GPO must first replicate to the domain controller the client uses; Active Directory and SYSVOL replication add their own delay before any refresh can pick up the change.

Troubleshooting: gpresult, RSoP, event logs

When a setting does not apply, the diagnostic sequence is consistent:

1. gpresult /h report.html — generates the Resultant Set of Policy report for the current computer and user: which GPOs applied, which were denied and why (security filtering, WMI filter, disabled link, empty), and the winning GPO for each setting. gpresult /r prints a summary to the console; /scope computer or /scope user narrows it. Reference: gpresult. Run from an elevated prompt to see the computer half.
2. RSoP from the server side — the Group Policy Results wizard in GPMC produces the same report for a remote computer and user, and Group Policy Modeling simulates what would apply after a planned move or filter change before you make it.
3. Event logs — the Group Policy operational log at Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational records each processing cycle with per-phase events; the System log carries the summary errors (event 1058 and similar for SYSVOL access failures). Processing failures here usually point at DNS, connectivity to a domain controller, or SYSVOL replication rather than at the GPO itself.

The common root causes, in observed order: the object is not in the OU the GPO is linked to; security filtering removed Authenticated Users without adding the target group with both Read and Apply permissions (and, since the MS16-072 change, the computer account needs Read for user policy processing); the GPO has not replicated to the client's domain controller yet; a later GPO overrides the setting; or the client cannot reach SYSVOL.

Security baselines

Microsoft publishes recommended hardening configurations as importable GPO backups in the Microsoft Security Compliance Toolkit, downloadable from the Microsoft Download Center. The toolkit contains baselines for supported Windows client versions, Windows Server 2016 through 2025, Microsoft 365 Apps for enterprise, and Microsoft Edge, plus tooling: Policy Analyzer compares baseline GPOs against your current GPOs and local registry state, and LGPO.exe applies policy backups to non-domain-joined machines. The standard deployment pattern is to import the baseline as its own GPO, link it above your customization GPOs, and put deliberate deviations in a separate override GPO so the baseline can be updated without merging.

Group Policy and Intune

Group Policy applies to machines joined to on-premises Active Directory (including hybrid-joined devices). Devices that are Microsoft Entra joined only, with no on-premises domain join, do not process domain GPOs at all; they are configured through Intune, which delivers settings via the Policy configuration service provider (CSP). Many Administrative Templates settings have CSP equivalents, and Intune's settings catalog exposes ADMX-backed policies, but the two systems are separate: a GPO is not converted or synchronized to Intune by default. Microsoft's Group Policy analytics tool in Intune reports which settings in an imported GPO have MDM equivalents, which is the starting point for a migration. Environments running both (hybrid join with co-management) need a deliberate decision about which channel owns which setting category to avoid conflicts.

Related pages

Group Policy depends on the directory underneath it — domain controllers, replication, and OU design are covered in Active Directory. For environments where GPO sprawl, slow logons, or policy conflicts have accumulated over years, Group Policy audit and consolidation is a standard engagement for our server team.