The 8-hour Intune sync myth — and the firewall rule that makes it real

You changed a configuration profile and the device picked it up six hours later — so Intune must only sync every eight hours, right? Not quite. The fast lane is a push notification that usually lands within minutes; the 8-hour cycle is only the safety net. But one firewall or hardening decision can quietly put your entire estate on the slow lane, and make the myth true for you.

The problem

"Windows devices only get new Intune policies every eight hours" is one of the most repeated claims in endpoint management. It sounds plausible, it matches what many admins observe, and it is wrong — most of the time. Patch My PC's debugging write-up puts it plainly:

"Windows devices ONLY receive new policies every eight hours. That belief sounds convincing... There is an eight-hour maintenance Intune sync, but in fact, that's only a safety net!" — Patch My PC, Intune Policy Delivery: Debugging the 8-Hour Sync Myth

The catch: on some networks the myth is reality. If you recognise these symptoms, you are probably one of them:

• Every policy or profile change takes hours to land, on every device, consistently.
• Remote actions from the Intune admin centre — Sync, Restart, device query — arrive very late or never.
• A manual sync from Company Portal or Settings → Accounts → Access work or school works instantly, but nothing ever arrives unprompted.
• The same tenant behaves fine on devices at home or on mobile hotspots, and is only "slow" on the corporate network.

This pattern is most common in environments with strict egress filtering, TLS inspection, authenticated proxies, or CIS-derived hardening baselines — which is to say, exactly the environments most likely to be running Intune seriously.

Why it happens

Intune policy delivery to Windows is not one schedule; it is several lanes with very different latencies:

The fast lane works like this: when you change something, Intune evaluates the targeting scope and sends a push notification to the affected devices via Windows Notification Services (WNS). The notification carries no policy content — it is just a wake-up ticket. On the device, the PushLaunch scheduled task receives it (with a built-in buffer of around five minutes) and starts an OMA-DM session via OMADMClient, which downloads the actual changes. First change after a quiet spell: typically five to ten minutes. Subsequent edits inside the ~30-minute quiet period get bundled. Patch My PC also notes the newer declared-configuration channel (WinDC/MMP-C) keeps its own maintenance cadence of about 3.5 hours.

The firewall rule that makes the myth real

All of that depends on the device being able to hold a connection to WNS. Block it — with an egress rule that drops *.wns.windows.com, a TLS-inspecting proxy that breaks the long-lived notification channel, an authenticated proxy WNS cannot traverse, or the CIS-recommended "Turn off notifications network usage" policy — and change-based check-ins and remote actions simply never arrive. As Patch My PC puts it, "you've effectively killed the fast lane and left yourself stuck with the slow 8-hour sync maintenance cycle." Everything still works, eventually, because the maintenance sync is a genuine safety net. That "eventually" is why blocked WNS is arguably the number-one root cause of "Intune is slow" complaints: the estate is not broken, so nobody investigates — it is just permanently on the slow lane.

The fix

You can confirm and fix this today with no third-party tooling.

1. Prove or disprove push delivery. On a test device, make a trivial edit to an already-assigned profile in the Intune admin centre. On the device, open Task Scheduler and watch \Microsoft\Windows\EnterpriseMgmt\<enrolment GUID>\PushLaunch — if the fast lane works, its Last Run Time updates within minutes and the DeviceManagement-Enterprise-Diagnostics-Provider → Admin event log shows a new OMA-DM session. If PushLaunch only ever fires on the ~8-hour cadence, the push is not arriving. Note: a manual sync working proves nothing here — that is client-initiated and does not use WNS.
2. Test WNS reachability from the affected network. From an affected device: Test-NetConnection client.wns.windows.com -Port 443. Repeat per VLAN/site — this problem is often network-segment-specific.
3. Fix the firewall and proxy path. Per Microsoft's WNS allowlist guidance:
   • Allow outbound TCP 443 to *.wns.windows.com (the client-side FQDN devices use to receive notifications).
   • Allow the identity endpoints login.microsoftonline.com and login.live.com.
   • Allowlist by FQDN, not IP — Microsoft states the FQDNs will not change, while the VIP/IP ranges change periodically (they are published as a downloadable XML on the Microsoft Download Center if you have no choice).
   • Exempt WNS traffic from TLS inspection, and do not force it through an authenticated proxy: Microsoft's own guidance is that WNS "may not support proxies" and that a direct connection gives the best results.
   • If your cloud services also send notifications, the service-side FQDN is *.notify.windows.com — but for the Intune fast lane, the client-side entries above are what matter.
4. Check for the self-inflicted version. Hardening baselines derived from the CIS benchmark often enable Turn off notifications network usage (Computer Configuration → Administrative Templates → Start Menu and Taskbar → Notifications; registry value NoCloudApplicationNotification under HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\PushNotifications, or the Notifications/DisallowCloudNotification CSP). On an Intune-managed estate this policy disables the very channel Intune depends on — review whether you can exclude managed devices from it.
5. Re-test and set expectations. After the fix, repeat step 1. Remember the ~30-minute bundling window: a second edit made straight after the first is supposed to wait for the next check-in. Don't diagnose a delay until the quiet period has elapsed.

How Decolla handles it

Honestly: Decolla cannot make Intune's delivery pipeline faster, and neither can anything else — Decolla provisions devices through your own Intune/Autopilot tenant, so its deployments ride exactly the same WNS-plus-maintenance-sync lanes described above.

What Decolla does do is make sure you find out about a blocked fast lane before it turns into a mystery. Its pre-flight environment check, run before a deployment plan executes, includes verifying that the WNS endpoints are reachable from the environment — so an estate stuck on the 8-hour slow lane is flagged up front rather than discovered later as "Intune is slow". This is a point-in-time check at deployment time, not continuous monitoring.

Beyond that, every Decolla deployment starts from a written, itemised plan that records the delivery method for each item, which turns "has it landed yet?" from a guess into a checkable question. Decolla is currently pre-launch, with a waitlist open at decolla.app — but the fix above stands entirely on its own.

Sources

• Patch My PC — Intune Policy Delivery: Debugging the 8-Hour Sync Myth
• Microsoft Learn — Policy refresh intervals in Microsoft Intune
• Microsoft Learn — Adding WNS traffic to the firewall allowlist