I talked about the behavior of the Windows MDM stack in a blog post about a year ago.  The quick recap:  When a device first enrolls in Intune, it will initiate an MDM sync (i.e. ask Intune to send a list of new policies, apps, certs, etc. that need to be process) every 3 minutes for 15 minutes, then every 15 minutes for two hours, then every 8 hours from that point onward.  There will also be an MDM sync when the user signs in (and there can be some additional ones too, sent to alert the MDM service about certain events, e.g. an LOB app install, but that’s a little outside of the scope of this conversation).

But my experience with this setup goes back almost a year and a half further (so 2.5 years total – yes, things can take a long time sometimes).  When investigating why the Windows Autopilot provisioning process was taking longer than expected, there was a gotcha:  It would typically take a second MDM sync before Intune would send the list of policies.  That’s no big deal for the device ESP, but it gets more interesting for user ESP.

Let’s look at an example scenario where you install a bunch of apps during device ESP.  What happens if that takes more than, say, 20 minutes?  Well, going back to the MDM sync interval, that would mean the every-three-minute syncs would have already completed, and now the MDM syncs would be occurring every 15 minutes instead of every three minutes.  And when the user signs in, a sync would be initiated right away and then the next one would occur between zero and 15 minutes later, so averaging about 7.5 minutes later.  What does the user see during this time?  All the user ESP (“Account setup”) categories will just stay at “Identifying” for that whole time:

What’s going on in the background?  Absolutely nothing, it’s just waiting for that next background MDM sync to happen.  (Imagine if it took more than 2 hours and 15 minutes for device ESP to finish.  Then the syncs would be running every 8 hours, so on average there would be a four hour delay.  Thankfully, most devices don’t take that long for device ESP to finish.)

Alright, so what can we do about this, to get rid of that extra wasted time?  We can do the MDM sync more frequently, like every three minutes, until Intune tells us that all policies have been received and no more are expected (at least until the next normal scheduled sync).  So we added code to ESP to do exactly that.  But that code was checked in after the release of Windows 10 version 2004, so that needed to be backported to the previous releases, where it is included in cumulative updates that you can install:

• For Windows 10 1903 and 1909, install the April 21st 2020 cumulative update or any later one.
• For Windows 10 2004, install the September 3rd 2020 cumulative update or any later one.
• For Windows 10 20H2 or above, this new functionality will be included by default.

There can still be a little delay (half of three minutes on average, so 1.5 minutes), but that’s quite manageable in comparison.

Interestingly, this functionality addresses another challenge that wasn’t even something we had thought of at the time.  And “time” is exactly the right word here:  Let’s say a device boots up with the “wrong” time (e.g. the real-time clock in the PC is set to the right time, but the time zone of the OS doesn’t match) and then the time syncs (e.g. after a reboot with Hybrid Azure AD Join, when the device fixes its time via a time sync with an AD domain controller).  That sounds fairly harmless, but it has an odd side effect:  The MDM syncs that are run via scheduled tasks now don’t run, either because the time they have been configured for hasn’t arrived yet (time went backwards) or has already passed (time went forward).  But with the new ESP polling logic in place, we keep polling every 3 minutes regardless of what happens with the scheduled tasks, so everything keeps working fine.  So if you are seeing ESP timeouts that don’t make sense and logs show the time shifting around, make sure you have those cumulative updates preinstalled.