Sometimes I can’t explain them, but I can at least pass them on so that you don’t tear your hair out trying to figure out what’s going on.
- The enrollment status page doesn’t track PowerShell scripts executed via Intune Management Extensions. They will be sent to the machine along with all the other policies, and if you are installing a bunch of apps it’s quite possible that the PowerShell scripts will install. But it’s not guaranteed; they may continue running after ESP has completed.
- The enrollment status page doesn’t actually track device configuration policies. You might notice that it shows “0 of 1” for security policies, and that quickly changes to “1 of 1.” But if you have created multiple device configuration policies in Intune, as well as security baselines, they aren’t explicitly tracked. Again, if you install any apps it’s quite likely that they will be processed and applied before ESP completes.
- Win32 app install failures cause ESP timeout errors. If you install a Win32 app via Intune Management Extensions and that app install fails, typically with an unexpected return code, that error isn’t reported by the ESP. (You will see it in the Intune Management Extensions log and in the Intune portal.) Instead, the ESP will always wait until it times out.
- Win32 app install detection rule errors cause an ESP timeout error. If you install a Win32 app via Intune Management Extensions but you don’t have the detection rules right, Intune Management Extensions will assume the app failed to install and will try to install it again – over and over again. (I’ve had a number of people say “but it works fine when not using ESP. Well sure, but Intune is still installing it over and over again, you just don’t notice. Make sure you get your detection rules right.)
- ESP settings can be complicated. Currently Intune targets ESP settings to users, not to devices. But there are some scenarios (e.g. white glove, self-deploying mode) where there isn’t a user. In those cases, ESP will use a default set of policies. So you might expect to see longer timeouts or a list of filtered apps, but that doesn’t actually happen. (There’s more to it, but it gives me a headache trying to reason it all out, so I’ll stick with the simple explanation.)
- Some Windows Autopilot scenarios (e.g. self-deploying mode, user-driven Hybrid Azure AD Join) will fail with an enrollment error (80180005) if you assign the Autopilot profile via Microsoft Store for Business instead of through Intune. So don’t assign profiles via Microsoft Store for Business.
That’s all I can think of right at this moment, but I’m sure there are more…