Intune Win32 app deployment

Most enterprise Windows applications ship as MSI installers, EXE installers, or some combination — collectively called Win32 apps in Intune. Deploying them via Intune requires packaging into the IntuneWin format and defining detection, install, and uninstall logic. It's how cloud-managed Windows estates handle the long tail of apps not in the Microsoft Store.

The IntuneWin package

Intune Win32 apps are packaged as .intunewin files — a wrapped container produced by the Microsoft Win32 Content Prep Tool. The tool takes a folder containing your installer (MSI, EXE, and any supporting files) and produces a single signed package that Intune distributes.

A simple invocation:

IntuneWinAppUtil.exe -c "C:\source\acme-app" -s "setup.exe" -o "C:\output"

The output .intunewin is uploaded to Intune.

Configuration in Intune

After uploading, Intune asks for:

Program

• Install command — setup.exe /silent /quiet or msiexec /i package.msi /quiet.
• Uninstall command — typically msiexec /x {GUID} /quiet for MSIs.
• Install behaviour — system context (most apps) or user context.
• Restart behaviour — handle, suppress, or allow restarts.

Requirements

• OS architecture and minimum version.
• Disk space, memory, CPU.
• Custom detection scripts for more complex requirements.

Detection rules

How Intune determines whether the app is already installed:

• MSI product code — if it's an MSI, this works automatically.
• Registry value — HKLM\SOFTWARE\Vendor\Product\Version exists and equals X.
• File or folder — C:\Program Files\Vendor\app.exe exists with version X.
• Custom detection script — PowerShell that returns success/failure.

Get detection rules right. Wrong detection = "installation succeeded but Intune thinks it failed" or vice versa.

Dependencies and supersedence

• Dependencies — other apps that must be installed first (visual C++ redistributables, .NET runtimes).
• Supersedence — this app replaces an older version. Specify what to uninstall first, what to leave.

Assignments

• Required (install now), available (let users pick), or uninstall (remove from devices).
• Targeted at users or devices.
• Optionally with delivery optimisation, scheduled time, etc.

Common pitfalls

• Detection rules wrong — the most common failure mode. Test in a controlled environment first.
• Silent install flag wrong — MSI typically /quiet, EXE varies by vendor. Read the vendor's docs or experiment.
• App needs user context — some apps install to the user's profile (Chrome user-mode install, for example). Use user context, not system, for those.
• Reboot prompts — apps that reboot mid-install can leave users in a bad state. Suppress reboots and chain them in maintenance windows.
• Network latency — large packages from regions far from Microsoft's CDN take long to download; use delivery optimisation features.

Win32 vs MSI vs Microsoft Store vs LOB

Intune supports multiple app types:

• Win32 app — .intunewin package, max flexibility, covers most scenarios.
• Line-of-business (LOB) app — simpler MSI deployment without the IntuneWin wrapper. Limited features but useful for straightforward MSIs.
• Microsoft Store app — UWP apps from the Microsoft Store, simple deployment.
• Microsoft 365 Apps — a first-class app type for Word, Excel, etc.
• Web apps — link to a URL pinned as an app.

For most enterprise apps with installers, Win32 is the right type. It's the most powerful but also the most setup-heavy.

For Intune-managed Windows estates, Win32 app deployment is the core skill that replaces traditional software distribution methods like SCCM and packaging studios.