Intune Win32 App Deployment: Packaging, Detection Rules, Error Codes & Troubleshooting

Why Win32 app deployments fail

Uploading an installer to Intune is the easy part. Most failures happen because the install command is not fully silent, the detection rule checks the wrong location, the application runs in the wrong context, or the package behaves differently under the local System account.

In this guide, I will show you the complete workflow I recommend for an Intune Win32 application: prepare the source, test the installer, create the .intunewin package, configure requirements and detection, deploy to a pilot group, and follow the correct logs when something fails.

Before troubleshooting the application, confirm that the device can process Win32 application policy.

• The Windows device is enrolled in Microsoft Intune.
• The device is Microsoft Entra registered, joined, or hybrid joined.
• The device runs a supported Windows edition and is not blocked by S mode restrictions.
• The application is assigned to a group that contains the intended user or device.
• The Microsoft Intune Management Extension service exists and is running.
• The device can reach the required Microsoft Intune network endpoints.

# Check the Intune Management Extension service
Get-Service -Name IntuneManagementExtension

# Show service state and startup type
Get-CimInstance Win32_Service -Filter "Name='IntuneManagementExtension'" |
    Select-Object Name, State, StartMode, PathName

Create one source folder for one application. Do not store unrelated installers, old versions, log files, or the Microsoft Win32 Content Prep Tool inside it because everything in the source folder can be included in the package.

C:\IntuneApps
  └── ContosoApp
      ├── ContosoApp-x64.msi
      ├── install.ps1
      └── uninstall.ps1

Use a wrapper script when the installation needs prerequisites, cleanup, configuration changes, or reliable logging. For a straightforward MSI, the native MSI command may be enough.

Intune cannot complete an unattended deployment if the installer waits for a button click, a licence prompt, or a user interface. Test the exact command locally before packaging.

Typical MSI commands

# Install silently and create a verbose log
msiexec.exe /i "ContosoApp-x64.msi" /qn /norestart /L*v "C:\Windows\Temp\ContosoApp-install.log"

# Uninstall using the MSI product code
msiexec.exe /x "{00000000-0000-0000-0000-000000000000}" /qn /norestart /L*v "C:\Windows\Temp\ContosoApp-uninstall.log"

Typical EXE commands

# Examples only—confirm switches with the application's vendor
setup.exe /silent /norestart
setup.exe /S
setup.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART

Test as the local System account

If the app will use Install behavior: System, testing only from an administrator PowerShell window is not enough. System has a different profile, environment, network access, and registry hive. Use an approved administrative test method to open a System-context shell, then run the exact install and uninstall commands.

• Confirm the process exits without user interaction.
• Record the exit code.
• Confirm the app launches or its service starts.
• Confirm the planned detection rule returns true.
• Run the uninstall command and confirm detection returns false.

A wrapper provides consistent logging and exit-code handling. The example below is a template; replace the installer name and arguments with vendor-supported values.

# install.ps1
$ErrorActionPreference = 'Stop'
$LogPath = 'C:\ProgramData\LSTech\Logs\ContosoApp-install.log'
$LogFolder = Split-Path -Path $LogPath -Parent

New-Item -Path $LogFolder -ItemType Directory -Force | Out-Null

