Intune App Deployment Failures — 8 Causes and Fixes

Get the Real Error First

The Intune portal shows a hex code that's rarely enough. The real detail is in the IME log (Intune Management Extension) on the device itself:

# IME log location
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log

# Also check:
C:\Windows\Temp\IntuneScripts\    # Script deployment logs
C:\Windows\Logs\Software\         # Some app installers log here

Open the IME log and search for the app name. You'll find the exact exit code, the command line that was run, and any error output from the installer. This is almost always more useful than the portal error code.

1 — Wrong Detection Rule

The most common cause of "Failed" when the app is actually installed correctly. Intune re-attempts installation every 8 hours if detection fails — it looks like a continuous failure but the app is fine.

# Test your detection rule manually on the device

# File detection
Test-Path "C:\Program Files\MyApp\myapp.exe"

# Registry detection
Get-ItemProperty -Path "HKLM:\SOFTWARE\MyApp" -Name "Version" -ErrorAction SilentlyContinue

# MSI detection (use product code from the installer properties)
Get-WmiObject Win32_Product | Where-Object {$_.Name -like "*MyApp*"}

If these return nothing on a machine where the app is installed, your detection rule is wrong. Fix the path, registry key, or product code in Intune and trigger a sync.

2 — Bad Install Command

Win32 apps require a silent install command. Intune runs it without an interactive session — any prompt will cause it to hang forever.

# Test your install command in a non-interactive context:
# Open CMD as SYSTEM using PsExec
psexec -s -i cmd.exe

# Then run your install command:
msiexec /i "MyApp.msi" /qn /l*v C:\install.log

Check C:\install.log for the MSI error code. Common fixes:

Add /qn for silent install on MSI packages
Add /norestart to prevent reboots during deployment
Use START /WAIT for exe installers that spawn child processes

3 — 32-bit vs 64-bit Context

By default, Intune runs Win32 app installations in the 32-bit context on 64-bit machines. Paths like C:\Program Files\ silently redirect to C:\Program Files (x86)\, and registry writes go under WOW6432Node.

Fix: in the Win32 app configuration in Intune, set Install behavior → System and enable Run as 64-bit. Or adjust your detection rule to use the WOW6432Node path explicitly if you can't change the install context.

4 — Missing Dependency

Apps requiring .NET, Visual C++ Redistributable, or other runtimes fail silently if the dependency isn't present and isn't configured in Intune.

# Check if the required .NET version is installed
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" |
  Select-Object Version, Release

In Intune, add the dependency (e.g., .NET Runtime) under App → Dependencies. Intune will install it first, automatically, before the main app.

5 — User vs System Context

Some apps must install in user context (per-user profile apps), others in system context (Program Files). Running a system app in user context fails with permission errors; running a user app as SYSTEM installs it for SYSTEM, not the logged-in user.

Set Install behavior → System for apps in Program Files, User for apps that write to the user profile. Check the app's own documentation or its installer log to confirm which it expects.

6 — Corrupt Package Upload

Large packages occasionally upload with corruption that isn't caught until deployment time. The IME log shows a hash mismatch or extraction failure:

# Look in IME log for:
# "Content hash mismatch"
# "Failed to extract"
# "Download failed"

Fix: delete the app in Intune, re-wrap it with the Win32 Content Prep Tool to generate a fresh .intunewin file, and re-upload:

IntuneWinAppUtil.exe -c "C:\SourceFiles" -s "setup.exe" -o "C:\Output"

7 — Supersedence Loop

If App B supersedes App A, and both are assigned to the same device, Intune can loop — installs B, detects A is gone (correct), then reinstalls A from a separate assignment. Both apps cycle indefinitely.

Fix: remove the older app (App A) from the direct assignment. Only keep the superseding app (App B) assigned. The supersedence relationship handles uninstalling the old version — you don't need to assign both.

8 — Network / CDN Block

Intune delivers Win32 app content through Azure CDN. If the device can reach Intune but not the CDN, downloads fail silently.

# Test CDN connectivity
Test-NetConnection -ComputerName swda01-mscdn.azureedge.net -Port 443

# Check IME log for failed downloads with CDN URLs

Fix: add a firewall/proxy bypass rule for *.azureedge.net and *.manage.microsoft.com. SSL inspection (deep packet inspection) on these domains also breaks downloads — add them to your SSL inspection bypass list.

Intune App Deployment Failures — 8 Common Causes and How to Fix Them