Microsoft Intune

Windows Autopilot oddities

By on • ( 16 Comments )

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…

Categories: Microsoft Intune, Windows Autopilot

16 replies »

  1. Hi Michael,

    Thanks for sharing this information. There certainly do seem to be more issues… 🙂
    Specifically we have discovered a few around the ESP. Support ticket numbers in case you are interested are: #15233962, #15168778, #14644415

    We also still struggle with the fact that the Intune management extension is not exposed as a cloud app in CA, meaning we have no way to exclude it from our base CA configuration. As a result of that have to wait for the device to be compliant (requires at least one reboot because of Bitlocker) before the extension can start to deploy Win32 apps and PowerShell scripts.

    Regards,
    Jan

    Like

  2. Test. Just checking if the comments need to be approved by you before they show up on the site…
    Regards,
    Jan

    Like

  3. I have a side question. We’re buying Lenovo laptops, on the box the is a ‘Autopilot product key ID’ can I use that to register the device instead of the regular method?

    Like

    • No, sorry. That bar code (which should have been labeled “Windows product ID”) can be used by CSP partners to register devices (along with the serial number), but Intune and MSfB require the full 4K hardware hash, for security reasons.

      Liked by 1 person

      • Ah, that would make our life much easier by shipping directly to end-users and avoid us as middle man for opening the box all together, end-users aren’t usually that tech savvy to run a command to extract the hw key and send us a file. Thanks for answering that, btw I subscribed to your post yet all updates landed in my spam folder

        I do have another question, I noticed today (deployed 5 autopilot PCs) that office 365 failed to deploy because the computers have office freeware installed despite checking the box to remove in intune app, am I missing something here?

        Like

      • I believe you can work around that with the option in the config.xml – not sure if that’s exposed through the Intune UI, so you may have to import your own XML (which you can build from config.office.com).

        Like

  4. Hi Michael, I did some testing regarding the ESP not catching the Win32 app installation errors and could also reproduce the behaviour on non-autopilot devices using AAD Join + automatic MDM enrollment. Support ticket is #15773555 and all relevant logs should be attached to the case. Cheers, Nicola

    Like

  5. Would love for the ESP page to work for SelfDeploying mode – I have a project with public facing MultiApp Kiosks, so enrollment control would be nice.

    Like