Helpdesk: "The new drive-mapping GPO works for half of Sales. The lobby kiosks ignore the lock-screen policy we linked to the Kiosks OU. The branch office laptops still show last month's settings, and the VPN users never got the software install. I ran gpupdate /force on two of them and nothing changed. Can you just push gpupdate /force to every PC?"
Don't push it yet. "Group Policy not applying" is usually one broken layer in a documented chain, not a broken client: the GPO isn't linked where the user or computer object actually lives (or the link, or half of the GPO, is disabled) → the GPO is in scope but filtered out (security filtering, the computer's Read permission since MS16-072, a WMI filter, loopback) → it applied, but a GPO with higher precedence set the same setting another way → the domain controller the client talks to doesn't have the current version yet (Active Directory and SYSVOL replicate separately) → the client can't process policy at all (DC discovery, DNS, LDAP, SYSVOL access, clock) → the setting belongs to an extension that only runs at startup or logon, or not over a slow link → on co-managed PCs, an MDM policy is blocking the Group Policy setting. gpresult, the Group Policy operational log, GPMC's Scope, Delegation, and Status tabs, and the GroupPolicy PowerShell module are the sources for that chain. gpupdate /force reapplies every setting, but it can't fix a link, a filter, or replication, and the extensions that need a logon or a restart still won't run in a background refresh.
If the GPO in question is Enable automatic MDM enrollment using default Microsoft Entra credentials and devices never show up in Intune, start with Auto MDM Enroll Failed (Event 76). If it's the GPO that puts the Seamless SSO URL in the Intranet zone, use Entra Seamless SSO Not Working. This post covers "a domain GPO isn't taking effect on a user or computer, and you need a read-first path before you relink, re-filter, force updates across the fleet, or rebuild the GPO."
TL;DR
-
Run
gpresult /hfrom an elevated prompt on the affected PC first. Is the GPO listed as applied, listed as denied (with a reason), or not listed at all? Each answer points at a different layer. - User settings follow the user object's OU. Computer settings follow the computer object's OU. Microsoft: without loopback processing, a computer only processes the Computer Configuration half and a user only the User Configuration half. A user-settings GPO linked to an OU full of computers does nothing.
- Security filtering needs Read and Apply group policy for the target, and since MS16-072 the computer also needs Read on user GPOs. Removing Authenticated Users from Security Filtering without giving Read to Domain Computers (or the computers' group) breaks user policy.
- A GPO lives in two places that replicate separately: the Group Policy container in Active Directory and the Group Policy template in SYSVOL (DFSR, every 15 minutes within a site). GPMC's Status → Detect Now compares every DC against a baseline.
- Not every extension runs in the background. Folder redirection runs only at logon, and software installation only at startup and logon. The background refresh comes every 90 minutes plus up to 30 minutes of random offset (every 5 minutes on DCs).
- Read the client's own logs before guessing. System log events 1129, 1058, 1053, 1006, 1030, and 1097 each name a cause. The Group Policy operational log lists the applied (5312) and filtered (5313) GPOs for every processing run.
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Exact setting, user or computer half, GPO name, both objects' OUs, gpresult output | "The GPO isn't working" with no detail |
| 2. Link and scope | GPO linked (link enabled) in the OU tree that holds the object, with the right half enabled | GPO not listed in gpresult at all; user settings ignored on a computer OU |
| 3. Filtering | Target has Read and Apply; computers can Read user GPOs; WMI filter true; loopback mode as intended | GPO listed as denied; works for one group, not another |
| 4. Precedence | No higher-precedence or enforced GPO sets the same setting the other way | GPO listed as applied, setting has a different value |
| 5. Replication | The DC the client uses has the same version as the DC you edited on | Works at headquarters, not in the branch; DCs listed as "replication in progress" |
| 6. Client processing | Client finds a DC, resolves DNS, reaches LDAP and SYSVOL, clock within 5 minutes | System log events 1129, 1058, 1053, 1006, 1030, 1097 |
| 7. Timing and extensions | The extension runs in the cycle you're waiting for, on a fast link | Registry settings land, folder redirection or software never does; VPN users only |
| 8. MDM overlap | No Intune setting is blocking the same Group Policy setting | Co-managed PCs ignore the GPO; the Advanced Diagnostic Report lists blocked GP settings |
| 9. Change | Only after Steps 1–8 agree, one layer at a time | Every GPO edited, every PC forced, still not applying |
Step 1: Capture the exact symptom (read-only)
Write these facts on the ticket before anyone edits a GPO or forces an update:
| Fact | Why it matters |
|---|---|
| The exact setting and where it lives | Computer Configuration or User Configuration, Policies or Preferences. That decides whose OU counts, which processing run applies it, and when |
| User, PC, and both OUs | User settings come from the user object's location, computer settings from the computer object's (unless loopback is on) |
| GPO name and where it's linked | You'll compare it with the client's list in a moment |
| When the GPO changed, and on which DC | Replication (Step 5) |
| On the LAN, on VPN, or remote | DC reachability and slow-link behavior (Steps 6 and 7) |
| What else manages this PC | Intune or co-management can block Group Policy settings (Step 8) |
Then collect the Resultant Set of Policy. Microsoft's troubleshooting guide starts with gpresult /h from an elevated command prompt. The computer half (and loopback, which is a computer setting) needs elevation.
# Read-only. Elevated prompt, signed in as the affected user if you can.
gpresult /h "$env:TEMP\gpresult.html" /f
gpresult /r /scope computer
gpresult /r /scope user
# Read-only: the same RSoP data for a remote user and computer (RSAT GroupPolicy module)
# Get-GPResultantSetOfPolicy -Computer 'PC042' -User 'contoso\dana' -ReportType Html -Path 'C:\Temp\PC042-dana.html'
Microsoft notes that on ARM64 Windows only the gpresult in SysWOW64 works with /h. Now find the GPO in the report:
| What gpresult shows for the GPO | Likely layer |
|---|---|
| Listed as applied, but the setting has a different value | Precedence (Step 4), an MDM block (Step 8), or the setting needs a logon or restart (Step 7) |
| Listed as denied with an empty reason, or Not Applied (Empty) | That half of the GPO has no settings for this object. Microsoft's AskDS guidance: usually a User Configuration GPO linked to an OU of computers, or the reverse (Step 2) |
| Denied because of security filtering | Step 3 |
| Denied because of a WMI filter | Step 3 |
| Not listed anywhere | Not in scope (Step 2), not yet on the DC the client uses (Step 5), or the client didn't process policy (Step 6) |
| Old "last applied" time, or errors in the report | Step 6 |
Step 2: Is the GPO linked where the object actually lives? (read-only)
Microsoft's processing order is local GPO → site → domain → OU, with parent OUs before child OUs, and each later GPO can override an earlier one. When several GPOs are linked to the same container, the link with the lowest link order wins.
| Check | What Microsoft documents |
|---|---|
| The object's real OU | Policy follows where the object sits in Active Directory, not where you think it sits. A PC left in the default Computers container isn't in any OU, so OU-linked GPOs never reach it |
| The link is enabled |
Get-GPInheritance lists every directly linked GPO in GpoLinks, enabled or not. InheritedGpoLinks lists only what a client actually processes there, in precedence order |
| Inheritance isn't blocked | GpoInheritanceBlocked on the OU. Block Inheritance stops site, domain, and parent-OU GPOs, except links marked Enforced |
| The GPO, or half of it, isn't disabled | A GPO can be entirely disabled, or have only its computer or only its user settings disabled. Get-GPO shows this as GpoStatus
|
| The right half for the right object | Without loopback, GPOs reaching a computer object only process Computer Configuration, and GPOs reaching a user only process User Configuration |
# Read-only (RSAT: ActiveDirectory and GroupPolicy modules)
(Get-ADComputer 'PC042').DistinguishedName
(Get-ADUser 'dana').DistinguishedName
# What reaches that OU, in precedence order, and whether inheritance is blocked
$som = Get-GPInheritance -Target 'OU=Sales,OU=Workstations,DC=contoso,DC=com'
$som | Select-Object Path, GpoInheritanceBlocked
$som.InheritedGpoLinks | Select-Object Order, DisplayName, Enabled, Enforced, Target
# Is the GPO (or half of it) disabled? Does it carry a WMI filter?
Get-GPO -Name 'Sales - Drive Maps' | Select-Object DisplayName, GpoStatus, WmiFilter, ModificationTime
If the GPO isn't in InheritedGpoLinks for the object's OU, nothing on the client will change that. Fix the link or the object's location (Step 9).
Step 3: Is the GPO filtered out? (read-only)
Security filtering
By default, Authenticated Users has Read and Apply group policy on every GPO, and GPMC's Delegation tab shows that as Read (from Security Filtering). Microsoft's AskDS guidance: target objects need at least Read and Apply group policy.
| Check | What Microsoft documents |
|---|---|
| The target group has Read and Apply | Security filtering decides whether the whole GPO applies. It can't be applied selectively to individual settings inside a GPO |
| Computers can Read user GPOs (MS16-072) | Since MS16-072 (June 2016), Windows retrieves user policy in the computer's security context. Remove Authenticated Users from Security Filtering and you remove Read from every computer. Microsoft's fix is Read (not Apply) for Authenticated Users, Domain Computers, or a group of the computers |
| No explicit Deny | Microsoft: an explicit denial always overrides a permission that would otherwise allow access |
| Domain controllers | Usually unaffected, because Enterprise Domain Controllers has Read on every GPO by default |
| Recently added to the group | Microsoft's MS16-072 guidance: computers don't pick up membership of a new group until a reboot. Users get new group membership at their next sign-in |
# Read-only: every trustee and permission level on the GPO
Get-GPPermission -Name 'Sales - Drive Maps' -All
Look for GpoApply on the group you filter to, and for Authenticated Users, Domain Computers, or a computer group with at least GpoRead. In GPMC, Read without "(from Security Filtering)" means Read only, no Apply.
WMI filters
Each GPO can have one WMI filter. It's evaluated on the client during processing, and the GPO applies only if it evaluates to true. Microsoft documents a hard 30-second timeout for WMI filter queries since Windows Vista. A filter that times out shows up in the GPSvc log as FilterCheck: Evaluate returned error. hr=0x80041069 (WBEM_E_TIMED_OUT), and Microsoft's fix there was a narrower query.
# Read-only: run the filter's query yourself on the affected PC (copy it from GPMC → WMI Filters)
Get-CimInstance -Query "SELECT * FROM Win32_OperatingSystem WHERE ProductType = 1"
# Nothing returned = the filter is false on this PC, so the GPO is denied
Loopback processing
Loopback (Computer Configuration → Policies → Administrative Templates → System → Group Policy → Configure user Group Policy loopback processing mode) makes user settings follow the computer's location. It's meant for kiosks, classrooms, and Remote Desktop Services hosts.
| Check | What Microsoft documents |
|---|---|
| Which mode | Merge: the computer's GPOs are added after the user's, so they win on conflicts. Replace: the user's normal GPO list isn't gathered at all. Operational log event 5311 records the mode as "No loopback mode," Merge, or Replace |
| Which loopback GPO won | gpresult shows the winning GPO with loopback enabled, not every GPO that configures it |
| Permissions | The computer needs Read and Apply on the GPO holding the loopback setting. User settings in a separate GPO need Read and Apply for the user, and Read for the computer. The MS16-072 article adds that Merge mode needs the specific users and computers in Security Filtering |
| Filtering user settings | Microsoft: you can't filter the user settings applied by loopback by denying or removing Read and Apply from the computer object |
| Both accounts in Active Directory | Loopback is supported only when both the computer and the user account are in Active Directory |
Step 4: Did another GPO win? (read-only)
The GPO can be listed as applied and still lose. Microsoft's precedence rules:
- Later wins. GPOs closer to the object override GPOs from higher containers, and domain-based policy overrides local policy.
- Enforced beats Block Inheritance. Enforced is a link property and takes precedence over Block Inheritance, which is a container property. If several enforced links compete, the highest one wins.
- Computer beats user. Microsoft: computer-related policy settings override user-related policy settings.
- Group Policy Preferences have their own logic. Item-level targeting can skip an item, and Apply once and do not reapply means a changed item won't come back.
# Read-only: every setting with every precedence, not just the winning value
gpresult /z > "$env:TEMP\gpresult-z.txt"
# Read-only: what a competing GPO contains, plus its links, security filtering, WMI filter, and delegation
Get-GPOReport -Name 'Workstations - Baseline' -ReportType Html -Path "$env:TEMP\baseline.html"
Microsoft says gpresult /v shows settings applied with a precedence of 1, and /z shows precedence 1 and higher, so the losing values are in the /z output.
Step 5: Does the DC the client uses have the current version? (read-only)
Each GPO is stored in two parts: the Group Policy container in Active Directory and the Group Policy template in SYSVOL. Microsoft: AD replication within a site usually takes less than a minute, while DFSR replicates SYSVOL every 15 minutes within a site, and between sites on the site-link schedule (15 minutes at the lowest). Until both parts reach the DC the client uses, the client sees the old GPO, or a mismatched one.
| Check | What Microsoft documents |
|---|---|
| GPMC Status tab | Select the domain (or one GPO) → Status → Detect Now. GPMC compares each DC with a baseline DC: the ACLs on both parts, the version numbers (including the one in gpt.ini), object, folder, and file counts, and a hash of every template file |
| What a problem looks like | DCs that can't be reached or don't match the baseline appear under Domain controller(s) with replication in progress |
| Limits | The report runs only in GPMC. Microsoft: there's no PowerShell or command-line equivalent, and it isn't kept between GPMC sessions |
| Expected vs. broken | Microsoft: version mismatches can be expected during replication delays, and they can also point to a Group Policy problem. If a DC stays in the list, check AD replication and file replication next |
| Which DC the client used | Operational log event 5308 records the domain controller name and IP address for each processing run |
# Read-only: the same GPO as two DCs see it (AD version vs SYSVOL version for each half)
foreach ($dc in 'DC01','DC02') {
"== $dc"
Get-GPO -Name 'Sales - Drive Maps' -Server $dc | Out-String
}
# Read-only, on the client: which DC did the last runs use?
Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-GroupPolicy/Operational'; Id = 5308 } -MaxEvents 5 |
Select-Object TimeCreated, Message
Works at headquarters, fails in the branch? Compare the branch DC's versions before you touch the GPO.
Step 6: Can the client process policy at all? (read-only on the PC)
Microsoft's checklist starts with the Group Policy events in the System log, then the Group Policy operational log:
| System log event | Microsoft's explanation and first check |
|---|---|
| 1129 | No network connectivity to a domain controller. Microsoft's example is LDAP port 389 blocked to the DC |
| 1058 | Couldn't read a GPO file (gpt.ini) from the DC. Error 3: path not found. Error 5: access denied. Error 53: network path not found (name resolution) |
| 1053 | Couldn't resolve the user name. Error 525: the object needs read access to the OU that holds it. Error 1355: DNS. Error 1727: RPC blocked by a firewall |
| 1006 | LDAP bind failed. Error 49: invalid credentials, for example a password that expired while the user was signed in. Error 258: timeout, check the _ldap._tcp DNS records |
| 1030 | Couldn't retrieve new settings. Check that the LDAP ports are open on the network, the client, and the DC |
| 1097 | Couldn't determine the computer account. Check the time: more than five minutes of skew from the DC can break authentication |
| 1002 | System allocation failure: low memory or disk space |
In the operational log (Applications and Services Logs → Microsoft → Windows → GroupPolicy → Operational), each processing run starts with an event from 4000–4007 (4000 computer startup, 4001 user logon, 4004/4005 manual refresh, 4006/4007 periodic refresh) and ends with 8000–8007 on success, the 6000s on warnings, or the 7000s on errors. 5312 lists the applicable GPOs, 5313 lists the GPOs that were filtered out, and 5314 says whether the link was fast or slow. Microsoft's tip: copy the run's ActivityID from the event details and build a custom view with *[System/Correlation/@ActivityID='{...}'] so you're reading one run, not several mixed together.
# Read-only: recent Group Policy errors and warnings in the System log
Get-WinEvent -FilterHashtable @{ LogName = 'System'; ProviderName = 'Microsoft-Windows-GroupPolicy'; Level = 2,3 } -MaxEvents 20 -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id, LevelDisplayName, Message
# Read-only: applied and filtered GPO lists from the last runs
Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-GroupPolicy/Operational'; Id = 5312,5313 } -MaxEvents 10 |
Select-Object TimeCreated, Id, Message | Format-List
# Read-only: DNS records for the domain's LDAP service, LDAP and SMB reachability to one DC, and the clock
Resolve-DnsName '_ldap._tcp.contoso.com' -Type SRV | Select-Object Name, NameTarget, Port
Test-NetConnection 'dc01.contoso.com' -Port 389 | Select-Object ComputerName, TcpTestSucceeded
Test-NetConnection 'dc01.contoso.com' -Port 445 | Select-Object ComputerName, TcpTestSucceeded
w32tm /query /status
# Read-only: can this account read the GPO template? (take the DC, domain, and GUID from the 1058 event)
Test-Path '\\dc01.contoso.com\SYSVOL\contoso.com\Policies\{GPO-GUID}\gpt.ini'
Microsoft's 1058 guidance is to test that path as the account that failed. For computer policy the event's User field shows SYSTEM, so a test from your own session proves only that your account can read it.
Step 7: Is it timing, an extension, or a slow link? (read-only)
| Fact | What Microsoft documents |
|---|---|
| Foreground first | Computer policy applies at startup and user policy at logon. After that, the system refreshes in the background |
| Background interval | Every 90 minutes, plus a random offset of up to 30 minutes. Domain controllers check every 5 minutes. Setting the interval to zero makes it seven seconds, which Microsoft doesn't recommend |
| Extensions that skip background refresh | Folder redirection runs only at user logon. Software installation runs only at computer startup and user logon. Scripts process in the background, but each script runs only at startup, shutdown, logon, or logoff |
| Unchanged GPOs aren't reapplied | During a refresh an extension reapplies settings only if its GPOs, or its list of GPOs, changed. gpupdate /force reapplies everything |
| Time limit | All policy processing must finish within 60 minutes, and that can't be changed |
| Fast Logon Optimization | Foreground processing is asynchronous by default on Windows clients, so a user may need to sign in twice before folder redirection or software installation applies |
| Synchronous extensions | Microsoft's AskDS team lists four that need a synchronous foreground run: Software Installation, Folder Redirection, Disk Quota, and Group Policy Preferences Drive Maps |
| Slow links | Group Policy estimates the bandwidth to the DC and compares it with the slow-link threshold (500 kbps in Microsoft's example). Some extensions skip a slow link: security settings still process, folder redirection doesn't. Event 5314 records the result |
VPN users. If the VPN connects only after the user signs in, the startup and logon runs never reached a DC. Background refresh catches up on most settings once the tunnel is up, but folder redirection and software installation wait for a foreground run that can see a DC. Microsoft's setting for forcing synchronous foreground processing is Computer Configuration → Administrative Templates → System → Logon → Always wait for the network at computer startup and logon. AskDS warns that it makes all foreground processing synchronous, slows startup and logon, and often gets left on after troubleshooting.
# Read-only: which kinds of runs happened recently, and was the link fast or slow?
Get-WinEvent -FilterHashtable @{ LogName = 'Microsoft-Windows-GroupPolicy/Operational'; Id = 4000,4001,4004,4005,4006,4007,5314 } -MaxEvents 20 |
Select-Object TimeCreated, Id, Message
Step 8: On Intune or co-managed PCs, is MDM blocking the setting? (read-only)
If the PC is also enrolled in Intune, check Microsoft's MDMWinsOverGP policy (./Device/Vendor/MSFT/Policy/Config/ControlPolicyConflict/MDMWinsOverGP, Windows 10 1803 and later):
- Set to 1, any MDM policy in Policy CSP that has an equivalent Group Policy setting causes the Group Policy service to block that GP setting.
- It only covers Policy CSP. Settings defined in other CSPs (Microsoft's example is the Defender CSP) aren't covered, so configuring the same setting in a GPO and in Intune is a race with no guaranteed winner.
- The Advanced Diagnostic Report (Settings → Accounts → Access work or school → the account → Advanced Diagnostic Report → Create report) lists Group Policy settings blocked because an MDM equivalent is configured.
- For Windows Update conflicts, Microsoft points to IgnoreWindowsUpdateGroupPolicies in the Update Policy CSP instead.
A GPO that's "applied" in gpresult but blocked by MDM on a co-managed PC is working as designed. Decide which channel owns that setting.
Step 9: Change one layer, then retest (only after the read)
Pick the one change Steps 1–8 point at:
- Scope: link the GPO to the OU that holds the object, enable the link, or move the object into the right OU. For kiosks and RDS hosts that need user settings by computer, use loopback deliberately.
- Filtering: keep Read and Apply on the target group, and add Read (not Apply) for Authenticated Users, Domain Computers, or a computer group on the GPO's Delegation tab. Restart PCs you just added to a computer group.
- WMI filter: fix the query so it returns true on the PCs you mean, quickly.
- Replication: if a DC stays under "replication in progress," follow Microsoft's next steps for AD replication and file replication before you edit the GPO again.
-
Client: fix DNS, open LDAP to the DC, or fix the clock (Microsoft's 1097 guidance uses
w32tm /resync). -
Refresh, narrowly:
gpupdate /target:computer /forceorgpupdate /target:user /force. Add/logoffor/bootonly for the extensions that need them, or/syncto make the next foreground run synchronous. For many PCs,Invoke-GPUpdate(needs the Remote Scheduled Tasks Management and WMI-In firewall rules on the clients) or GPMC's Group Policy Update on an OU. - Still unclear: turn on GPSvc debug logging on one PC, reproduce, read the log, and turn it off.
# Change (diagnostic, reversible): Group Policy service debug log, per Microsoft's troubleshooting guide. Elevated.
New-Item "$env:windir\debug\usermode" -ItemType Directory -Force | Out-Null
reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" /v GPSvcDebugLevel /t REG_DWORD /d 0x00030002 /f
gpupdate /force /target:computer
# Read %windir%\debug\usermode\gpsvc.log, then turn logging off:
reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" /v GPSvcDebugLevel /t REG_DWORD /d 0x00000000 /f
Microsoft: verbose logging can reduce performance and use a lot of disk space, and if the usermode folder doesn't exist, no log is written. Retest with gpresult /h as the user, and check that the GPO is listed as applied and the setting has the value you expect.
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| GPO not in InheritedGpoLinks for the object's OU | Link it there, or move the object | Linking it at the domain root "to be safe" |
| User settings linked to a computer OU | Link to the users' OU, or loopback for special-use PCs | Duplicating every user setting into computer GPOs |
| Authenticated Users removed from Security Filtering | Add Read (not Apply) for Domain Computers or a computer group | Re-adding Authenticated Users with Apply and losing your filtering |
| PC just added to a filtering group | Restart it | Rebuilding the GPO |
| WMI filter false or timing out | Fix and narrow the query | Removing the filter and scoping to everyone |
| Another GPO wins | Change link order, or the conflicting setting, in one place | Enforcing more links until something sticks |
| DC listed as "replication in progress" | Fix AD or SYSVOL replication first | Editing the GPO again on another DC |
| Events 1129, 1030, 1006 | Fix DNS, LDAP ports, credentials, or time | Running gpupdate /force in a loop |
| Folder redirection or software only fails on VPN | Plan a foreground run on a connection that can see a DC; targeted "Always wait for the network" for that group | Turning on "Always wait" for the whole domain and forgetting it |
| MDM blocks the setting on co-managed PCs | Decide which channel owns it; remove it from the other | Setting it in both and hoping |
FAQ
Why is my GPO not applying to a computer?
In Microsoft's order: the computer object isn't in the OU tree where the GPO is linked (or the link is disabled), the settings are in the User Configuration half, the computer isn't allowed Read and Apply (or a WMI filter is false), another GPO wins, the DC it uses hasn't replicated the change, or the client can't reach a DC. gpresult /h from an elevated prompt tells you which.
Why doesn't gpupdate /force apply my GPO?
/force only reapplies settings the client already receives. It can't change scope, filtering, or replication, and extensions like folder redirection and software installation still wait for a logon or a restart. Use /logoff or /boot for those, and fix the layer gpresult points at for everything else.
Why does my GPO apply to users but not computers (or the reverse)?
Without loopback, a computer processes only Computer Configuration from the GPOs linked above its own OU, and a user processes only User Configuration from the GPOs linked above theirs. A GPO linked to an OU that holds only one kind of object applies only its matching half.
How long does Group Policy take to apply?
At startup and logon, then in the background every 90 minutes plus up to 30 minutes of random offset (DCs every 5 minutes). Add replication: AD usually within a minute inside a site, and SYSVOL on DFSR every 15 minutes within a site, longer between sites.
Why isn't Group Policy applying over VPN?
Usually because the tunnel comes up after logon, so the foreground runs couldn't see a DC, or because the link is slow and some extensions skip slow links. Check events 5314 and 1129 in the logs, and plan a foreground run on a connection that can see a DC for folder redirection and software installation.
Related posts
- Auto MDM Enroll Failed (Event 76) (when the GPO that lands is the Intune auto-enrollment policy, and enrollment still fails)
- Entra Seamless SSO Not Working (the Intranet zone GPO and the Kerberos ticket behind it)
- Hybrid Azure AD Join Pending (domain-joined PCs that never finish joining Entra, which auto-enrollment rides on)
Free checklist
Group Policy is often what puts a domain PC on the path to Conditional Access. The auto-enrollment GPO is how many hybrid joined PCs get into Intune, and Seamless SSO is usually rolled out with a GPO that adds its URL to the Intranet zone. When that GPO doesn't land, the PC never enrolls or becomes compliant, and a "require compliant device" policy blocks the user. Before you enforce, the free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=group-policy-not-applying
Admin Pack Studio; not affiliated with Microsoft. Steps 1–8 favor read-only checks: gpresult, Get-GPResultantSetOfPolicy, Get-GPInheritance, Get-GPO, Get-GPPermission, Get-GPOReport, GPMC's Scope, Delegation, and Status tabs, event log reads, DNS and port tests, and w32tm /query. Linking or moving objects, editing security filtering or WMI filters, enabling loopback or "Always wait for the network," resyncing time, forcing updates with logoff or restart, and turning on GPSvc debug logging are deliberate changes. Change one layer at a time, retest with gpresult as the affected user, and check current Microsoft Learn for console labels and supported versions.
