Win32 app deployment in Intune is where most packaging pain lives. The process looks straightforward on paper: wrap your file, upload it, configure a detection rule, assign it. In production, it falls apart at every one of those steps. Wrong silent switch. Misclassified install context. Detection rule that never fires. Exit code flagged as failure when the app installed cleanly.
This guide covers the full Win32 deployment pipeline as it stands in 2026 — from package preparation through detection rules, install context, supersedence, and the specific failure modes that burn the most time.
Why Win32 Apps, Not LOB MSIs
Intune supports two app types for desktop software: line-of-business (LOB) MSI and Win32 apps. The portal makes them look equivalent. They are not.
LOB MSI uploads are limited to simple MSI installs. You get basic install/uninstall, no pre/post-install logic, no dependency chaining, no custom detection rules, and no control over install arguments beyond what the MSI exposes through transforms. If the MSI behaves badly — wrong install context, missing prerequisites, stubborn exit codes — you have no levers to pull.
Win32 apps give you full control. You define the install command, uninstall command, detection rule, return codes, and install context. You can wrap any EXE, MSI, or script. You can chain dependencies. You can handle 32-bit apps on 64-bit endpoints correctly.
Use Win32 for everything except the simplest, well-behaved MSIs. The overhead is worth it every time.
Step 1: Package Preparation
Intune requires Win32 apps to be packaged as .intunewin files. The official tool is the Microsoft Win32 Content Prep Tool — a command-line utility that wraps your installer and its dependencies into a single encrypted .intunewin archive.
Basic packaging command
IntuneWinAppUtil.exe -c "C:\Packages\MyApp" -s "setup.exe" -o "C:\Output"-c— source folder containing the installer and any supporting files-s— the setup file Intune will call (must be inside the source folder)-o— output folder for the.intunewinfile
The Prep Tool wraps everything in the source folder, encrypts it, and produces a single .intunewin. That file is what you upload to Intune.
The catch: the Prep Tool only wraps files. It does not detect silent switches, does not generate detection rules, and does not produce uninstall strings. You handle all of that manually after the wrap.
Step 2: Silent Install Switches
This is where most deployments fail. The app installs interactively on your test machine, then sits at a UAC prompt or dialog on every endpoint because the silent switch is wrong or missing.
Common frameworks and their switches
- MSI-based:
/qn(silent) //qb(passive) - Inno Setup:
/VERYSILENT /SUPPRESSMSGBOXES(silent) //SILENT(passive) - NSIS:
/S - InstallShield:
/s /v"/qn"(silent) //s /v"/qb"(passive) - WiX-based MSI:
/qn(silent) //qb(passive)
Gotcha: InstallShield wraps an MSI internally. The outer EXE takes /s, but the inner MSI still needs its own quiet flag passed via /v. Passing only /s leaves the inner MSI UI visible.
Gotcha: Some NSIS installers use /S (uppercase) and some use /s (lowercase). They are not interchangeable. Test both if the first fails.
Gotcha: Inno Setup without /SUPPRESSMSGBOXES will still surface error dialogs even in silent mode. Always include both flags together.
Identifying the framework manually means inspecting the EXE header, checking for embedded MSI streams, or hunting through vendor documentation that may not exist. That process takes anywhere from 10 minutes to an hour per app.
If you want to skip that entirely, InstallMage auto-detects the installer framework — Inno Setup, NSIS, InstallShield — and extracts the correct silent arguments automatically. The output includes ready-to-paste install and uninstall commands.
Step 3: Install Context
Install context is one of the most misunderstood settings in Intune Win32 deployment. Get it wrong and you get silent failures, apps that appear installed for one user but not another, and detection rules that never match.
System vs. User context
System context — the app installs under NT AUTHORITY\SYSTEM. It writes to HKLM, installs to C:\Program Files, and is available to all users on the endpoint. Use this for the vast majority of corporate software.
User context — the app installs under the signed-in user's account. It writes to HKCU, installs to %APPDATA% or %LOCALAPPDATA%. Use this only when the vendor explicitly requires it or the app is per-user by design.
Gotcha: Running a per-machine installer in user context will either fail silently or install into the user profile in a broken state. The reverse — running a per-user installer in system context — often fails because %APPDATA% resolves to the SYSTEM profile, not the user's.
Always check the installer's target directory and registry writes before choosing context. For the full decision framework, see per-machine vs per-user installs in Intune.
Step 4: Detection Rules
Detection rules tell Intune whether the app is installed. A deployment that completes successfully but has a broken detection rule will report as failed — and Intune will retry the install on every check-in cycle.
You have three detection rule types: MSI product code, file/folder, and registry.
MSI product code detection
Use this only for pure MSI installs where the ProductCode is stable across versions. ProductCodes change between versions by design. If you hardcode a ProductCode for a versioned app, detection breaks the moment you update.
ProductCode: {A1B2C3D4-E5F6-7890-ABCD-EF1234567890}File detection
Reliable for most Win32 apps. Point to the main executable and check the version attribute.
Path: C:\Program Files\Acme\App
File: acme.exe
Detection method: Version
Operator: Greater than or equal to
Value: 3.2.1Gotcha: Do not detect on a folder alone. Folders persist after uninstall in many apps. Detect on a specific file with a version check.
Registry detection
Use this when the app registers itself in the standard uninstall keys. It's the most consistent method for apps that write proper uninstall entries.
Key path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{ProductGUID}
Value name: DisplayVersion
Detection method: Version comparison
Operator: Greater than or equal to
Value: 3.2.1Gotcha: 32-bit apps on 64-bit endpoints write to HKLM\SOFTWARE\WOW6432Node\, not HKLM\SOFTWARE\. If your detection rule points to the 64-bit hive for a 32-bit app, it will never match. Enable the "associated with a 32-bit app on 64-bit clients" toggle in the Intune portal when this applies.
For a deeper look at when to use .intunewin versus a straight MSI upload, the .intunewin vs MSI breakdown covers the tradeoffs in detail.
Step 5: Return Codes
Intune interprets exit codes from your install command to determine success or failure. The defaults cover most scenarios, but legacy apps and custom installers often return non-standard codes.
Default return codes in Intune
0— Success1707— Success3010— Success, reboot required1641— Success, reboot initiated1618— Retry (another install in progress)
Add custom return codes in the portal under the app's return code configuration. If a vendor installer returns 2 for success — common in some legacy apps — add it as a success code. Without it, Intune marks the deployment failed and retries indefinitely.
Gotcha: A misclassified exit code shows up as failure in the Intune portal even when the app installed perfectly. Always test your install command in a clean VM and capture the actual exit code before configuring the deployment. The full exit code reference covers every code you'll see in production.
Step 6: Dependencies and Supersedence
Dependencies
Dependencies let you chain app installs. If your app requires Visual C++ Redistributable or .NET 6, configure it as a dependency in Intune. Intune installs dependencies first, in order, before the target app.
Set the dependency to auto-install. If you set it to detect-only, Intune checks for the dependency but does not install it — the parent app will fail on any endpoint where the dependency is missing.
Supersedence
Supersedence tells Intune that this deployment replaces a previous version. Configure it correctly and Intune handles the upgrade path: it uninstalls the old version (if you configure uninstall on supersedence) and installs the new one.
Do not skip supersedence configuration when updating apps. Without it, you end up with both versions on the endpoint, conflicting detection rules, and deployment loops.
Wrapping Legacy EXEs: The Hard Part
Everything above assumes you have a well-behaved installer. Legacy EXEs are a different problem.
Many corporate environments still run software built on Inno Setup, NSIS, or InstallShield from the early 2000s. Vendor documentation is nonexistent. Silent switches are undocumented. There is no MSI wrapper. The traditional approach: spin up a clean VM, run the EXE interactively, capture the file system and registry deltas, and repackage. That process takes 2 to 4 hours per app when it works. When the capture is incomplete or the app behaves differently across OS versions, you start over.
The faster path is a tool that handles framework detection and silent argument extraction automatically. InstallMage takes the raw EXE, identifies the installer framework, extracts the correct silent switches, compiles a WiX-based MSI wrapper, and outputs a ready-to-deploy .intunewin with detection rule GUIDs and uninstall strings already generated. The whole pipeline runs in under 3 minutes in an isolated cloud container. The EXE is deleted immediately after conversion — nothing is stored.
That covers the exact gap the Microsoft Win32 Content Prep Tool leaves open. The Prep Tool wraps files. It does not detect silent switches, does not generate MSI wrappers, and does not produce detection rules. You still do all of that manually. InstallMage closes that loop.
For a direct comparison of the manual PSADT scripting approach versus automated MSI conversion, the PSAppDeployToolkit vs MSI conversion guide is worth reading before you commit to either path.
Common Deployment Failures and Root Causes
- App shows "Failed" but is installed on endpoint → wrong exit code classification
- Detection rule never matches → 32-bit app in 64-bit registry hive
- App installs for one user, not others → per-user install in system context
- UAC prompt appears during silent deployment → missing or wrong silent switch
- Deployment loops on every check-in → detection rule points to folder, not file
- Upgrade leaves both versions installed → supersedence not configured
- Install fails with error 1618 → another install running; Intune will retry
Deployment Checklist
Before you submit any Win32 app to Intune, run through this list:
- Installer framework identified (MSI, Inno Setup, NSIS, InstallShield)
- Silent switch tested in a clean VM — exit code captured
- Install context set correctly (system vs. user)
- Detection rule targets a versioned file or registry value, not a folder
- 32-bit/64-bit registry hive flag set if app is 32-bit
- Custom exit codes added for non-standard success codes
- Uninstall command tested and confirmed
- Dependencies configured with auto-install enabled
- Supersedence configured if this replaces a previous version
- Assignment scoped to a test group before broad deployment
A Note on Scale
If you manage packaging across multiple clients or more than a few dozen apps, the per-app overhead compounds fast. Two to five hours per legacy EXE adds up to a significant chunk of weekly capacity.
The Intune deployment best practices post covers how to standardize your packaging workflow across environments. For MSP environments specifically, the MSP and Teams tier at $99 per month includes priority VIP queueing and supports files up to 3 GB — built for the throughput that multi-client packaging demands.
Frequently Asked Questions
What is the difference between a Win32 app and an LOB app in Intune?
LOB apps support simple MSI installs with limited configuration. Win32 apps support any installer type, custom install and uninstall commands, full detection rule control, dependency chaining, and supersedence. Use Win32 for anything beyond a basic, well-behaved MSI.
Why does my Win32 app show as failed in Intune when it installed correctly?
The most common cause is a misclassified exit code. If your installer returns a non-standard success code — anything other than 0, 1707, 3010, or 1641 — Intune marks it as failed. Add the actual exit code as a success code in the app's return code configuration.
What silent switch should I use for an Inno Setup installer?
Use /VERYSILENT /SUPPRESSMSGBOXES. Using only /VERYSILENT without /SUPPRESSMSGBOXES can still surface error dialogs during a silent deployment.
How do I detect a 32-bit app installed on a 64-bit endpoint?
32-bit apps write to HKLM\SOFTWARE\WOW6432Node\ on 64-bit systems, not HKLM\SOFTWARE\. In the Intune portal, enable the "associated with a 32-bit app on 64-bit clients" toggle on your registry detection rule, or your rule will never match.
What does the Microsoft Win32 Content Prep Tool not do?
It wraps files into a .intunewin archive. It does not detect silent switches, does not generate MSI wrappers, does not produce detection rule GUIDs, and does not generate uninstall strings. You configure all of that manually after wrapping.
When should I use file detection versus registry detection in Intune?
Use file detection with a version check when the app installs a versioned executable in a predictable path. Use registry detection when the app writes a proper uninstall entry to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\. Avoid folder-only detection — folders persist after uninstall and will falsely report the app as installed.
How do I handle a legacy EXE with no documented silent switch?
Identify the installer framework first — Inno Setup, NSIS, and InstallShield each have known silent arguments. If you cannot identify the framework by inspecting the EXE, use a tool that automates framework detection. InstallMage identifies the framework automatically and extracts the correct silent arguments without manual investigation. Start with a free conversion.
Win32 app deployment in Intune has a lot of moving parts, but the failure modes are predictable. Get the silent switch right, set the correct install context, build a detection rule that targets a versioned file or registry value, and handle your exit codes. That covers 90% of deployments. The remaining 10% is legacy EXE repackaging — and that is where automation pays for itself fastest.