For about eighteen months, anyone running App Control for Business with a managed installer policy in Intune had to make an uncomfortable choice at provisioning time. Turn the managed installer on, and Win32 apps got skipped during Windows Autopilot device preparation. Leave it off, and you exposed the endpoint during OOBE. The official Microsoft Learn “known issues” page literally told admins to disable the managed installer opt-in if they wanted reliable app reporting. That workaround was painful, and it forced a lot of teams to delay App Control rollouts.
On April 10, 2026, Microsoft shipped the fix. The managed installer policy now applies during Autopilot device preparation itself, before Win32, Microsoft Store, and Enterprise App Catalog apps attempt to install. The desktop hands off to the user only after the trust chain is in place. If you skimmed the April What’s New post and missed it, you missed one of the more consequential plumbing changes of the quarter.
This article walks through what actually changed in the flow, why the old behavior broke, what you need to verify in your tenant before you rely on it, and a concrete migration sequence for teams that have been running without managed installer to avoid this exact bug.
What broke before April 10, 2026
The original Autopilot device preparation (AP-DP) pipeline had a sequencing problem. Device preparation registered the device, applied Entra join, delivered scripts and apps, and then handed off to the user. The managed installer policy, however, was treated like any other endpoint security policy. It got delivered once the device reached a steady state.
If you ran App Control for Business with a managed installer opt-in, AP-DP detected the active policy at the tenant level and refused to push Win32 or Enterprise App Catalog apps during OOBE. The official behavior was for the device preparation status report to mark those apps as “Skipped”. The apps did eventually install after the first desktop session kicked off and the Intune Management Extension picked up the policy. That meant the provisioned device looked “done” on screen while security agents, browser baselines, and productivity suites were still trickling in behind the scenes.
Reporting made things worse. Patch My PC documented cases where AP-DP enrollments appeared green in the admin center, but the Win32 app reporting downstream was either missing or wrong. Support tickets got noisy. Engineers spent cycles chasing phantom failures that were really just this sequencing gap.
Microsoft’s official recommendation during that period was blunt: disable the managed installer opt-in if you wanted clean AP-DP reporting. That works as a workaround, but it leaves App Control in a partial state and creates an operational gap most CISOs will not tolerate for long.
What actually changed on April 10, 2026
The fix rewires the OOBE sequence so the managed installer policy arrives first. Before any Win32, Store, or Enterprise App Catalog app starts installing, AP-DP now applies the managed installer trust so the Intune Management Extension is already recognized as an authorized installer. The app install phase then executes under a policy that trusts those installers, which removes the original reason apps were skipped.
A few things worth flagging:
The change applies to both user-driven and automatic AP-DP flows. Windows 365 provisioning that uses the automatic flow benefits in the same way, which matters if you run Cloud PC fleets that need baseline security posture before the user connects.
The fix does not require you to reauthor your App Control policy. If you already have a managed installer configured and assigned, the new OOBE behavior picks it up. That said, the August 2025 split of the tenant-wide managed installer into group-targeted assignments is still in effect. Make sure your AP-DP device groups are included in the managed installer assignment, or the policy will not reach the device during preparation.
Reporting changes too. The “Skipped” status for Win32 apps in the AP-DP deployment report should disappear for new deployments. If you still see “Skipped” in your post-April data, that usually signals a group scoping mismatch, not a regression.
The new AP-DP sequence in practice
Here is the sequence after the April change, written the way most engineers want to see it:
The device boots into OOBE and hits the AP-DP profile. The Entra join completes and the enrollment hooks fire. The Intune Management Extension is installed. The managed installer policy (App Control for Business configuration that designates IME as an authorized installer) applies. Device targeted configuration profiles and scripts start processing. Win32, Microsoft Store, and Enterprise App Catalog apps assigned to the AP-DP policy install under the protection of the managed installer trust chain. The enrollment status page completes, and the user reaches the desktop.
Two practical points. First, the “up to 25 apps” AP-DP ceiling from January 2026 still applies, so your provisioning app set cannot sprawl. Second, deployment timeouts become more sensitive now because more work happens inside OOBE. Review your AP-DP timeout settings and extend them modestly if you are delivering the full 25 apps with heavy payloads.
A clean migration path if you had disabled managed installer
If your team followed Microsoft’s earlier guidance and disabled the managed installer opt-in to get AP-DP reporting to behave, you have some cleanup work. Do not re-enable managed installer blindly in production. Use this sequence instead.
Start in a dedicated test tenant or a tightly scoped pilot ring. Confirm you are running Windows 11 24H2, or 23H2 / 22H2 with KB5035942 or later, on the AP-DP target devices. The fix depends on recent Autopilot plugin updates that ship with those builds.
Rebuild your managed installer policy with explicit group targeting. Use a dynamic device group that reflects your AP-DP scope, and assign both the App Control for Business configuration and the managed installer policy to that group. Avoid tenant-wide assignment unless you have validated the downstream impact on existing fleets.
Re-enable the managed installer opt-in only after you have confirmed the AP-DP policy groups are fully populated. A common mistake is to enable opt-in before the AP-DP device group is hydrated, which can leave a narrow window where OOBE machines fall outside the managed installer scope.
Run a provisioning test with a representative Win32 app set. Validate three things in the AP-DP deployment report: enrollment completes, apps report as “Succeeded” rather than “Skipped”, and the managed installer shows as applied in the device’s App Control for Business policy list. If any of the three is off, stop and check group membership before expanding.
Move to a small production pilot of ten to twenty devices before you push the change organization-wide. Watch your Helpdesk queue for the next seven days for any anomaly in application reporting or Defender / Application Control events.
Gotchas that still exist
The April fix does not eliminate every pitfall. A few items to watch.
Enterprise App Catalog apps now install during OOBE, but they still rely on the Windows Package Manager stack underneath. If your network path to the EAC CDN is slow or blocked for newly joined devices, OOBE time will balloon. Check your conditional access and named locations to ensure newly enrolled devices can reach the Microsoft content endpoints before a user-scoped policy restricts them.
PowerShell scripts assigned alongside Win32 apps still execute in their prior order, which means signing and execution policy problems you had before April are unchanged. If a script unpacks an installer and runs it manually, the managed installer trust does not magically extend to that installer unless you have configured the script host accordingly.
Custom App Control policies that you author outside of the Intune-provided template can conflict. If you shipped a signed custom policy that specifies a different set of authorized installers, you need to reconcile it with the Intune-managed installer configuration. The Intune Management Extension must be on the authorized list or the new AP-DP flow will look fine but apps will fail signature evaluation after install.
Reporting propagation can still lag by a few minutes. Do not declare a deployment broken because the AP-DP report has not updated yet. Give it fifteen to thirty minutes before opening a ticket.
Finally, Patch My PC and other third-party deployment tools that inject into the AP-DP pipeline need their own validation pass. Confirm with your vendor that they have tested against the April 10, 2026 behavior. Early adopters of the fix caught a couple of vendor-side issues where metadata did not flow into the Intune reporting surface even though the app installed correctly.
What to verify in your tenant right now
If you want a fast checklist to run on Monday morning, here it is.
Confirm your Windows build floor. Any AP-DP target below Windows 11 22H2 with KB5035942 will not benefit from the fix and may exhibit the old behavior.
Pull your current App Control for Business configuration in the Intune admin center. Check that the Intune Management Extension is the managed installer, and that the policy assignment covers the device groups that receive AP-DP.
Review your Autopilot device preparation policy. Count the apps. Make sure you are under 25, and that every app is a Win32, Microsoft Store, or Enterprise App Catalog app (line-of-business MSIX and classic LOB apps follow different rules).
Look at the last seven days of AP-DP deployment reports. Filter for “Skipped” app results. If you see them, pull the device identity and check which group it landed in and whether that group is on the managed installer assignment.
If you have been running without the managed installer opt-in, schedule a pilot for the migration path above. Do not wait for an auditor to flag the gap.
Bottom line
The April 10, 2026 change to Autopilot device preparation is not flashy, but it closes a real operational wound. Teams can finally run App Control for Business with a managed installer and ship clean, app-complete AP-DP deployments without the awkward workaround. The fix needed about eighteen months to land. Use the next few weeks to validate the new sequence in your tenant, bring your managed installer assignments back into alignment with AP-DP device groups, and retire the “opt-out” workaround for good.
Desktop engineers