Error 0x87D1041C appears during the Enrollment Status Page (ESP) phase of Windows Autopilot and is tied to changes introduced in the May 2026 cumulative update, build 26200.8457. On affected devices the Microsoft Store version of Company Portal installs successfully, but Intune's detection logic fails to validate it - so ESP treats a working install as a failed required app and stops the deployment. Devices on older builds such as 26100.8457 continue to enroll normally, which confirms the issue is specific to this build.
This guide walks through five approaches, from the fastest workaround to fixes that scale. The quickest is removing Company Portal from the ESP blocking apps list; more durable options include deploying Company Portal as a Win32 app with registry-based detection, shifting it to user-context deployment, recovering already-stuck devices via the Autopilot diagnostics registry keys, and automating repair with an Intune remediation script. Because several steps modify the registry, back up before making changes and validate on a test device before any production rollout.
Before you start
What you will learn
- You will learn how to fix Windows Autopilot error 0x87D1041C on build 26200.8457 by reconfiguring how Company Portal is validated during the Enrollment Status Page (ESP), plus how to recover devices already stuck at the error.
- This error halts entire Autopilot deployments during the ESP phase, blocking large-scale device rollouts even though Company Portal actually installs correctly. Resolving it keeps provisioning moving and preserves Intune management on newly enrolled devices.
Requirements
- You need administrative access to the Microsoft Intune admin center (https://intune.microsoft.com) to edit the Enrollment Status Page profile, app assignments, and remediation scripts. Device-level recovery steps additionally require local access to the affected device during OOBE.
- Intune Administrator (or Global Administrator)
- Local administrator on the target device (for registry-based recovery during OOBE)
Good to know
- The ESP blocking-apps workaround takes about 10-15 minutes; Win32 repackaging and remediation scripts take longer to build and test.
- Applies to Windows build 26200.8457 with devices managed through Microsoft Intune and enrolled via Windows Autopilot.
Quick answer
Error 0x87D1041C means ESP failed to validate Company Portal during Autopilot on build 26200.8457, even though the app installed. The fastest fix is to stop ESP from blocking on it: in the Intune admin center open your Enrollment Status Page profile and remove Company Portal from the required/blocking apps, or switch to allowing device use even if app installation fails.
Devices → Enroll devices → Enrollment Status PageStep-by-step tutorial
5 stepsRemove Company Portal from ESP blocking apps
Stop the Enrollment Status Page from halting Autopilot when Company Portal detection fails.
Devices → Enroll devices → Enrollment Status Page → [profile] → Settings → App installationThis is the fastest workaround and resolves the immediate Autopilot failure.
- Sign in to the Microsoft Intune admin center at https://intune.microsoft.com.
- Go to Devices → Enroll devices → Enrollment Status Page.
- Select your existing ESP profile (or create a new one for testing).
- Open Settings and scroll to the App installation section.
- Under Block device use until these required apps are installed if they are assigned to the user/device, locate Company Portal and remove it from the list.
- Alternatively, change the behavior to Allow device use even if app installation fails so ESP no longer treats the Company Portal detection failure as a blocking error.
- Click Save to apply the changes.
Company Portal still installs in the background - you are only removing it as a blocking requirement during device setup.
Verify by deploying a test device through Autopilot and confirming ESP completes without 0x87D1041C, then check that Company Portal is still installed after user sign-in. If Company Portal is required immediately for compliance policies, prefer the Win32 approach in the next step instead of dropping the block entirely.
Deploy Company Portal as a Win32 app with reliable detection
Replace the failing Store detection logic with a Win32 detection rule Intune can validate correctly.
Apps → All apps → Add → Windows app (Win32)Convert Company Portal from a Microsoft Store deployment to a Win32 (.intunewin) app so you control the detection rule.
- Obtain the Company Portal MSIX package.
- Convert it to
.intunewinformat using the Microsoft Win32 Content Prep Tool (see command below). - In the Intune admin center go to Apps → All apps → Add and select Windows app (Win32) as the app type.
- Upload the converted
.intunewinfile. - Set the Install command to
Add-AppxPackage -Path "Microsoft.CompanyPortal.msix". - Set the Uninstall command to
Get-AppxPackage Microsoft.CompanyPortal | Remove-AppxPackage. - Configure a registry detection rule pointing at the uninstall key:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Microsoft.CompanyPortal_8wekyb3d8bbwe. - Assign the app to device groups and configure it as Required during ESP.
IntuneWinAppUtil.exe -c "C:\CompanyPortal" -s "Microsoft.CompanyPortal.msix" -o "C:\Output"Paths such as C:\CompanyPortal, C:\Output, and the package/version identifiers are placeholders - adjust to your source folder, package name, and current publisher/version string. Test the Win32 deployment thoroughly in a pilot ring before production rollout, since it replaces the Store-managed update mechanism with one you now maintain.
Move Company Portal to user-context deployment
Move Company Portal out of the device setup phase so it installs after user sign-in.
Apps → All apps → [Company Portal] → Properties → Assignments → EditDeploy Company Portal during user sign-in instead of the device setup phase so ESP never validates it as a device-required app.
- In the Intune admin center go to Apps → All apps and locate your Company Portal assignment.
- Click Properties → Assignments → Edit.
- Change the assignment from device groups to user groups.
- Set the install context to User instead of Device.
- Change the assignment intent to Available rather than Required so it is not enforced during ESP.
- Open your ESP profile and confirm Company Portal is not listed under device-targeted required apps.
- Save all configuration changes.
Get-AppxPackage -AllUsers | Where-Object {$_.Name -like "*CompanyPortal*"}Making Company Portal Available rather than Required means users must be signed in for it to install; if your policies depend on Company Portal being present immediately at the device level, use the Win32 approach instead. Verify by deploying a test device and confirming ESP finishes, then checking installed apps after the user logs in.
Recover devices already stuck at the error
Unblock devices currently failing with 0x87D1041C so they can complete enrollment.
OOBE → Shift+F10 → regeditUse this only for devices already halted at the error during OOBE. Back up the registry before editing - incorrect changes can cause system instability.
- On the affected device, press Shift + F10 during OOBE to open a Command Prompt.
- Launch Registry Editor by running
regedit. - Navigate to
HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot\EstablishedCorrelations. - Locate the Company Portal correlation entry and delete it.
- Navigate to
HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilotand find ESP-related entries showing a failed status; set the relevantInstallationStatevalue to reflect an installed state. - Close Registry Editor and restart the device so ESP re-evaluates and bypasses the failed Company Portal check.
regeditThis is a manual per-device recovery and a workaround, not a fix - pair it with one of the configuration changes above so future devices don't hit the same error. After the device finishes, run dsregcmd /status to confirm Azure AD join and verify Company Portal manually. Export the affected keys with File → Export before deleting anything.
Deploy a PowerShell remediation script at scale
Automate Company Portal detection and reinstallation across affected device groups.
Devices → Scripts and remediations → Remediation scripts → CreateCreate an Intune remediation that detects the Company Portal package and reinstalls it when missing.
- In the Intune admin center go to Devices → Scripts and remediations → Remediation scripts and click Create.
- For the detection script, check for the appx package and exit
0when present,1when missing:
- For the remediation script, reinstall Company Portal when it is missing (see the command panel).
- Configure the script to run in System context.
- Assign the remediation to the device groups experiencing the error.
try {
$StoreApp = Get-AppxPackage -Name "Microsoft.CompanyPortal" -AllUsers
if (-not $StoreApp) {
winget install "Company Portal" --source msstore --accept-package-agreements --accept-source-agreements
}
Write-Output "Company Portal remediation completed"
exit 0
} catch {
Write-Error "Remediation failed: $($_.Exception.Message)"
exit 1
}winget in system context during OOBE/ESP can be unreliable because it depends on the Store/App Installer being provisioned - validate on a pilot group first. Avoid writing custom status values into the Autopilot diagnostics keys as a 'fix', since those are internal state managed by Windows and editing them is a recovery workaround rather than a supported detection mechanism. Monitor execution in the Intune remediations report.
Confirm the 0x87D1041C Error Is Resolved
After applying one of the fixes, deploy a test device through Windows Autopilot and watch the Enrollment Status Page (ESP) progress through the device setup and account setup phases. A successful result means ESP completes without surfacing error 0x87D1041C, the device reaches the desktop, and Company Portal is present and functional - either installed during ESP (Win32 or remediation approaches) or shortly after user sign-in (user-context and blocking-app removal approaches).
Don't rely on the absence of the error code alone. Verify all three outcomes: ESP completion, Company Portal presence, and full Intune management. Run the checks below and compare against the normal/abnormal results.
Verification checks
- Confirm the Company Portal appx package is present: Get-AppxPackage -Name "Microsoft.CompanyPortal" -AllUsers | Select-Object Name, Version, InstallLocation - Confirm Entra ID (Azure AD) join status: dsregcmd /status - look for AzureAdJoined : YES - Confirm Intune (MDM) enrollment: Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Enrollments" | Get-ItemProperty | Where-Object {$_.ProviderID -eq "MS DM Server"}
If you removed Company Portal from the blocking apps list, the app may still be installing in the background at first sign-in - allow a few minutes before treating its absence as a failure.
- ESP completes with no 0x87D1041C error; the device reaches the desktop; Get-AppxPackage returns the Microsoft.CompanyPortal package; dsregcmd /status shows AzureAdJoined : YES; and the Enrollments key contains an MS DM Server entry, confirming full Intune management.
- ESP still halts on 0x87D1041C, or Company Portal never appears in Get-AppxPackage even after sign-in, or dsregcmd shows AzureAdJoined : NO / no MS DM Server enrollment entry. If so, proceed to the advanced troubleshooting and consider opening a Microsoft Support case with your Windows build, Intune tenant ID, device model, and ESP logs.
- Confirms the device is Entra ID joined after ESP completes.
- A returned package object confirms Company Portal is installed regardless of the ESP detection issue.
- An MS DM Server entry under HKLM\SOFTWARE\Microsoft\Enrollments confirms Intune management is active.
Troubleshooting
ESP still fails with 0x87D1041C after removing Company Portal from the blocking apps list
Cause: The ESP profile change has not propagated to the device, or Company Portal is still assigned as a device-required app elsewhere in Intune, so ESP continues to wait on it.
Confirm you saved the ESP profile and that it is assigned to the correct device group. Then check Apps → All apps and verify Company Portal is not assigned as Required to the device during setup. Create a fresh Autopilot test device rather than reusing a device that already cached the old ESP policy, since policy is fetched at the start of enrollment.
Win32 Company Portal reports install failure even though the app is present
Cause: The registry detection rule points to a path that does not match the installed package, so Intune cannot confirm the install and ESP treats it as failed.
Re-check the detection rule against HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Microsoft.CompanyPortal_8wekyb3d8bbwe on a reference device. Confirm the install and uninstall commands run in system context, then re-upload the .intunewin and re-test on a clean device before production rollout.
Editing the registry during OOBE leaves the device in an unstable or unbootable state
Cause: Incorrect keys were removed or values were changed outside the documented Autopilot diagnostics paths.
Always export the affected keys with reg export before deleting anything. Only clear the Company Portal correlation entries under HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot\EstablishedCorrelations. If the device will not recover, reset it and re-run Autopilot with the corrected ESP profile instead of continuing to edit the registry.
The remediation script does not run during the Enrollment Status Page
Cause: Remediation scripts run on the Intune management extension schedule and are not guaranteed to execute inside the ESP window, and they only apply to already-enrolled devices.
Use the remediation script as an ongoing fix for enrolled devices rather than an ESP-time fix. For new deployments, combine it with Step 1 (remove Company Portal from blocking apps) so ESP completes, then let the remediation reinstall and validate Company Portal after sign-in. Confirm the script is set to run in System context and assigned to the affected device group.
Devices on build 26100.8457 work but 26200.8457 devices keep failing
Cause: The detection/validation change was introduced by the May 2026 cumulative update in build 26200.8457, so only devices on that build hit the fault.
Confirm the build with winver or Get-ComputerInfo. Apply the ESP reconfiguration (Step 1) or Win32 deployment (Step 2) to any group receiving 26200.8457. Where feasible, hold the affected build in your update ring until Microsoft ships a permanent fix, and monitor the Intune diagnostics log with Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Operational".
Frequently asked questions
What exactly does Windows Autopilot error 0x87D1041C mean?
It means Autopilot failed during the Enrollment Status Page because Intune could not validate that Company Portal was successfully installed, even though the app is actually present on the device. ESP interprets this as a failed required-app install and halts the deployment.
Why does this error only affect Windows build 26200.8457?
The error is tied to the May 2026 cumulative update (build 26200.8457), which changed how Windows and Intune detect and validate Microsoft Store apps during ESP. Devices on older builds such as 26100.8457 use the previous detection logic and continue to enroll normally.
Can I prevent this error by avoiding Company Portal deployment during Autopilot?
Yes - removing Company Portal from the ESP blocking apps list or deploying it in user context instead of during device setup prevents the error. Weigh this against your security and compliance needs, since it delays Company Portal availability until after sign-in; deploying it as a Win32 app is an alternative that keeps it required with reliable detection.
Will Microsoft release a permanent fix for this Autopilot error?
Microsoft has acknowledged 0x87D1041C as a known issue on the latest build and is investigating a permanent solution. Until it ships, use the workarounds in this guide and keep the affected build controlled in your update rings.
How do I recover a device already stuck at error 0x87D1041C?
During OOBE press Shift+F10, back up the registry, then clear the Company Portal correlation entries under HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot\EstablishedCorrelations and restart so ESP bypasses the failed check. If recovery fails, reset the device and re-run Autopilot against a corrected ESP profile.
