Common reasons apps fail in Intune

Why does an app show as failed when it actually installed?

This is the single most common surprise in Win32 deployment. The installer ran, the application is on the device, but Intune still shows “Failed” or keeps retrying. The reason is that Intune does not decide success from the install command alone — it runs your detection rule after the command finishes. If the detection rule does not match the installed state, Intune concludes the app is absent and marks the cycle as not successful, even though the install worked.

Detection mismatches usually come from one of these:

• Wrong path or 64-bit redirection. A File rule pointing at C:\Program Files when a 32-bit app actually lands in C:\Program Files (x86), or vice versa.
• MSI product code drift. MSI detection keys off the product code; if the vendor ships a new product code with an update, the old rule stops matching.
• Registry value vs key. Checking that a value equals a string when the installer writes a different value, or checking a key that only exists under one architecture hive.
• A detection script that does not follow the contract. A custom PowerShell detection script is treated as “detected” only when it exits with code 0 and writes something to STDOUT. A script that exits 0 silently, or writes output but exits non-zero, is read as “not detected.”

What does “the install command is not fully silent” really mean?

Win32 apps install in the background with no signed-in user able to click through a wizard. If the command opens any UI, waits for input, or relaunches itself, the Intune Management Extension sees a process that never returns a clean exit code and the deployment hangs or fails. “Silent” means the installer runs end to end unattended and returns control to IME with a defined return code.

The fixes depend on the installer technology. The most reliable patterns are:

• MSI: msiexec /i app.msi /qn /norestart — quiet, no UI, and suppress the installer-driven reboot so Intune controls restart behaviour.
• EXE setups: use the documented silent switch (often /S, /silent, /quiet, or /verysilent), which varies by packaging engine. The silent switches for common installers guide lists the right flag per engine.

A quick local test is the surest check. Run the exact command you put in Intune from an elevated, non-interactive context and confirm it returns to the prompt with no window and a known exit code:

msiexec /i app.msi /qn /norestart & echo %ERRORLEVEL%

Is the device even targeted, or does it fail a requirement?

Before any command runs, two gates must pass. First, the device or user must be in a group that the app is assigned to. An app with no successful targeting will never appear in reporting for that device at all — it simply is not applicable. Second, the device must satisfy every requirement rule on the app. Requirement rules are evaluated before detection and before the install command, so a device that fails one is reported as “Not applicable,” not “Failed” — which is why an app can look like it is doing nothing.

Common targeting and requirement causes:

• Wrong assignment intent. An Available assignment only surfaces the app in Company Portal for a signed-in user; it never auto-installs and is not supported for device-only groups. If users expect an automatic install, the intent must be Required.
• Group membership lag. The device was added to a group but has not picked up the policy yet.
• OS architecture or minimum OS. An x64-only requirement on an x86 or ARM64 device, or a minimum OS version higher than the device runs.
• Optional requirements. Disk space, physical memory, logical processors, CPU speed, or a custom file/registry/script requirement that the device does not meet.

How do return codes turn into success or failure?

When the install command finishes, IME maps the process exit code to an install behaviour. The defaults below decide whether Intune records success, a reboot, a retry, or a failure. Many “failures” are simply a non-default success code (like an MSI reboot code) being treated as failure because the installer returns something Intune has not been told to accept — in which case you add a custom return-code mapping rather than changing the package. See return codes and install behavior for the full mapping workflow.

Does context (System vs User) or restart behaviour cause failures?

Install behaviour is set to System or User context on the Program tab, and the wrong choice causes confusing, partial failures. System context runs as the local SYSTEM account, device-wide, and is the common default for machine-wide installers. User context runs as the signed-in user and requires a user to be present — it is meant for per-user installers that write to the user profile or HKCU. An app that only works per-user but is assigned in System context (or the reverse) can install partially, write to the wrong hive, then fail detection.

Restart behaviour on the same tab matters too. If an installer forces its own reboot mid-install while Intune also expects to manage restarts, the cycle can be cut short. The cleaner pattern is to suppress the installer’s reboot (for example /norestart) and let Intune handle it through the restart behaviour options: “No specific action,” “App install may force a device restart,” “Determine behavior based on return codes,” or “Intune will force a mandatory device restart.”

Could the failure just be timing and IME check-in?

Sometimes nothing is wrong except expectations about speed. Win32 apps and PowerShell scripts are processed on the device by the Intune Management Extension, which checks for new app and script policy roughly every hour, and also right after a device restart or when the IME service restarts. That is a different cadence from the general Windows MDM device check-in, which runs on a variable schedule (commonly around every eight hours, more often just after enrollment). A new assignment can therefore look “stuck” simply because the next IME cycle has not run yet.

To force a check-in instead of waiting, trigger a sync from Company Portal or from Settings > Accounts > Access work or school > Info > Sync. If you are testing repeatedly, a manual sync after each change saves an hour of waiting.

(New-Object -ComObject Shell.Application).Open("intunemanagementextension://syncapp")

Which symptom maps to which cause?

Triaging is faster when you start from the user-visible symptom and work back to the lifecycle stage, rather than changing settings at random. The flow below is the order to reason in, followed by a symptom-to-cause map you can scan quickly.

Where do the logs confirm the real cause?

Status in the Intune portal tells you that something failed; the device logs tell you why. The Intune Management Extension writes to C:\ProgramData\Microsoft\IntuneManagementExtension\Logs, where AppWorkload.log and IntuneManagementExtension.log record the install command, its exit code, and the detection result for each Win32 app. Open them with CMTrace so you can colour-filter and follow a single app’s cycle. The Intune Management Extension logs guide explains which file holds which event. Reading the log before changing anything is what stops you from “fixing” the wrong thing.