[ad_1]
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 https://oofhours.com/2020/06/23/you-can-now-target-esp-profiles-to-devices/ 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).
[ad_2]
Source link
