A Required Win32 app shows Install failed on a batch of laptops. Company Portal says "Couldn't install" or "Install failed". The first instinct is to edit the detection rule, re-upload the .intunewin, or remove and re-add the assignment.
Wait on all three. A Win32 install goes through several stages, and the error code tells you which one broke. If the app did install and Intune still says Failed (0x87D1041C), that's a detection problem and the detection-rule post covers it. This post is for the other case: the install itself never succeeded. Every step below only reads until the change table at the end.
TL;DR
- Find the stage first: content info, download, unpack, install command, or detection. The code in the portal usually tells you.
- An install exit code shows up in the portal as an HRESULT:
0x80070643is just MSI 1603,0x80070652is 1618. Convert before you search. - Intune's default return codes are
0and1707Success,3010Soft reboot,1641Hard reboot,1618Retry. Anything else counts as a failure unless you mapped it. -
0x87D300C9(the installer was still running when the agent stopped watching) almost always means a hidden prompt or a non-silent switch, not a slow network. - Don't delete Intune Management Extension (IME) registry keys or reimage to "force a retry" until you know why the first attempt failed.
Which stage failed?
The Intune Management Extension handles a Required Win32 app in roughly this order. Microsoft's Win32 docs and the IME logs line up with these stages:
| Stage | What happens | What a failure usually looks like |
|---|---|---|
| Requirements | OS, architecture, disk, custom requirement script | Not applicable, not Failed |
| Content info | IME asks the service where the package is and how to decrypt it |
0x87D30065 Failed to retrieve content information |
| Download | Delivery Optimization pulls the encrypted content | Stuck at Downloading, or a network error such as 0x87D1313C (connection lost) |
| Unpack | Hash check, decrypt, extract to C:\Windows\IMECache
|
Antivirus quarantine, low disk |
| Install | Your install command runs as System or User; the exit code goes through your return-code map |
0x8007xxxx codes (1603, 1618), 0x87D300C9, timeouts |
| Detection | Your detection rule runs again |
0x87D1041C: detection post
|
In the Intune admin center > Apps > Windows > [app] > Device install status, note the status and the error code for two or three failed devices. If every device fails with the same code, it's the package or the assignment. If one site or one model fails, it's the environment.
Step 1: Translate the code
A lot of time goes into searching for 0x80070643 when the installer simply returned 1603. Win32 error codes come back wrapped as 0x8007 plus the code in hex. Convert in PowerShell (read-only):
# HRESULT from the portal -> installer exit code
[int]0x80070643 -band 0xFFFF # 1603
[int]0x80070652 -band 0xFFFF # 1618
# Exit code -> what the portal will show
'0x8007{0:X4}' -f 1603 # 0x80070643
| Code | Means | Usual cause |
|---|---|---|
1603 / 0x80070643
|
Fatal error during installation (Windows Installer generic failure) | Failed custom action, missing prerequisite, newer version already present, pending restart, wrong run context |
1618 / 0x80070652
|
Another installation is already in progress | Windows Update, another app, or Office setup holding the installer. Intune retries this by default |
| 1619 | Package could not be opened | Wrong file name or relative path in the install command |
| 1638 | Another version of this product is already installed | Upgrade without an uninstall or supersedence step |
0x87D300C9 |
Unmonitored process in progress, may time out | Installer waiting on a prompt nobody can see |
0x87D30065 |
Failed to retrieve content information | Network/proxy/TLS inspection, or a bad upload when every device fails |
Step 2: Read the device's own record
On an affected device, with authorization, the logs are in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\. Newer IME builds write Win32 app download, install and detection steps to AppWorkload.log; older builds use IntuneManagementExtension.log. A read-only filter for one app (use the app ID GUID from the portal URL):
$appId = '<app GUID from the Intune portal URL>'
$logs = Get-ChildItem 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs' -Filter '*.log' |
Where-Object Name -match 'AppWorkload|IntuneManagementExtension'
Select-String -Path $logs.FullName -Pattern $appId, 'lpExitCode', 'exit code', '0x87D' |
Select-Object -Last 60 |
ForEach-Object { ($_.Line -replace '<!\[LOG\[|\]LOG\]!>.*$', '').Trim() }
Not every line carries the app ID, and log wording changes between IME versions, so if the output is thin, open the log in a CMTrace-format viewer and search for the app ID. You're looking for three things: did the download finish, what exit code did the install command return, and did IME map it as success, retry or failure.
For MSI-based installs, Windows Installer writes its own result to the Application event log:
Get-WinEvent -FilterHashtable @{ LogName = 'Application'; ProviderName = 'MsiInstaller'; StartTime = (Get-Date).AddDays(-2) } |
Where-Object Id -in 1033, 1034, 11707, 11708 |
Select-Object TimeCreated, Id, Message -First 20 | Format-List
Event 11708 means the install failed, and 1033 includes the product name and the exit status. That confirms whether the installer itself returned the code, or whether IME never got that far.
Step 3: Download and unpack problems
If the log never shows the install command running, the problem is upstream of your installer:
# Read-only checks
Get-PSDrive C | Select-Object Used, Free
Get-DeliveryOptimizationStatus | Select-Object FileId, Status, BytesFromPeers, BytesFromHttp, DownloadMode -First 10
| Finding | Likely cause | First move |
|---|---|---|
0x87D30065 on every device, new app |
Content upload didn't finish cleanly | Check the app's upload status in the portal; re-upload is justified here |
0x87D30065 / download errors at one site |
Proxy, firewall or TLS inspection on Intune and Delivery Optimization endpoints | Compare with a device on another network before touching the app |
| Download completes, then hash/decrypt error | Antivirus scanning the IME content folder | Microsoft recommends excluding C:\Windows\IMECache and the IME Content folder from scanning |
| Low free space | Package plus extraction doesn't fit | Free space, then let the retry run |
Step 4: The install command and its exit code
This is where most Required app failures land. Check the app's Program tab against what the installer actually does.
Return codes. Intune's defaults are 0 and 1707 Success, 3010 Soft reboot, 1641 Hard reboot, 1618 Retry. Per Microsoft, a Retry code makes the agent try three times, five minutes apart. Some vendor EXEs return non-zero codes on success. Only add a custom Success code when the vendor documents it, never because "it installed on my machine."
Run context. Install behavior System runs with no user profile, no mapped drives and no visible desktop. Install behavior User runs with the signed-in user's rights, so it can work for an admin tester and return 1603 for a standard user. Match the context to where the app installs (per-machine vs %LOCALAPPDATA%).
Silent switches. 0x87D300C9, or a failure right at the Installation time required limit (60 minutes by default, 1440 maximum), almost always means the installer is waiting on a prompt: an EULA, a "close Outlook first" dialog, a reboot question. Raising the timeout just makes it fail later.
Reproduce it the way IME runs it. On a lab device, not a user's laptop, run the exact install command from the extracted package as SYSTEM (for example Sysinternals psexec -s -i cmd.exe) with logging on:
msiexec /i "App.msi" /qn /l*v "C:\Windows\Temp\App-install.log"
Then search the log for Return value 3. The action just above it is the real cause of the 1603.
Dependencies. If the app has dependencies, a failed dependency fails the parent. The install details flag the dependency, and Microsoft notes each dependency follows the same retry logic and the 24-hour reevaluation schedule. Fix the dependency first.
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
Upload incomplete, every device 0x87D30065
|
Re-upload the .intunewin to the same app |
Creating a second app with a new name (two apps, two assignments, two reports) |
| One site fails downloads | Fix the proxy/TLS inspection path for Intune and Delivery Optimization | Repackaging the app |
1603 with a known Return value 3 cause |
Fix the prerequisite, uninstall step or context in the command line | Mapping 1603 as Success |
0x87D300C9 or timeout |
Fix the silent switches, then test as SYSTEM | Raising Installation time required to hours |
| 1618 on many devices | Let the Retry code work; check what else installs at the same time (ESP, Office, updates) | Adding 1618 as Success |
| Install actually succeeded, still Failed | Go to the detection post | Changing the install command |
| Need a faster retry on one test device | Restart the IME service or install it as Available from Company Portal | Deleting IME registry keys on production devices as a first move |
A failed Required app during Autopilot also holds up the Enrollment Status Page if it's on the blocking list. If that's how the ticket arrived, read the ESP triage alongside this.
FAQ
Is 0x80070643 an Intune error?
No. It's Windows Installer's 1603 wrapped as an HRESULT. The reason is in the MSI verbose log, not in Intune.
How often does Intune retry a failed Required app?
Retry return codes get three attempts five minutes apart. After that, Microsoft describes a reevaluation on roughly a 24-hour cadence. For quick feedback on a test device, an Available install from Company Portal is faster than waiting.
Why does it install from Company Portal but fail as Required?
Usually timing or context: Required installs run during ESP or at sign-in while other installs and updates are running (1618), or the assignment targets devices while the app installs per user.
The portal shows "Install pending" for days, no error at all.
That's usually check-in or assignment, not the installer. Start with the Company Portal / sync triage.
Should I collect diagnostics remotely?
Yes, where your tenant supports it. Collect diagnostics on the device, or Collect logs from the app's install details, pulls the IME logs without changing the device.
Related posts
- Intune Win32 app shows "Failed" after a successful install? It's usually the detection rule
- Autopilot ESP stuck? An assignment-first triage checklist
- Company Portal can't connect / device not syncing: a 10-minute triage order
Free checklist
Required apps often feed compliance, and compliance feeds Conditional Access. If you're about to require compliant devices, the free Conditional Access pre-enforcement checklist keeps device readiness, pilot groups and report-only review on one page, so a broken app deployment doesn't turn into a sign-in lockout:
If you package apps regularly, the Intune Win32 App Packaging Starter Pack has silent-switch research notes, install/uninstall command and return-code patterns, failure triage cards and pilot gates: https://cashflow4375.gumroad.com/l/cgnpzt?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=intune-win32-app-install-failed
Admin Pack Studio; not affiliated with Microsoft. Steps 1–3 only read. Reproduce installs on a lab device, not a user's machine, and check current Microsoft docs for log names and limits.
Top comments (0)