Windows Autopilot

Coming soon: Improvements to app installation error handling in ESP

For those of you who have been deploying apps (of any type, Win32, LOB/MSI, UWP, etc.) during a Windows Autopilot provisioning process with ESP enabled, you may have noticed that an installation failure for an app has an interesting result:  ESP will time out at the end of the configured timeout period, even if the app failed after one minute.  That’s not awful if your timeout is fairly short, but with typical ESP timeout values being configured at 60 minutes (or even longer), that can be a little frustrating – waiting for something you know has failed and being unable to make it report that failure faster.

We have been working on that, changing the ESP monitoring logic to tell you about errors when they occur.  Those changes will be available in the next Windows Insider build (20222 or higher), which should be available this week.  With those changes in place, you’ll see an error like this:


And most importantly, you’ll see that when the error occurred.  In my case, the error (which I forced by deploying an app that reports a return code that Intune will consider a failure) happened about 15 minutes into the process (as the apps before it in the list for Intune Management Extensions had to install before it got to this one that failed), and then I saw this.

Since I have “Continue anyway” enabled in my ESP profile, as well as all the other options (reset, collect logs, try again), there are choices presented to the user what to do in this case.  If they choose to “Continue anyway” it will advance to the next step in the process, which would mean user ESP if there was a failure during device ESP, or to the desktop if there was a failure during user ESP.  (The “Machine targeted!” message is actually the custom error text that I defined in my ESP profile – see for more info on that.)

You can see the app failure detail in the Get-AutopilotDiagnostics script output:


That shows that my app exited with return code 1234, hence the failure.

The goal is to backport this change to previous Windows 10 releases as well (at least 2004 and 20H2), but the timeframe for that is still undetermined.  If you have any feedback on this change, let us know (since that’s what Insider builds are for).

Categories: Windows Autopilot

6 replies »

  1. Fantastic work. What can we do in the meantime?

    In Autopilot, I’ve run across the case where an app set to device restart behavior “Intune will force a mandatory device restart” or “Determine behavior based on return codes” (with exit code 1641) will hang the Device ESP process after the reboot. Why? Well, using Get-AutopilotDiagnostics.ps1, I see that the app didn’t update from “2 (Downloading / Installing)” to “3 (Success / Installed, rc = 0)”. Everything else after the reboot installs, but because this one didn’t update, the Device ESP page times out. I’m looking for a fix (other than don’t reboot during Device ESP!).


    • We see the exact same thing, seems anything other then a 0 or 3010 code stalls out ESP after a restart. Like you the IME appears to be fully functional and installs everything else even if ESP says 3 of 10…

      We are using Hybrid join, not sure if that matters.

      We also are using 1903 (direct from vendor), and 1909 enablement deployed by CM. Haven’t noticed a difference based on version yet.

      Just updated to CM 2006, hoping the run a TS after CM client install will provide better control/results.


  2. Good to see the enhancements coming to this space. It would be even more user-friendly if instead of just error codes the ESP showed the name of the application installing (realtime) as well as the application name on failure.

    Apps (0x…) to Apps (0x…) – Notepad++

    Additionally, instead of Application (1 of 13), have it say Application (1 of 13) – Notepad++

    Similar descriptors could be put in place in the other sections where it makes sense as well.