try {
    $Installer = Join-Path -Path $PSScriptRoot -ChildPath 'ContosoApp-x64.msi'
    $Arguments = "/i `"$Installer`" /qn /norestart /L*v `"$LogPath`""

    $Process = Start-Process -FilePath 'msiexec.exe' `
        -ArgumentList $Arguments `
        -Wait `
        -PassThru

    switch ($Process.ExitCode) {
        0     { exit 0 }
        1641  { exit 1641 }
        3010  { exit 3010 }
        default { throw "Installer returned exit code $($Process.ExitCode)" }
    }
}
catch {
    Add-Content -Path $LogPath -Value "$(Get-Date -Format o) ERROR: $($_.Exception.Message)"
    exit 1
}

Use this Intune install command when the wrapper is included in the package:

powershell.exe -NoLogo -NoProfile -ExecutionPolicy Bypass -File ".\install.ps1"

Download the Microsoft Win32 Content Prep Tool from Microsoft's official GitHub repository, then run IntuneWinAppUtil.exe.

IntuneWinAppUtil.exe -c "C:\IntuneApps\ContosoApp" -s "install.ps1" -o "C:\IntuneApps\Output" -q

• -c: source folder containing all required application files.
• -s: setup file used as the package entry point.
• -o: output folder for the generated .intunewin file.
• -q: quiet mode.

1. Sign in to the Microsoft Intune admin center.
2. Go to Apps → Windows → Create.
3. Select Windows app (Win32).
4. Upload the generated .intunewin file.
5. Complete the app name, description, publisher, version, category, information URL, and privacy URL.
6. Add a clear app icon so users can recognise it in Company Portal.

Enter the exact commands already tested on the clean device.

• Install command: powershell.exe -NoLogo -NoProfile -ExecutionPolicy Bypass -File ".\install.ps1"
• Uninstall command: use a tested PowerShell wrapper or the vendor's silent uninstall command.
• Install behavior: choose System for machine-wide applications and User only when the installer genuinely requires the signed-in user's profile.
• Device restart behavior: normally select Determine behavior based on return codes.
• Installation time: allow enough time for slow applications, but do not hide a hanging installer with an excessive timeout.

Return codes

Requirements decide whether Intune considers the application applicable. A device that does not meet them is not an installation failure; it is Not applicable.

• Select the correct operating-system architecture: 32-bit, 64-bit, or ARM64.
• Set the minimum supported Windows version.
• Use minimum disk space, memory, or processor requirements only when the application genuinely needs them.
• Use a custom requirement script for prerequisites that cannot be expressed with built-in rules.

# Example custom requirement: confirm .NET 4.8 or later
$Release = Get-ItemPropertyValue -Path 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' -Name Release -ErrorAction SilentlyContinue

if ($Release -ge 528040) {
    Write-Output 'Installed'
    exit 0
}

exit 1

Detection does not install the application. It tells Intune whether the expected installed state exists. Intune checks detection before installation and again after the installer finishes.

MSI detection

Use the MSI product code when the application has a stable product code and the vendor's upgrade behaviour is understood. Be careful when every new version receives a new product code.

File detection

Use a stable executable or DLL in the final installation folder. Prefer a version comparison rather than checking only whether the folder exists.

• Path: C:\Program Files\Contoso\ContosoApp
• File: ContosoApp.exe
• Detection method: file or folder exists, version greater than or equal to the deployed version.
• Associated with a 32-bit app on 64-bit clients: select the value that matches the actual installation path and registry view.

Registry detection

Use a vendor-maintained registry value such as DisplayVersion. Confirm whether the key is in the 32-bit or 64-bit registry view.

Custom PowerShell detection

$AppPath = 'C:\Program Files\Contoso\ContosoApp\ContosoApp.exe'
$MinimumVersion = [version]'5.4.0'

if (-not (Test-Path -LiteralPath $AppPath)) {
    exit 1
}

$InstalledVersion = [version](
    [System.Diagnostics.FileVersionInfo]::GetVersionInfo($AppPath).FileVersion.Trim()
)

if ($InstalledVersion -ge $MinimumVersion) {
    Write-Output "Detected $InstalledVersion"
    exit 0
}

exit 1

Use Dependencies when another application must exist first, such as a runtime or framework. Use Supersedence when a new application replaces or updates an older Win32 application.

• Each dependency needs its own accurate detection rule.
• Keep dependency chains short and document their order.
• Choose whether the superseded app should be uninstalled before the replacement installs.
• Test upgrades separately from clean installations.
• Avoid circular dependencies.

Choose the assignment intent carefully:

• Required: Intune installs the application automatically.
• Available for enrolled devices: users install it from Company Portal.
• Uninstall: Intune removes the application from targeted devices.

For machine-wide applications and Autopilot scenarios, I recommend beginning with a device group. Use assignment filters only when their logic is documented and tested.

1. On the Windows device, open Settings → Accounts → Access work or school.
2. Select the connected organisation account, open Info, and select Sync.
3. You can also restart the Microsoft Intune Management Extension service during controlled testing to trigger an IME check-in.
4. In Intune, open Apps → Windows → select the app → Device install status.
5. Open the affected device to see the status details and reported error code.

# Controlled test device only
Restart-Service -Name IntuneManagementExtension -Force

# Confirm the service returned to Running
Get-Service -Name IntuneManagementExtension

1. Assignment: Is the correct user or device included, with no conflicting exclusion or uninstall assignment?
2. Applicability: Does the device meet architecture, OS, disk, memory, and custom requirements?
3. IME health: Is the Microsoft Intune Management Extension installed, running, and checking in?
4. Content download: Did IME receive policy and download the package?
5. Pre-install detection: Did Intune already consider the app installed?
6. Install execution: What exact command and security context were used?
7. Installer result: What exit code and vendor log were produced?
8. Post-install detection: Did the application install but fail detection?
9. Reporting: Has the client sent the latest state to Intune?

Client logs are stored here:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Open logs with CMTrace or another viewer that can follow live changes. Search by the app ID, then correlate entries using the deployment timestamp. Microsoft lists the current IME logs and their purposes in its Intune Management Extension documentation.

# Find recent errors and exit-code references across IME logs
Get-ChildItem 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\*.log' |
    Select-String -Pattern 'error|failed|exit code|0x87D|1603|1618|3010' |
    Select-Object Path, LineNumber, Line

This is one of the most common Intune Win32 app failures. The installer can return success while Intune reports 0x87D1041C because installation and detection are separate checks.

1. Confirm the app is actually installed.
2. Run the detection script manually in the same 32-bit or 64-bit PowerShell context configured in Intune.
3. Run it as System if the application is device-context.
4. Confirm success produces exit code 0 and output.
5. Confirm failure produces a non-zero exit code.
6. Check whether the installed file version contains spaces or a vendor-specific version format.
7. Check Program Files versus Program Files (x86).
8. Check 32-bit versus 64-bit registry redirection.
9. Correct the detection rule, sync, and monitor a new evaluation.

When a Win32 installation fails, Intune can collect diagnostic files from the installation details pane.

1. Open Apps → Windows → select the Win32 app.
2. Open Device install status and select the failed device.
3. Open the installation details.
4. Select Collect diagnostics.
5. Provide exact paths for any additional vendor logs created by your wrapper.
6. After collection completes, download the diagnostics and correlate the logs by timestamp.

Microsoft documents current file, size, and platform requirements in Troubleshooting Win32 app installations with Intune.

An application that installs successfully after sign-in can still fail during Autopilot because the device is in a different state and the installer runs before user resources are available.

• Use System install behavior for required device-stage applications.
• Do not require mapped drives, user profiles, interactive prompts, or user-based network authentication.
• Keep required Enrollment Status Page applications to the minimum needed before desktop access.
• Validate dependencies and restart behaviour.
• Avoid mixing Win32 and line-of-business application installation during traditional Autopilot enrollment when the combination creates installer conflicts. Microsoft notes that mixing is supported in Autopilot device preparation.
• Test on a freshly reset device, not only an already enrolled administrator workstation.

Production-ready Win32 app checklist

• Clean source folder and repeatable package build
• Silent install and uninstall tested locally
• Commands tested under the intended user or System context
• Installer creates a useful local log
• Exit codes mapped correctly
• Requirements match supported devices
• Detection proves the correct installed version
• Dependencies and upgrade path tested
• Required, Available, and Uninstall assignments checked for conflicts
• Pilot deployment succeeds on a clean device
• Autopilot test completed when the app is required during enrollment
• Package owner, source, version, commands, and rollback method documented

Frequently Asked Questions