Intune Win32 App Installs Manually but Fails in Deployment: Remove Interactive Setup

A Win32 installer may work perfectly when an administrator runs it from the desktop and clicks through its dialogs, yet fail when Intune deploys it. The difference is not necessarily the package. Microsoft Intune does not support interactive application installations: deployed applications must install silently and cannot depend on dialog boxes, prompts, or UI input.

That makes this a separate failure path from a bad detection rule or a generic installer error. A manual test proves only that the installer works with a person present in that session. It does not prove that the exact Intune command can finish unattended in the configured install context.

For a structured review, use the free Intune App Failure Analyzer. It is a browser-based, client-side beta. You provide the error code, install command, detection rules, install context, registry view, and IME/AppWorkload logs; it organizes the evidence you supply and does not inspect the endpoint or invent findings.

Quick fix checklist

1. Open Intune admin center > Apps > All apps > select the Windows app (Win32) > Properties and copy the exact install command.
2. Run that command without clicking through dialogs. Use a test device and a maintenance window; do not test against production devices.
3. Confirm the vendor’s documented silent switches. For an EXE, /quiet, /silent, or /S are vendor-specific, not interchangeable guesses.
4. Check whether the command launches a child process and returns before the real installer finishes. The wrapper must wait for the child and return its result.
5. Review AppWorkload.log, AppActionProcessor.log, and AgentExecutor.log under C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.
6. After the installer completes, verify the exact file, MSI product code, or registry value used by the Intune detection rule.

Why the obvious diagnosis can be wrong

If setup succeeds from an elevated PowerShell window, it is tempting to blame detection when Intune reports Failed. Detection can be wrong, but the installer may never have completed: it may be waiting for a hidden prompt, displaying UI in a non-interactive session, or returning a wrapper code before a child installer finishes.

Microsoft also documents that applications deployed through Intune must install silently. Techniques that force interaction with the signed-in session are unsupported and can produce inconsistent behavior. Do not treat a visible dialog on a technician’s test run as evidence that the deployment is supported.

Evidence to inspect

1. The actual command and context

Record the command exactly as configured, including quoting, working files, and arguments. Record Install behavior as System or User. A command that relies on a mapped drive, a user’s profile, or a prompt can pass manually and fail under the deployment identity.

Microsoft’s current Win32 app guidance also warns that calling powershell.exe from the command fields launches 32-bit PowerShell. If the installer or wrapper needs 64-bit PowerShell, use:

%SystemRoot%\Sysnative\WindowsPowerShell\v1.0\powershell.exe

2. IME and installer logs

Start with AppWorkload.log to establish whether content was downloaded, the command was launched, and a return code was recorded. Use AppActionProcessor.log to correlate applicability and detection. Use AgentExecutor.log when a PowerShell installer or detection script is involved. Then read the vendor installer log for the prompt, blocked action, or child-process failure.

A portal result alone cannot tell you whether the break occurred during download, command execution, detection, or reporting. Preserve timestamps and the app name when correlating the entries.

3. Detection after a silent install

Once the command runs unattended, verify the artifact it creates. Check the same registry hive and registry view that the rule uses. For a machine install, confirm the expected HKLM location and file path as SYSTEM; for a per-user install, confirm that the selected context matches the user-scoped artifact. Do not use a Start menu shortcut as the only proof.

Verified fix

Replace the interactive workflow with a vendor-supported silent command, and make the wrapper wait for completion. If the vendor provides no supported unattended mode, the application is not ready for a reliable Intune Win32 deployment; escalate to the vendor or choose a deployment method that supports the product.

A safe validation sequence is:

1. Test the exact configured command on a clean Windows device with no user interaction.
2. Capture the installer log and its final exit code.
3. Confirm the installer process and any child process have exited.
4. Confirm the artifact used by detection exists in the configured context.
5. Trigger an Intune sync and verify the device installation result.
6. Repeat on a second pilot device before widening the assignment.

Do not use ServiceUI.exe or similar attempts to force setup into the signed-in user’s session. Microsoft identifies these techniques as unsupported for Intune application deployment.

Prevention checklist

• Require a documented silent install and uninstall command before packaging.
• Test as the configured System or User context, not only as an administrator.
• Make wrappers wait for child processes and propagate the meaningful exit code.
• Capture vendor logs to a local path available in the deployment context.
• Keep detection tied to a stable file, MSI product code, or registry value created by the silent install.
• Validate both native and 32-bit registry views when PowerShell is part of the command.
• Pilot on clean devices and preserve IME evidence for every change.

Sources and related troubleshooting

• Add and assign Win32 apps to Microsoft Intune
• Intune Management Extension for Windows
• The Intune Win32 App Installed but Says Failed
• System vs. User Install Context in Intune Win32 Apps
• How to Read Intune Management Extension and AppWorkload Logs
• Free Intune App Failure Analyzer