Win32 Apps not Installing During Autopilot Device Preparation

This blog started with a support case from a customer who ran into an issue where Autopilot Device Preparation (AP DP) got stuck at “Installing required apps and scripts.” Strangely, none of the Win32 apps actually assigned in the AP DP profile or any PowerShell scripts seemed to install at all.

We decided to dig into it. What we found was a breakdown in the SLDM Provider phase and a strong connection to how many Win32 apps were assigned as required. In this blog, we’ll walk through why SLDM never completes, how that blocks the rest of the provisioning process, and how assigning too many win32 apps as required (even if they’re NOT marked as required in the AP-DP profile!!!) might be the root cause.

Introduction

Before enrolling your device with Autopilot Device Preparation, you need to setup the AP-DP profile and define the only apps and scripts you won’t to have installed during AP-DP

With the profile created, you start the Autopilot Device Preparation enrollment. The device moves through the initial steps. But after installing the management extension, it gets stuck on “Installing required apps and scripts for your organization”

It sits there for 20, 30, maybe 40 minutes, depending on how long you configured the setting: “Minutes allowed before showing installation error” in the Autopilot Device Preparation profile, until it finally gives up and throws the error: We can’t complete device setup.

The first thing we did was check out the new AP-DP Monitor functionality

With the Autopilot Device Preparation monitor showing us nothing really useful (except the policy installation that failed), we took a closer look at the Intune Management Extension AppWorkload log to determine which app was the culprit; however, the IME AppWorkload log was quite empty.

No mention of Win32 apps, no scripts, no trace of anything getting installed. One thing was for sure It wasn’t the Managed Installer issue (we covered that here). This time, the issue seemed to have occurred earlier in the Device Preparation chain, to be precise, during the SLDM phase.

However, before we zoom in on what went wrong, it’s helpful to understand how Autopilot Device Preparation is structured behind the scenes. It doesn’t just fire off scripts and app installs randomly; everything happens in a strict sequence of four internal phases.

The Four Phases of Autopilot Device Preparation

So let’s discuss the four phases of AP-DP first, then. As mentioned above, Autopilot Device Preparation (AP-DP) follows a strict execution order made up of four internal providers:

1. StandardUserProvider – Removes the Entra user from the local Administrators group, updates ESP status text, and sets registry markers.
2. SldmProvider – Requests required apps, monitors the provisioning state, checks for reboot needs, and signals MDM setup completion.
3. PowerShellScriptProvider – Runs device-assigned PowerShell scripts.
4. Win32AppProvider – Installs Win32 apps assigned to the device.

Each batch phase only runs if the one before it completes successfully. In this case, the SLDM phase didn’t finish successfully, and after the time-out, it was cancelled.

With the SLDM provider batch being canceled, Win32 apps and PowerShell scripts never even begin. Let me start explaining each batch a bit more.

The StandardUserProvider

Before anything else happens in the Autopilot Device Preparation batch flow, the StandardUserProvider is called. Its job is to configure the account type by removing the Entra user from the local Administrators group, depending on the Autopilot-DP profile.

Once it is done, it will update the ESP status message to “Installing required apps and scripts for [company name]”, set key registry flags, and signal readiness for SLDM to start. If this StandardUserprovider doesn’t complete successfully, none of the others will run. (which we noticed in this blog as well)

In our case, StandardUserProvider batch finished fine. The local administrator group was updated. The Autopilot Device Preparation enrollment proceeded, and the following item in the batch order was the SLDM Provider.

The Autopilot Device Preparation SLDM Provider

Next comes the SldmProvider, short for Stateless Device Management. Its role is to initiate the provisioning process by requesting the list of required apps, monitoring the installation state reported by the MDM agent, and sending progress signals back to the service. It acts as the key orchestrator for MDM provisioning during Autopilot Device Preparation. If you want to take a small peak yourself at how this looks like in the IME code, you will need to use the dotPeek Tool as I am explaining in this YouTube video.

Here’s how the SLDM process works in practice:

SLDM Under the Hood – Visual Walkthrough

To make things more concrete for people who don’t like mermaid flow, here’s what the SLDM process looks like when you trace it from the network and CSP activity:

Let me walk you through each step so it becomes clear what broke down

Step 1: Autopilot Device Preparation Execute Provisioning Request

The device sends a POST request to r.manage.microsoft.com with the DevicePrep payload including the ExecutingProvisioning alert. This initiates the Device Preparation phase in the cloud service.

Step 2: Progress CSP is sent over to the device.

The service responds by delivering a SyncML payload with the CSP node:./Device/Vendor/MSFT/DevicePreparation/MDMProvider/Progress.

This CSP above contains the serialized progress blob, listing each workload (workloadId) and its current state (DeploymentWorkloadState), starting with workloadState:1 (InProgress).

Step 3: Autopilot Device Preparation Workload Deserialization

The SLDM provider running in the Intune Management Extension reads the Progress blob, deserializing it into in-memory DeploymentWorkloadDto objects.

