u/unoquattro

Hey everybody,
recently, we've seen many Autopilot deployments (Win11 24H2) failing with error code 0x87d1041c in the device setup phase after the first user login.

After reviewing the logs, we found out that the OOBE update KB5095189 enforced a restart. Unfortunately, this restart happens in parallel to an ongoing Win32app installation. After the restart, the "interrupted" app is not detected => Error, because the app is one of the blocking apps in our ESP profile.

The devices were all pre-provisioned. Our colleagues turned them on and we could see the automatic app detection and update installation before any user interaction. After the user login, we could see the error in the device setup phase.

Does this issue sound familiar to someone else? Is there anything we could do?

Hey everyone,
in one customer environment, we re using AutoPilot + Pre-Provisioning.
Since the Pre Provisioning is done by another service provider, many devices are currently still in the storage while the PreProvisioning was done ~mid of may.

Therefore, some colleagues are "preparing" the devices again. Basically, they start the device without any further interaction so it stops at the region/keyboard screens. In the logs (AppWorkload.log), we can see that all (5 in total since mid of may) the updated Win32 apps started to get installed. So far, so good.

Unfortuntely, some of the prepared devices failed on monday morning.
What happened? They were all "prepared" on Friday afternoon for approx. 1h10min - before the weekend, the colleagues shutted down all devices. That time was not enough to finish all the installations in the back for all the clients. Some of the clients, where the installation did not go through, failed on Monday during ESP after an user logged in. We could see that the detection of the remain app failed bcs the installation was not complete on Friday - even if it got installed correctly a few minutes later, but the error remained.

One reason of the missing installation on Friday was that there is a delay of an hour before the last application gets installed. And thats even if the same app was detected as not installed in the previous app discovery round. Our current assumption is that the IME Win32App poller time interval is re-setted by an Win32 app which requires a soft reboot. It kicks in exactly after an hour and then starts the new round - then the whole process including detection, download and installation works just fine. As long as you don't interrupt the installation...

We also observed that a soft reboot requirement during manual installations did not lead to any re-runs or further delays.

Does this behaviour sound familiar to someone? How do you treat devices being pre-provisioned a while ago to minimise waiting times for your users?

Thanks in advance :)