This blog will address one of the biggest misunderstandings I hear regarding Intune: the misconception that Windows devices ONLY receive new policies every eight hours. That belief sounds convincing, because yes… There is an eight-hour maintenance Intune sync, but in fact, that’s only a safety net!
Let me explain that safety net a bit more. As shown above, Windows performs a background Intune sync roughly every 8 hours. If nothing else happened in between, that’s when it will pull fresh policies. To understand the entire flow, we first need to examine what happens during enrollment, then move on to how change-based push notifications work, and finally, why throttling means that the first change feels instant, while the next one may not.
By the end of this blog, the eight-hour Intune sync myth is gone.
Intune Sync Faster at Enrollment
Let’s first zoom in on how policies are coming down during Enrollment. When a Windows device enrolls in Intune, it certainly doesn’t wait for the 8-hour maintenance sync to complete. During enrollment, some additional schedules are created to ensure the device PULLS all the necessary policies.
These Intune sync enrollment schedules are ONLY executed during enrollment.
Microsoft has documented this first enrollment sync behavior: during the Intune/MDM enrollment, devices check in more frequently to PULL down configuration profiles, certificates, and policies.
- Every 3 minutes for the first 15 minutes
- Then every 15 minutes for the next 2 hours
- And only after that, it shifts to the ~8-hour cycle
That behavior is critical. At enrollment, the device has no policies, no apps, nothing. If enrollment relied solely on the 8-hour maintenance cycle, the device would remain partially configured for hours. The OMADMClient (Windows Phone Provider) forces repeated check-ins until the important workloads are applied and reported back. It is the only way Intune can guarantee a device comes out of OOBE fully configured and compliant before the user is allowed to continue.
Change-Based Check-Ins
Outside of enrollment, Intune isn’t just going to wait eight hours for the next sync with Intune; it actively pushes devices to check in when something changes on the service side. Let me explain! When an admin changes something, such as a policy or a setting that impacts targeting, Intune evaluates the scope and then sends a push notification to the affected devices using the WNS.
That push message travels over the Windows Notification Service (WNS) and tells the device to check in. These are the triggers that make Intune notify devices:
- Changing targeting (adding or removing a device or user group)
- Editing a payload (changing/adding a new Intune policy or updating app assignment)
- Entra group membership changes
- Store app version updates released by the vendor
In practice, the first policy change is usually pushed down within a few minutes. From there, Intune enforces a quiet period/throttle (roughly 30 minutes per device) before sending another push. So, while it’s not instant like a remote wipe (which must always be immediate), it’s still far faster than waiting for the full 8-hour maintenance cycle. Let me zoom in on the push message itself a bit more.
How the Push forces the Intune Sync
When Intune sends a message through the WNS, the device doesn’t apply the policy directly. It wakes up the PushLaunch scheduled task.
That PushLaunch scheduled task then triggers the OMADMClient (AKA the Windows Phone Provider) task, which is the actual engine that connects to Intune and fetches the policy.
But be aware! There’s also a short delay baked in. In a previous blog (Why Intune Remote Actions Are Fast at First but Slow the Next Day), I demonstrated how Microsoft added a 5-minute buffer before the task is executed. That’s why these pushes aren’t immediate (after 8 hours), but they are still far quicker than the full 8-hour maintenance window.
We tested this with a simple example: We created a new configuration policy to lock down access to the Settings app. Within 5/10 minutes, the PushLaunch task on the device fired, OMADMClient ran, and the restriction was active. No waiting until the 8-hour sync was kicked off!
WNS: The Black Box
One important thing to keep in mind: WNS is a black box. Intune doesn’t send a policy payload directly to your device. It communicates with the Windows Notification Service, which then relays a push notification down to the client itself.
What happens inside that WNS pipeline? We don’t really know. We can confirm that Intune sent a notification, and we can confirm the device received it; however, the middle layer (WNS) is hidden. On the device side, the first visible trace is the PushLaunch task being triggered. From there, the event logs and scheduled tasks tell the story as OMADMClient starts its Intune sync.
That’s why the PushLaunch operational event log is one of the best places to check if a push notification actually arrived.
What’s Inside the Push
When WNS delivers a notification, it doesn’t carry any real policy data. What arrives on the device is just a JSON ticket, but it’s just a tiny envelope with a notification ID and some metadata.
From the logs, the WNS payload looked like this:
Breaking it down:
- notificationId → unique GUID for this push, used for correlation.
- version → schema version (1.0).
- serverPayload → string-encoded JSON that just repeats the notification ID, version, a placeholder “Payload”, and empty arguments.
That’s it. No CSP values, no settings, nothing. The push is simply a knock on the door telling Windows, “time to run the PushLaunch task.”
When the PushLaunch task is executed, it triggers the OMADMClient, which then contacts Intune, downloads the actual policies, and the CSP engine applies them by using the get-set-get mechanism.
So the next logical question is: why doesn’t every push notification come through instantly? → Answer: throttling it seems
Throttling and WNS
One thing that stands out in testing is how the timing affects policy changes made back-to-back. Here’s how it behaves today.
- The first Intune change you make (adding or editing a policy) is pushed quickly through WNS. The device usually syncs within a few minutes.
- If you make more changes inside the next ~30 minutes, Intune doesn’t send multiple pushes. Instead, those changes are bundled together and resolved the next time the device checks in from that notification (usually the maintenance window), but….
- Once the ~30-minute quiet period has passed, the next change triggers another WNS push.
This isn’t queueing in the traditional sense. Intune enforces a per-device throttle of about 30 minutes, but it can fold multiple edits into a single notification. That way, devices don’t get hammered with pushes, yet they don’t miss changes either. The result today looks like this:
- Change #1 → WNS push almost immediate
- Change #2 and #3 (<30 min later) → bundled, resolved when device responds to the same notification
- Change #4 (>30 min later) → new WNS push delivered
It’s deliberate throttling with batching, designed to prevent notification storms while still keeping devices up to date. But by the looks of it, change (aka the fast lane) is coming!!!!
The Fast Lane: Per-Device Notification Timer
Microsoft is redesigning how push notifications are handled to reduce the confusion around throttling. Instead of a rigid “first push fast, second push maybe later” model, the new design introduces a per-device notification timer.
Here’s how it works in practice:
- When a drift (change) is detected, a timer starts.
- If no further changes happen within ~3 minutes, a notification is sent immediately.
- If more changes occur, the system queues them in small increments (up to ~10 minutes).
- Once a notification is sent, the next batch is held until the start of the following hour.
That means devices still won’t get hammered with constant pushes, but the delivery is far more predictable and bounded in time.
Microsoft calls this the “fast lane” because it ensures:
- No dropped notifications – every policy change is eventually delivered.
- Bounded delays – you can expect delivery in minutes, not hours.
- Better handling of back-to-back changes – instead of one fast push and the rest being delayed, each batch gets a guaranteed delivery slot.
- Device actions stay instant – wipes, restarts, or lock commands bypass the timer and are always delivered right away.
In the future, Microsoft plans to add retries (based on importance) if a device doesn’t check in, plus configurable batching windows (5–15 minutes). Instead of relying purely on throttling, this model places devices on a time-bound fast lane for configuration drift, while keeping the immediate lane open for admin-triggered remote actions (example: remote wipe).
Don’t Block WNS
Owww… and before we forget…Some admins still think it’s a good idea to block “cloud notifications” at the firewall or by configuring a CIS baseline policy to block them.
Don’t!!!. WNS is exactly what Intune uses to wake up your devices. Block it, and the remote actions AND change-based check-ins won’t arrive. I covered this in detail here: Push notifications device query an error occurred. If your devices can’t talk to WNS, you’ve effectively killed the fast lane and left yourself stuck with the slow 8-hour sync maintenance cycle. So if you are blocking WNS, don’t complain that the S in Intune stands for speed.
Closing Thoughts
One thing is certain! Policy delivery is not stuck on a fixed 8-hour cycle.
- Enrollment is immediate
- Change-based check-ins ride over WNS and usually arrive pretty fast (if WNS throttling is not active)
- Throttling enforces a 30-minute throttle period per device
- Maintenance runs every 8 hours on OMA-DM or 3.5 hours on MMP-C as a safety net
The end result is that Windows devices are much more dynamic than most admins think, and the Intune check-in? That’s far faster than the 8 hours maintenance task everyone believes in. So that 8-hour Intune sync myth? That belongs to the past!