It tracks fields such as:

• workloadId
• workloadState
• friendlyName
• and additional metadata like timestamps or error codes.

This data becomes the working set that SLDM uses to determine the provisioning progress

When we examine the progress blob sent over in step 2 more closely, we will notice that the WorkloadState:1 indicates the SDLM is in progress.

Step 4: WorkloadState Change

If the Intune back-end successfully evaluates app assignments and policies, and determines that a workload has completed, it re-sends the same Progress CSP with an updated state:

This means the workload is Completed, and the SLDM provider will interpret it as ProvisioningComplete. As shown below, we could also get some other results.

Step 5: Autopilot Device Preparation POST Completion Signal

Once all workloads have reached a ProviderResult of ProvisioningComplete (as mapped from workloadState), the SLDM provider sends a final POST to r.manage.microsoft.com, signaling that provisioning has finished successfully.

Failure Case: Progress CSP Never Updates to Completed

If the updated Progress Blob never arrives, meaning no workloads transition to workloadState:2, the SLDM provider keeps polling, waiting for completion.
Since that state change never happens, the final ProvisioningComplete signal is never sent back to the service, and Autopilot Device Preparation just hangs until timeout (depending on your settings), returning:

This issue was only observed with Autopilot Device Preparation (AP-DP), not classic Autopilot (APv1). That led to the suspicion that EnrollmentTimeGroup (ETG), introduced alongside AP-DP, plays a role. ETG may delay or suppress the policy grouping logic needed to generate the correct Progress CSP with workload completions.

Enrollment Time Grouping and Autopilot Device Preparation

Enrollment Time Grouping was designed to reduce redundant processing. Instead of evaluating each app and assignment individually per device, the backend groups devices together at enrollment time and evaluates shared assignments once.

The goal is to optimize app targeting logic and reduce strain on the backend. The moment the device is enrolled (Entra join), it will be automatically added to this enrollment time group in the background.

All apps that are assigned to this enrollment time group will be processed during the AP-DP Enrollment. However, we noticed that the Win32 apps weren’t really targeted at this group, but at ‘All Devices’ instead. That made us realize something else must be going wrong.

The Win32 App Limit and Autopilot Device Preparation

That’s when we began investigating how many apps could actually be assigned as required without breaking AP-DP. When too many Win32 apps are marked as *required for all devices, the entire AP-DP provisioning cycle stalls. We tested this in our lab by gradually assigning large numbers of apps.

*Updates are marked as required for all devices to ensure that if the App exists on any device, it will be updated automatically.

At first, everything worked fine. But as the number increased, Autopilot Device Preparation began to fail consistently. The backend logic stopped scaling. The Progress CSP with workloadState: 2 never arrived on the device. Without it, the SLDM provider timed out and returned:

After spending a lot of time in our LABS, we found the limit!!!!! The exact number of maximum assigned apps was 256. Sounds like a human set limit. 256. It also sounds like a coincidence, given that I published the upcoming fix for the BitLocker 256-bit issue during AP-DP :)…

Once you hit 257, AP-DP provisioning fails. The device never receives the updated progress state (workloadstate:2), and the Autopilot Device Preparation enrollment will fail!

But We Didn’t Assign 257 Apps to AP-DP… Did We?

Let’s be clear… we didn’t assign 257 apps to the Autopilot Device Preparation profile. (which is not even possible… ) In fact, we only scoped a single Win32 app, a single Store App and the MS365 apps in that AP-DP profile.

Only those three apps should’ve been evaluated and installed during provisioning. The rest were just marked as required for all devices in the assignments, but they weren’t included in the actual AP-DP config.

So the bottom line…they shouldn’t have been involved at all!

But clearly, the backend didn’t care. It evaluated everything, regardless of what the ap-dp profile told it to focus on. That’s why this issue was so confusing at first. It looked like a single app failing but behind the scenes, the whole provisioning logic was choking on the full set of required apps (which exceeded the 256 apps).

What You Can Do About It

A practical workaround until Microsoft is going to fix it, could be: Defer non-critical apps until after the AP-DP enrollment. That way, SLDM has a better chance of completing and handing off control to the next stage.

We can do so by ensuring that all Win32 App updates are configured to be excluded for the Enrollment Time Group. With it, the Win32 App Updates are not configured as required for devices that are enrolling.

From then on, we can remove the device from that group the next day with the Azure Runbook. Once the device is no longer a member of that group, the Updates for the Win32 Apps are no longer excluded and will be installed on all devices that have the app installed once it checks in.

Microsoft their Response

It’s pretty obvious we contacted Microsoft about this issue. So far, there’s no public documentation or fix available, but if we’re able to share more in the future, we’ll update this blog.

Conclusion

While Microsoft hasn’t published an official limit, internal observations suggest that provisioning logic during Autopilot Device Preparation might not handle high volumes of Win32 app assignments gracefully, particularly when app status reporting is involved. At >256 app assignments, things stop scaling predictably.