So, ESP is waiting for Intune Management Extensions (IME) to indicate what it wants to have tracked. In the future, there will be another one for ConfigMgr so that we can track ConfigMgr “stuff” during ESP as well. 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). But there are other things that may need to be tracked, so an extensible model was created for Windows 10 1903. With Windand previous releases, ESP only tracked one policy provider: the MDM service itself, Intune. But what are policy providers and what do they do? Simply put, these are “things” that tell ESP what policies it needs to track. Basically, ESP is waiting for “policy providers” to install before continuing. The last two sentences (highlighted) are what are important here. Once all the registered policy providers are marked as Completed or NotRequired, the ESP progresses to the device setup phase. 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). The node should be given a unique name for the policy provider. Represents a policy provider for the ESP.

This node is supported only in device context. More specifically, it’s tied to this particular CSP setting:ĮnrollmentStatusTracking/DevicePreparation/PolicyProviders/ ProviderName And the answer is interesting – yes, ESP is waiting longer while “Preparing your device for mobile management” in Windows 10 1903.īut 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. 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.

Upilot moble app