I don’t blog about Intune nearly as much as I used to, now that I no longer work for Microsoft and have a greater focus on the Apple ecosystem (which, to be fair, Intune still plays a pretty significant role with iPad/iPhone management).
However, I like to keep across what is happening in this space and I saw a great tweet earlier this week that touched on one of the age old complaints about Intune – the perceived slowness of policy synchronisation (especially compared to other MDM such as Jamf). The tweet came from Rudy Ooms who describes himself as:
Content Creator at Patch My PC | Reverse engineering Intune and Windows internals. Sharing what actually happens under the hood.
Back in 2019 I shared a similar blog post from Oliver Kieselbach entitled New To Intune As An MDM? Read This Blog Post First! – SamuelMcNeill.com (which is still a good read), where Oliver dived into how policy syncs work. In this newer post from Rudy, he tackles similar ground but with a view 6yrs on (wow, time flies!) and as always, I encourage you to read the original post in full:
Intune Sync and Policy Delivery: Debunking the 8 Hour Myth
Rudy does have a video overview of this topic if you’re more into listening and watching than reading:
I’ll share a few highlights from the post that are pertinent in my view, starting with:
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
Those first two bullet points are generally pretty well understood and most IT Pros will have seen this frequent sync and update during the first OOBE workflow (Out Of Box Experience).
Rudy correctly focuses on “Change Based Check-ins” with Intune and has even created a great diagram to help explain that:
To expand on that, he talks about the role of the Windows Notification Service (WNS) which functions in a similar fashion to Apple’s own Push Notification Service (APN – Configure devices to work with APNs – Apple Support (NZ)). As explained by Rudy:
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.
The blog includes some interesting testing data showing that the WNS is somewhat of a ‘black box’ in terms of how it operates and where buffers can come into play between a push of a policy change and execution on the device (again, read the full blog on Rudy’s site).
But What About Throttling, You Say?
Something that many frustrated IT Admins have suspected and/or complained about is the preception Microsoft throttles Intune changes to reduce load (either for the Azure cloud or the endpoint). Rudy’s post goes into this in some detail, explaining how the first changes are almost immediate and then subsequent rapid changes are bundled together and throttled:
- 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
Whilst this may make a lot of sense for Microsoft, for IT Admins that are perhaps making rapid changes to configurations it can be a source of intense frustration. Of course, in a perfect world IT Admins are cool, calm and collected at all times and make all of their policy configuration changes with a single update. However, that rarely matches the often frenetic pace which busy IT Admins are required to work at and knowing that changes are being bundled and throttled is often a suboptimal experience.
It does sound like there is some work being done by Microsoft to redesign this with something called “Fast Lane” that is broken down in the blog – check it out.
Final Thoughts
It can be very hard to change perceptions and the old adage of “perception vs reality” is very real when it comes to Intune sync speed. Dealing far more regularly with Jamf and macOS/iPadOS these days than Intune and Windows, I can say that in terms of speed of policy sync and responsiveness it really does feel like Jamf is a Ferarri and Intune can be a Bambina stuck in rush hour traffic.
However, Rudy’s blog goes a long way to showing that perception is often just that: perception. (Again, read the original post in its entirety – it’s definitely worth it)
Ultimately, it’s a great thing if Windows and Intune become increasingly more responsive as managing endpoints from the cloud is a good thing for everyone. With that, a final graphic from Rudy’s blog to visualise timings:
