Why “Per User Settings” in Intune Take So Long to Apply
If you’ve ever noticed that user-targeted policies in Microsoft Intune seem to take forever to apply — sometimes 8 hours or more — you’re not alone. A recent Reddit thread highlights this exact frustration, where one admin shared that while device policies apply quickly (within the expected 30-minute refresh window), per-user settings can lag far behind.
Here’s a breakdown of what’s likely happening, why it occurs, and what you can do about it.
🔍 The Scenario
The original poster configured two user-scoped profiles in Intune:
- Policy A: Applied to all users except a specific group.
- Policy B: Applied only to that excluded group.
This setup allows the organization to toggle configurations based on group membership, such as granting extra privileges to administrators while restricting standard users.
However, when moving users between these groups, the updated settings didn’t apply immediately. Even after trying multiple troubleshooting steps — restarting the device, restarting the Intune Management Extension (IME) service, performing manual syncs, and signing out and back in — nothing worked right away. The policy settings would remain unchanged for hours, only to update suddenly later.
⚙️ Device vs. User Policies: Why the Delay Happens
1. Different Sync Mechanisms
- Device policies refresh on a regular schedule (roughly every 30 minutes) because they run under the SYSTEM context using the MDM agent.
- User policies, on the other hand, rely on the user context, meaning they’re tied to a user’s login session and Azure AD token. These tokens often refresh every 8 hours, which explains why changes might take that long to appear.
2. Azure AD Group Membership Caching
When a user’s group membership changes, it isn’t always updated immediately across all Microsoft cloud services.
- Azure AD (Entra ID) needs time to update group memberships.
- Intune depends on that data before it can reevaluate and apply new user-targeted settings.
This chain of dependency creates natural delays — especially with dynamic groups, which must reprocess membership rules before users are reassigned.
3. Policy Precedence and Conflict Resolution
When two user policies manage similar settings (for example, Start Menu layout or privacy options), Intune needs to determine which one takes precedence. That process happens during evaluation cycles and adds another layer of delay, especially when the user’s group assignments are changing.
4. Backend Queues and Service Timings
Intune’s cloud infrastructure batches user policy updates separately from device configurations. During peak usage periods or when multiple assignments are recalculated, user policies can sit in a processing queue before delivery to the client.
5. PolicyManager Cache Behavior
Windows’ PolicyManager component won’t overwrite existing settings until Intune provides a new confirmed payload. This means even if a user syncs, their settings remain cached until Intune’s backend officially pushes the updated configuration.
🧪 Troubleshooting and Diagnostics
If you experience slow user policy updates, these checks can help pinpoint the delay:
- Check IME Logs:
Look atC:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log.
Focus on timestamps when user policies are detected and applied. - Review Event Viewer:
Navigate toApplications and Services Logs > Microsoft > Intune > ManagementExtension
to identify sync timing and user policy events. - Verify Group Membership:
In PowerShell, run:Get-MgGroupMember -GroupId <YourGroupID>to confirm that Azure AD reflects the change. - Test a Clean Environment:
Assign a new user to a simple test policy. If the delay persists, it’s likely a tenant-wide behavior, not a misconfiguration.
💡 Best Practices to Reduce the Impact
- Keep targeting simple: Avoid overlapping policies that apply to similar settings.
- Prefer device-based targeting: Whenever possible, use device policies for faster, more predictable enforcement.
- Limit frequent group toggling: Constantly changing group membership triggers repeated evaluations and delays.
- Plan ahead: When testing user-scope configurations, allow for several hours of propagation time before verifying results.
- Document expected behavior: Set realistic expectations with your IT support team and end users.
For more advanced testing, you can script policy refreshes or token renewals to force earlier evaluation, but these workarounds are temporary and not officially supported.
🗣️ Community Insight
User-based settings rely on the user’s session lifecycle, not on the Intune sync schedule. This makes them inherently slower and less predictable than device-scoped configurations.
📘 Key Takeaways
| Category | Device Policies | User Policies |
|---|---|---|
| Refresh Trigger | MDM agent (every 30 min) | User session or token renewal |
| Speed | Fast | Slow (6–12 hours possible) |
| Scope | System-wide | Logged-in user only |
| Reliability | High | Depends on Azure AD sync and backend |
| Control | Manual sync, restart | Limited — backend dependent |
🧭 Final Thoughts
If your Intune per-user settings take hours to apply, it’s not a misconfiguration — it’s how Intune currently works. The delay stems from how user context, group evaluation, and token lifecycles interact across Intune and Entra ID.
Until Microsoft enhances how user-targeted policies refresh, admins should:
- Use device policies whenever possible.
- Plan for propagation time when testing new configurations.
- Monitor IME and event logs to confirm backend syncs are completing properly.
Patience is key here — your user policy will eventually apply, but it’s running on its own schedule.
