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:
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).
Categories: Windows Autopilot
I know that ESP is ExtraSensory Perception, but what’s CSP?
CSP = Configuration Service Provider. Basically, the MDM stack leverages CSPs, which are kind of like modules (think of them like a DLL) that provide specific MDM policies.
Before I open a MS support case on this same topic. Michael do you know if this is a known bug as devices on 1903 are now taking an extra amount of time to complete through the ESP compared to same steps on 1809.
I don’t know of any bugs. The biggest change is that ESP is now tracking Win32 apps (Intune Management Extensions) so you will now notice when Win32 apps aren’t set up correctly (e.g. incorrect detection rules).
The IME on 1903 is causing us a lot of grief in combination with how we have Intune Compliance policies and CA configured. It appears that the IME user sync keeps failing because the device is not compliant and it basically retries until it reaches the ESP timeout value configured (e.g. 60 minutes). So even if there is nothing at all targeted to the user through sidecar, the Account stage will take a long time to finish.
(To confuse matters even more, if the ESP is configured to wait for ‘All’ apps to install, then the ESP will be unable to complete and get stuck in an endless sync retry loop even though NO apps at all are assigned to either user/device)
With 1809 this was not an issue, looks like the IME user sync did not retry if it failed, meaning there was no delay.
My thinking is that if we could exclude the IME from CA this problem would go away. And yes, we do have an open case about this: #14644415. Any thoughts on how we can make sure CA does not break the Autopilot experience?
I read through the case. It’s definitely related to the new IME integration, just not sure what the best solution is yet. I pinged the engineering teams to see if they have any ideas.