Most EXE installers were never designed for silent, unattended deployment. They pop UAC prompts, spawn post-install dialogs, and return exit codes that make Intune report failure even when the app installed perfectly. Converting them to a deployable .intunewin package sounds straightforward. In practice, it burns 2 to 5 hours per package if you do it manually.
This playbook covers the full pipeline: what .intunewin actually is, how to extract the right silent switches, how to wrap the EXE correctly, how to write detection rules that hold up in production, and how to get the package into Intune without rework.
What .intunewin Actually Is
A .intunewin file is not a new installer format. It is a compressed archive — a renamed ZIP — that the Intune Management Extension unpacks on the endpoint before executing the installer inside it. Your EXE or MSI runs as-is. Intune just handles the delivery.
That means the wrapper is the easy part. The hard part is making the installer inside it behave: silent, unattended, correct exit codes, detectable afterward.
If you need to decide between .intunewin and a native MSI LOB app, the .intunewin vs MSI breakdown covers the decision criteria in full.
Step 1: Identify the Installer Framework
Before you touch the Win32 Content Prep Tool, know what kind of EXE you are dealing with. Silent switch syntax differs by framework, and using the wrong one either silently fails or launches an interactive UI on the endpoint.
The three most common frameworks in 2026:
- Inno Setup — Look for
[Setup]in the binary strings, or runstrings installer.exe | grep -i inno. Silent switch:/VERYSILENT /SUPPRESSMSGBOXES /NORESTART. - NSIS (Nullsoft Scriptable Install System) — Identifiable by the
Nullsoft Install Systemstring in the PE header. Silent switch:/S. Some NSIS builds also accept/D=C:\TargetDirfor a custom install path. - InstallShield — Common in enterprise and legacy software. Silent switch:
/s /v"/qn"or/s /v"/qb"depending on whether there is an embedded MSI. If there is, you may also need/s /v"/qn REBOOT=ReallySuppress".
Gotcha: InstallShield EXEs that wrap an MSI internally require you to pass MSI properties through the /v flag. Skip this and the inner MSI runs in interactive mode even though the outer EXE is silent.
To identify the framework without guessing, run the EXE through a hex editor or use strings via Sysinternals. InstallMage detects the framework automatically during the AI scan step, which eliminates this manual lookup entirely.
Step 2: Extract or Confirm the Silent Install Switch
This is where most deployments fail. A wrong switch produces one of three outcomes:
- The installer runs interactively on the endpoint — visible to the user, blocks completion
- The installer exits with a non-zero code that Intune interprets as failure
- The installer appears to succeed but installs to the wrong directory or skips components
Finding the Switch Manually
For Inno Setup and NSIS, the switches are usually documented — just rarely somewhere obvious. Try:
installer.exe /?
installer.exe /help
installer.exe --helpIf the vendor documents nothing, fall back to the framework defaults above. They work for the vast majority of standard builds.
For InstallShield, check whether the EXE contains an embedded MSI first:
7z l installer.exeIf you see a .msi file in the output, you are dealing with a wrapped MSI. Extract it and deploy the MSI directly if possible — that path is cleaner. The extract MSI from EXE guide walks through this in detail.
Testing the Switch Before Packaging
Always test the silent switch in a clean VM before wrapping. Run:
installer.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART
echo Exit code: %ERRORLEVEL%Zero means success. 3010 means success with a reboot pending. Anything else is a failure you need to diagnose before the package ever touches Intune.
Gotcha: Some installers return 3010 even when a reboot is not strictly required. Add 3010 to your Intune success exit codes or the deployment will show as failed across your entire device group.
Step 3: Wrap the EXE into .intunewin
Once you have a confirmed silent switch, you have two paths.
Path A: Microsoft Win32 Content Prep Tool (Manual)
Download IntuneWinAppUtil.exe from Microsoft's GitHub and run:
IntuneWinAppUtil.exe -c "C:\Source\MyApp" -s "installer.exe" -o "C:\Output"This produces installer.intunewin. That is all it does. It does not detect your silent switch, does not generate detection rules, and does not produce an uninstall string. You handle all of that yourself.
Path B: Automated Pipeline
If you want the silent switch detected, the .intunewin generated, the detection rule GUID written, and the uninstall string ready to paste — InstallMage runs the full pipeline in under 3 minutes. Upload the EXE, and the AI engine identifies the framework, extracts the correct silent arguments, compiles a WiX-based MSI wrapper in an isolated container, and outputs the .intunewin plus all deployment metadata.
The EXE runs in a stateless Linux container and is permanently deleted after conversion. Nothing is stored or archived.
The free Starter tier covers 3 conversions per month, no credit card required. Pro at $39 per month gives you unlimited conversions, native .intunewin generation, and BYOC code signing via .pfx upload.
Step 4: Write Detection Rules That Hold Up
A deployment without a reliable detection rule is a deployment you will be troubleshooting at 9 PM. Intune needs to confirm the app is installed after the installer exits. If the detection rule is wrong, Intune reinstalls the app on every sync.
File Version Detection
Use this when the app installs a versioned executable:
Path: C:\Program Files\AppName\app.exe
Property: Version
Operator: Greater than or equal to
Value: 2.5.0Gotcha: Do not detect on the installer EXE itself. Detect on the application binary. The installer is gone after it runs.
Registry Detection
Use this for apps that write a consistent registry key on install:
Key path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{ProductCode}
Value name: DisplayVersion
Detection method: String comparison
Operator: Equals
Value: 2.5.0The ProductCode GUID lives under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\. For a 32-bit app on a 64-bit OS, check HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\ instead.
Gotcha: If the vendor changes the ProductCode between minor versions — common with InstallShield packages — your detection rule breaks on the next update. Use DisplayVersion string comparison rather than key existence alone.
MSI ProductCode Detection
If you wrapped the EXE in an MSI (manually or via InstallMage's WiX wrapper), Intune can detect by ProductCode directly. This is the most reliable detection method — Windows Installer maintains the ProductCode registry entry for the lifetime of the installation.
InstallMage outputs the detection rule GUID automatically as part of the package download. No manual registry hunting required.
Step 5: Configure the Win32 App in Intune
With the .intunewin file and deployment metadata ready, add the app in the Intune admin center under Apps > Windows > Add > Windows app (Win32).
Key fields:
- Install command:
installer.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART - Uninstall command: The uninstall string from the registry, or the MSI uninstall command if you wrapped it. For MSI:
msiexec /x {ProductCode} /qn - Install behavior: System (per-machine) for most enterprise apps. Per-user only when the app explicitly requires it.
- Return codes: Add
3010as a soft reboot required code alongside the default0. - Detection rules: Use the file, registry, or ProductCode rule from Step 4.
Get the Install Context Right the First Time
Always deploy as System unless you have a specific reason not to. Per-user installs run under the logged-in user's context — the app does not install on endpoints where no one is logged in, and it installs per-profile rather than per-machine. Most enterprise software expects a per-machine install path.
Gotcha: Some apps check install context during setup and write to different registry hives accordingly. If your detection rule points to HKLM but the app installed to HKCU because you used Per User context, detection fails silently. See the per-machine vs per-user context guide for the full breakdown.
Step 6: Handle the Repackaging Cases
Some EXEs cannot be silently installed as-is. They need a proper MSI wrapper before Intune will handle them reliably.
You need an MSI wrapper when:
- The EXE has no documented silent switch and does not respond to standard framework defaults
- The installer requires interactive input that cannot be suppressed
- You need reliable supersedence or upgrade behavior managed by Windows Installer
- Your SCCM or Intune policy requires signed MSI packages
For the full decision tree and repackaging options, the EXE to MSI guide covers it in detail.
The manual path involves a clean VM, a snapshot tool, an install capture, and WiX or another authoring tool to compile the output. That is a half-day of work per package. InstallMage runs the same WiX-based wrapper compilation in the cloud — no VM, no snapshot, no scripting.
Deployment Checklist
Before you assign the app to a device group:
- Silent switch tested in a clean VM, exit code confirmed zero or 3010
.intunewingenerated from the correct source folder- Install command matches the tested silent switch exactly
- Uninstall command tested and confirmed
- Detection rule validated against a test endpoint
- Install behavior set to System unless per-user is explicitly required
- Return code 3010 added to success codes
- App assigned to a test group before broad deployment
Frequently Asked Questions
What is the difference between a .intunewin file and an MSI?
A .intunewin is a delivery container, not an installer format. It wraps your installer — EXE or MSI — for upload to Intune. An MSI is a Windows Installer database that manages installation, repair, and uninstall natively. When you need reliable supersedence, clean uninstall by ProductCode, or Windows Installer transaction support, you want an MSI. For most EXE-to-Intune scenarios, wrapping in .intunewin with a solid detection rule is sufficient.
Why does Intune show my app as failed even though it installed correctly?
The most common causes: the installer returned 3010 and you did not add it as a success code, the detection rule does not match what the installer actually wrote to disk or registry, or there is an install context mismatch where the app installed per-user but the detection rule checks HKLM.
Can I use the Microsoft Win32 Content Prep Tool instead of a paid solution?
Yes, for wrapping. The Content Prep Tool produces a valid .intunewin file. It does not detect silent switches, does not generate detection rule GUIDs, and does not produce uninstall strings — you supply all of that manually. For a single package, that is manageable. Across dozens of apps, the overhead adds up fast.
How do I find the correct silent switch for an InstallShield EXE?
Run installer.exe /? first. If that produces nothing, try /s /v"/qn". If the EXE wraps an MSI internally (check with 7z l installer.exe), extract the MSI and deploy it directly. That eliminates the InstallShield layer entirely and gives you a clean MSI with a ProductCode you can use for detection.
What happens if the installer requires a reboot?
Add exit code 3010 to your Intune success return codes. Intune marks the deployment successful and handles the reboot according to your device restart policy. Without 3010 in the success list, Intune reports failure and may attempt to reinstall on the next sync.
Is it safe to upload a production EXE to a cloud conversion tool?
That depends entirely on the tool's architecture. InstallMage processes each EXE in an isolated, stateless Linux container and permanently deletes it immediately after conversion. Nothing is stored or archived. If a tool does not explicitly document zero-retention and ephemeral processing, treat that as a risk.
When should I wrap an EXE in an MSI rather than deploying it directly as a Win32 app?
Wrap in MSI when you need Windows Installer to manage the lifecycle: reliable supersedence, clean uninstall by ProductCode, or signed package requirements from a compliance policy. For most standard EXE deployments, a Win32 app with a solid detection rule is the faster path.
The packaging work itself is not complex. The complexity comes from the fragmentation — installer frameworks with different switch syntax, detection rules that require registry spelunking, and a Content Prep Tool that handles exactly one step of a five-step process. Get each step right in sequence and the deployment ships clean the first time.
If you want to skip the manual framework detection and detection rule authoring, InstallMage automates the steps that burn the most time. Start with the free tier, no credit card required.