It’s a question that I’ve been asked a number of times, and one that I actually asked myself when doing initial tests with Windows 10 1903.  And the answer is interesting – yes, ESP is waiting longer while “Preparing your device for mobile management” in Windows 10 1903.

But what is going on during that time, and why did it change in Windows 10 1903?  The mystery is related to the new EnrollmentStatusTracking CSP that was introduced in Windows 10 1903.  More specifically, it’s tied to this particular CSP setting:

EnrollmentStatusTracking/DevicePreparation/PolicyProviders/ProviderName
Optional. This node is supported only in device context.
Represents a policy provider for the ESP. The node should be given a unique name for the policy provider. Registration of a policy provider indicates to ESP that it should block in the device preparation phase until the provider sets its InstallationState node to 2 (NotRequired) or 3 (Completed). Once all the registered policy providers are marked as Completed or NotRequired, the ESP progresses to the device setup phase.

The last two sentences (highlighted) are what are important here.  Basically, ESP is waiting for “policy providers” to install before continuing.  But what are policy providers and what do they do?  Simply put, these are “things” that tell ESP what policies it needs to track.  With Windows 10 1809 and previous releases, ESP only tracked one policy provider: the MDM service itself, Intune.  But there are other things that may need to be tracked, so an extensible model was created for Windows 10 1903.  Right now, there is one additional policy provider that leverages that extensibility:  Intune Management Extensions, used to install Win32 apps (which are presently tracked by ESP) and to run PowerShell scripts (not presently tracked by ESP).  In the future, there will be another one for ConfigMgr so that we can track ConfigMgr “stuff” during ESP as well.

So, ESP is waiting for Intune Management Extensions (IME) to indicate what it wants to have tracked.  While standard MDM policies are received by the Windows 10 MDM client directly, Win32 apps are sent through a separate management channel between the IME Agent and the Intune service, so there are two distinct steps in the process:

• IME is installed.  This is delivered as an MSI app installed through the MDM client.
• The IME service talks to Intune to figure out what Win32 apps need to be installed.

Once those two steps are done, ESP will see (via the InstallationState property of the ESP) that “all” of the providers are finished installing and it will then continue on to the “Device Setup” phase of the ESP tracking process, where it monitors the full list of blocking policies provided by each provider (Intune/MDM and IME).  This also enables the ESP to get a complete count of policies to be tracked before it starts, so you don’t see any weirdness with changing numbers.

Alright, so we now know what’s going on:  It’s waiting for IME to install and indicate that it’s ready to go.  But there’s more to the story.  Go back a few lines to one key point: It’s waiting for IME, an MSI, to install.  You might think that because the ESP isn’t yet tracking the progress that there are no policies being processed, but that’s definitely not true.  The device has synced with Intune and has begun processing all of those policies, even before ESP gets to the “Device Setup” phase.  Odds are good that it will have completed the installation of some (if not all) MSI apps and certs and most (if not all) device configuration settings before IME (one of the MSI apps) is done.  And Office may be installing already too.  So this is definitely not idle time – the device is being provisioned in the background.

Here’s a hypothetical view of what this might end up looking like (with times in MM:SS):

• 00:00 : ESP starts up after successful MDM enrollment.
• 00:01 : ESP starts waiting for all policy providers (i.e. IME) to install.
• 03:00 : Intune delivers a list of policies to process (including MSI apps, Office, device configuration policies, certs, etc.) and tells ESP what to track.
• 03:01 : MDM client starts applying all device configuration policies.
• 03:02 : MDM client starts enrolling certs.
• 03:03 : MDM client starts downloading MSI #1 (which is not IME)
• 03:03 : MDM client starts installing Office
• 05:00 : MDM client finishes downloading MSI #1 (which is not IME) and begins installing it.
• 05:01 : MDM client starts downloading the IME MSI.
• 08:00 : MDM client finishes downloading the IME MSI and begins installing it.
• 10:00 : IME gets a list of Win32 apps and tells ESP that it is done.
• 10:00 : ESP progresses to the “Device Setup” phase and begins showing progress of all the items (with some already showing that they are complete).
• 10:01 : IME starts installing Win32 apps

That is roughly the amount of time I’ve seen in my tests, although I haven’t actually verified if any of my MSIs installed before IME (hard to check from an airplane, from where this blog is being written).  I would suggest not mixing MSIs and Win32 apps anyway – move everything to Win32 apps for additional flexibility (e.g. dependencies) and capabilities (e.g. support for Delivery Optimization for peer-to-peer content sharing – too bad MSI installs don’t support that, as the IME install would benefit).