Topic Hub
Group Policy
GPO design, processing order, ADMX templates, WMI filters, loopback processing, and hybrid Intune coexistence. Practical guidance for administrators still running Windows through Active Directory Group Policy.
Guides, scripts and analysis
Overview
What Group Policy Is Still Used For
Group Policy remains the default control plane for domain-joined Windows machines, especially where servers, shared workstations, legacy applications, and on-premises authentication still matter.
Domain-joined workstation baseline
GPO still handles Windows security options, audit policy, firewall rules, drive maps, certificates, browser controls, and legacy desktop configuration for machines joined to Active Directory.
Windows Server configuration
Most server estates are not Intune-managed. GPO is still the practical way to apply security baselines, Windows Update settings, Event Log policy, and administrative template settings to member servers and domain controllers.
Legacy app and device policy
Line-of-business applications, VDI pools, kiosk-like shared PCs, and peripherals often depend on registry policy, scripts, printers, mapped drives, or Group Policy Preferences that are not cleanly replaced by MDM.
Security baseline enforcement
CIS, Microsoft Security Baseline, and STIG-style controls are frequently deployed as imported GPOs. Many map to Intune Settings Catalog, but GPO remains common for hybrid and server scope.
Logon, startup, and network assumptions
Scripts, folder redirection, software installation policy, and synchronous first-logon workflows are still used where the client has line-of-sight to domain controllers and SYSVOL during startup or sign-in.
Migration reference point
Even when Intune is the destination, existing GPOs document the current state. Exporting and analyzing them is usually the first step before moving workloads to Settings Catalog policies.
Processing
GPO Processing Basics
When policy does not apply, start with processing order and scope before changing settings. Most failures are explained by where the object lives, which GPOs are linked, and whether the client can read SYSVOL and Active Directory.
Order of application
LSDOU precedence
- Sequence
- Local policy applies first, then site-linked GPOs, domain-linked GPOs, and finally OU-linked GPOs. In nested OUs, parent OU links process before child OU links.
- Precedence
- Later policy normally wins when two settings conflict. The OU closest to the user or computer usually has the final say unless an enforced link or block inheritance changes the result.
- Link order
- Multiple GPOs can be linked to the same site, domain, or OU. In GPMC, lower link order has higher precedence within that container.
- Not every setting conflicts
- Some client-side extensions merge settings, such as security policy. Others overwrite. Read the specific extension behavior before assuming last writer wins.
Timing
Foreground and background refresh
- Computer policy
- Computer Configuration applies at startup and during the periodic background refresh cycle. Some extensions require startup processing to complete.
- User policy
- User Configuration applies at sign-in and during background refresh. Folder redirection and some software deployment behavior depend on foreground logon processing.
- Refresh interval
- Clients normally refresh Group Policy about every 90 minutes with a random offset. Domain controllers refresh more frequently.
- gpupdate
- gpupdate triggers a refresh, but it does not fix scope, permissions, replication, WMI filter, or client-side extension failures. Use it after you know the policy should apply.
What applies the setting
Client-side extensions
- Examples
- Registry policy, Security Settings, Scripts, Folder Redirection, Software Installation, Drive Maps, Printers, and Scheduled Tasks are processed by different extensions.
- Failure mode
- A GPO can be in scope while one extension fails. That is why Event Viewer often matters more than the visible GPO list.
- SYSVOL dependency
- The client reads policy files from SYSVOL. DFSR backlog, DNS issues, or domain controller reachability can make a correctly linked GPO fail at application time.
- Version mismatch
- The AD object and SYSVOL version must line up. Replication problems can leave clients reading an older or incomplete copy of a policy.
Scope
OU Links, Security Filtering, WMI Filters, and Loopback
A GPO only matters if the user or computer is in scope and allowed to apply it. Build a clear targeting model before adding more GPOs.
OU and link design
Link GPOs where the target objects live. Separate user and computer OUs when the setting model is different, and keep baseline GPOs broad while making application or department policy narrow.
Security filtering
Security filtering depends on Read and Apply Group Policy permissions. If Authenticated Users is removed, make sure the computer account can still read the GPO or the client may never evaluate it.
WMI filtering
WMI filters evaluate on the target computer during processing. Keep filters simple and fast. Slow or broken WMI queries can delay logon and make a valid GPO look like it disappeared.
Enforced and block inheritance
Enforced is a link setting that prevents lower containers from overriding that GPO. Block inheritance is a container setting that stops normal inherited links, but it does not stop enforced links.
User vs computer side
Computer Configuration only applies to computers, and User Configuration only applies to users. A GPO can be linked correctly but still do nothing if the wrong side is disabled or the wrong object type is targeted.
Loopback processing
Loopback applies user policy based on the computer object. Use Merge for adding computer-scoped user policy and Replace for shared devices where the computer location should fully control user settings.
Deep-Dive Tutorials
Hardening Windows 11 Endpoints with CIS Benchmark Level 1
Apply the CIS Level 1 benchmark to Windows 11 22H2 and 24H2 endpoints using Group Policy, Intune profiles, and a validation script that reports compliance gaps.
20 min read · Advanced
Group Policy Troubleshooting with RSoP, gpresult, and Policy Scope Analysis
A practical troubleshooting methodology for Group Policy: reading RSoP, interpreting gpresult /h output, diagnosing WMI filter failures, and resolving OUlinking conflicts.
12 min read · Beginner
Diagnostics
RSoP, gpresult, and Event Viewer Troubleshooting
The fastest diagnosis is to prove three things in order: the policy is in scope, the client evaluated it, and the relevant client-side extension applied the setting without error.
Start with gpresult /h
Run gpresult /h C:\Temp\gpresult.html from an elevated prompt for computer policy, and as the affected user for user policy. Check Applied GPOs, Denied GPOs, security filtering, WMI filter results, and winning settings.
Use RSoP for visual inspection
rsop.msc is useful when you need a quick MMC view of applied Administrative Template and security settings. It is less complete than gpresult, so use both when diagnosing complex scope issues.
Read Event Viewer
Check Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational. Extension timing, WMI filter failures, inaccessible OUs, and SYSVOL read issues usually surface here.
Separate scope from application
If the GPO appears under Denied GPOs, fix OU, link, security, or WMI targeting. If it appears under Applied GPOs but the setting is missing, investigate the specific client-side extension and setting path.
Check domain controller and SYSVOL path
gpresult shows the domain controller used. Confirm the client can resolve and reach that DC, read SYSVOL, and see the expected policy version after AD and DFSR replication complete.
Do not rely on gpupdate alone
gpupdate /force reruns policy processing, but repeated refreshes hide the real problem. Capture gpresult and the GroupPolicy Operational log before and after the refresh so you can compare what changed.
Troubleshooting
Hybrid management
Group Policy and Intune Coexistence
Hybrid environments often run GPO, ConfigMgr, and Intune at the same time. That can work, but each setting needs one clear authority.
Best for domain-bound workloads
Keep GPO
- Good fit
- Servers, domain controllers, shared workstations, VDI pools, certificate auto-enrollment, printer and drive mapping, and settings tied to on-premises resources.
- Operational model
- Use clear OU structure, small purpose-built GPOs, documented link order, and regular backup/export from GPMC.
- Watch out for
- Do not leave old workstation GPOs targeting devices that have already moved to Entra join and Intune-only management.
Best for cloud-managed endpoints
Migrate to Intune
- Good fit
- Windows 10/11 endpoints that are Entra joined or hybrid joined, especially settings available in Settings Catalog or Endpoint security profiles.
- Migration path
- Export GPOs as XML, import them into Group Policy analytics, review MDM support, then rebuild supported settings as Settings Catalog policy.
- Watch out for
- Unsupported, deprecated, or preference-based settings may need scripts, remediations, app packaging, or a decision to keep a scoped GPO.
Transitional state
Coexist carefully
- Good fit
- Phased migrations where existing domain-joined devices keep baseline GPO while selected workloads move to Intune or ConfigMgr co-management.
- Conflict control
- Avoid configuring the same setting in both GPO and MDM. MDMWinsOverGP only applies to supported Policy CSP settings, not every equivalent control.
- Validation
- Compare gpresult with the Intune per-setting status page. A device can show both policies present while only one actually controls the setting.
Scripts & Automation
Get-StaleDevices
Identifies devices inactive for a configurable threshold across Intune, Entra ID, and on-premises Active Directory. Outputs CSV and HTML reports with remediation actions.
PowerShell
Invoke-WindowsHardening
Applies a configurable subset of CIS Level 1 and Level 2 controls to Windows 10/11 endpoints. Runs locally or via Intune remediation script. Generates a pre/post compliance delta report.
PowerShell
Get-PatchComplianceReport
Queries WSUS or Windows Update for Business status via WMI and Graph API. Produces a per-device patch lag report with severity breakdown and exportable HTML dashboard.
PowerShell
Common problems
Where Group Policy Goes Wrong
Most GPO incidents repeat the same patterns. Work through these before assuming Windows ignored the policy.
Computer is in the wrong OU
The policy is linked correctly, but the device object was moved, reimaged into a staging OU, or renamed and recreated. Confirm the object path in Active Directory before changing the GPO.
Security filtering removed Read permission
A GPO filtered to a security group can disappear from processing if the computer cannot read the GPO. When replacing Authenticated Users, keep read permission for the right principals.
WMI filter evaluates false or slowly
Filters based on OS version, chassis type, or installed software can fail after upgrades or hardware refresh. Test the WMI query locally on the affected client and keep the filter narrow.
User setting linked to a computer-only OU
User Configuration will not apply just because a computer is in scope. Either link the GPO to the user OU or intentionally use loopback processing on the computer side.
SYSVOL or AD replication lag
A client reads the GPO from a domain controller that has not received the latest SYSVOL or AD copy. Check the DC listed in gpresult and verify policy version consistency.
Conflicting Intune or ConfigMgr policy
Hybrid-joined devices may receive GPO, MDM, and ConfigMgr settings. Windows Update, Defender, BitLocker, and firewall controls need one authority per setting.
ADMX Central Store mismatch
Admins editing from different workstations may see different settings if the Central Store is stale or missing vendor ADMX files. Maintain a versioned PolicyDefinitions source before copying into SYSVOL.
Slow link or VPN timing
Remote devices may process before the VPN is available, or be treated as slow-link connections. Startup scripts, software installation, and folder redirection are especially sensitive to network timing.
Reading path
Recommended AdminSignal Reading Path
Use this path when you are auditing an existing Group Policy estate or preparing a hybrid migration to Intune.
- 1
Group Policy Troubleshooting with RSoP, gpresult, and Policy Scope Analysis
Start with the core diagnostic workflow: RSoP, gpresult output, WMI filters, and OU/link scope analysis.
- 2
Group Policy Not Applying to Users or Computers
Use the decision tree for denied GPOs, loopback, slow links, security filtering, and common scope failures.
- 3
Hardening Windows 11 Endpoints with CIS Benchmark Level 1
Apply and validate baseline controls via GPO or Intune, then compare policy outcomes before broad rollout.
- 4
Patch Management Hub
Use this for WSUS, WUfB, Intune update rings, maintenance windows, and update policy conflict patterns.
- 5
Microsoft Intune Hub
Plan the MDM side of a migration: Settings Catalog, compliance, update rings, and co-management boundaries.
- 6
SCCM / MECM Hub
Understand co-management workload sliding and the places where ConfigMgr, GPO, and Intune can overlap.
Official docs
Key Microsoft Documentation
Authoritative references for Group Policy processing, scope, ADMX templates, RSoP, gpresult, and Intune migration planning.
Group Policy processing ↗
Processing order, foreground and background refresh, enforced links, block inheritance, filtering, and loopback behavior.
Group Policy scope ↗
How OU position, security filtering, and WMI filtering determine whether a GPO applies.
gpresult command reference ↗
Command syntax for reporting the Resultant Set of Policy for local and remote users or computers.
Use RSoP to manage Group Policy ↗
Microsoft reference for Resultant Set of Policy planning and logging modes in GPMC.
Create and manage the ADMX Central Store ↗
Central Store layout, ADMX/ADML handling, and policy template version management.
Intune Group Policy analytics ↗
Import on-premises GPO XML, analyze MDM support, and plan Settings Catalog migration.