.intunewin vs MSI: Which to Use for Microsoft Intune

Microsoft Intune accepts both pure MSI line-of-business apps and Win32 apps packaged as .intunewin. The portal makes them look interchangeable. They are not. Choosing the wrong format usually does not fail loudly — it fails slowly, in production, on the laptops of your most senior staff.

Here is the decision matrix we use for every deployment.

What each format actually is

MSI (Line-of-Business app)

A pure MSI uploaded as "Line-of-business app". Intune treats it as a first-class Windows Installer payload — detection, uninstall, repair, and per-machine vs. per-user are inferred from the MSI metadata.

.intunewin (Win32 app)

A .intunewin is essentially an encrypted ZIP produced by the Microsoft Win32 Content Prep Tool. It can wrap anything: an MSI, an EXE, a PowerShell script, a folder of payload files. You define the install command, uninstall command, and detection rule manually in the portal.

The decision matrix

Use pure MSI when:

• You have a clean, vendor-supplied MSI with no transforms needed.
• You do not need to set custom MSI properties or pass parameters.
• You want the simplest possible upload — Intune reads the ProductCode and you are done.
• You want repair-on-demand to work with zero configuration.

Use .intunewin (Win32 app) when:

• The vendor only ships an EXE.
• You need to run a pre-install script (e.g. uninstall a previous version, set permissions).
• You need custom detection rules — registry keys, file versions, or PowerShell scripts.
• You are deploying multiple files (config files, license files, custom certs).
• You need supersedence (replacing or upgrading a previous app cleanly).
• You need to control install context (system vs user) explicitly.
• You want richer requirement rules (OS version, disk space, RAM).

The hidden gotchas

MSI as LOB does NOT support custom install args

Intune's LOB MSI flow ignores most command-line parameters. If your MSI needsTRANSFORMS= or a custom INSTALLDIR, wrap it as a Win32 app instead.

.intunewin re-wrap on every change

Updating the install command requires re-running the Content Prep Tool and re-uploading. Plan your install command before you wrap.

MSI ProductCode detection only

LOB MSI deployments detect via ProductCode only. If a future version ships with a new ProductCode, your detection breaks silently — no error, just stuck at "Not installed". Win32 apps with file-version detection age more gracefully.

32-bit vs 64-bit context

Intune Win32 apps run in 64-bit context by default. PowerShell detection scripts that probe HKLM\Software may miss 32-bit registry entries underHKLM\Software\WOW6432Node. Use the $env:ProgramFiles(x86)path or explicitly enumerate the 32-bit hive.

Quick-reference cheat sheet

Format       | Best for                                  | Detection
-------------|-------------------------------------------|---------------------
MSI (LOB)    | Clean vendor MSI, no scripts, no params   | ProductCode (auto)
.intunewin   | EXE, scripts, multi-file, supersedence    | File / Reg / Script
PSADT-wrap   | Complex preflight (kill processes, etc.)  | File / Reg / Script
EXE (legacy) | Avoid — almost always better as Win32     | n/a

The decision in one sentence

If you have a vendor MSI and zero customization, ship it as MSI LOB. For everything else, wrap it as .intunewin.

Skip the manual wrap step

InstallMage natively generates both formats from a single EXE upload — MSI for broad compatibility, .intunewin with detection rules pre-filled for Intune. The Pro tier also outputs an Intune deployment cheat sheet with the install command, uninstall command, and detection rule formatted for direct paste into the portal.

See the bigger picture in our Intune Win32 best-practices guide or the complete EXE-to-MSI walkthrough.