MSI packages and Intune have a complicated relationship. The Win32 app deployment pipeline requires a .intunewin file — not a raw MSI. That surprises a lot of admins the first time they try to deploy a standard MSI through the Win32 workflow. The portal accepts it, the deployment fails, and the ticket queue fills up.
This guide covers the exact process to convert an MSI to .intunewin correctly in 2026: what breaks if you skip steps, how to configure detection rules that actually work, and where the Microsoft Win32 Content Prep Tool leaves you on your own.
Why You Need .intunewin Even for MSI Packages
Intune's Win32 app type requires all installer content wrapped in a .intunewin container — an encrypted, compressed archive that the Intune management extension unpacks on the endpoint before running the installer.
Deploy an MSI as a Line of Business (LOB) app instead, and you lose everything Win32-specific: return code handling, dependency chaining, supersedence, and granular detection rules. For anything beyond the simplest MSI, Win32 is the right path.
The .intunewin format does not replace your MSI. It wraps it. Your MSI still runs at install time. The container just gives Intune the control layer it needs.
For a deeper breakdown of when to use each format, see IntuneWin vs MSI Explained.
What You Need Before You Start
- The MSI file you want to deploy
- Microsoft Win32 Content Prep Tool (
IntuneWinAppUtil.exe) — or an automated alternative (covered below) - A staging folder structure: one folder for the source MSI, one for the output
- The MSI's
ProductCodeGUID for detection rules - Silent install switches (typically
/quiet /norestartfor MSI, but verify per vendor)
Gotcha: Some MSIs bundle dependencies or call external EXEs during install. If yours does, every dependency must be in the same source folder before you wrap. A missing dependency silently fails the deployment on any endpoint that doesn't already have it.
Step 1: Extract the ProductCode GUID
Get the ProductCode before you build the detection rule. Don't go back for it later.
Run this in PowerShell:
# Query the MSI database directly for the ProductCode
$msiPath = "C:\Staging\Source\YourApp.msi"
$windowsInstaller = New-Object -ComObject WindowsInstaller.Installer
$database = $windowsInstaller.GetType().InvokeMember(
"OpenDatabase", "InvokeMethod", $null, $windowsInstaller,
@($msiPath, 0)
)
$view = $database.GetType().InvokeMember(
"OpenView", "InvokeMethod", $null, $database,
@("SELECT Value FROM Property WHERE Property='ProductCode'")
)
$view.GetType().InvokeMember("Execute", "InvokeMethod", $null, $view, $null)
$record = $view.GetType().InvokeMember("Fetch", "InvokeMethod", $null, $view, $null)
$record.GetType().InvokeMember("StringData", "GetProperty", $null, $record, @(1))You can also open the MSI in Orca (part of the Windows SDK) and read the Property table directly. Either way, record the GUID. You'll need it in Step 4.
Gotcha: ProductCodes change between versions. Do not reuse the GUID from an older deployment. Pull it fresh from the new MSI every time.
Step 2: Verify Your Silent Install Switches
MSI packages support standard Windows Installer parameters, but not every MSI behaves identically.
The standard silent install command:
msiexec.exe /i "YourApp.msi" /quiet /norestart /l*v "C:\Logs\YourApp_install.log"Key flags:
/quiet— fully silent, no UI/norestart— suppress automatic reboot/l*v— verbose logging, essential for troubleshooting failed deployments
Some MSIs require /qn instead of /quiet. Test both in a clean VM before wrapping. A silent switch that triggers a UAC prompt or post-install dialog stalls the deployment on every endpoint — and Intune reports it as a timeout failure, not a dialog failure. That mismatch costs time.
For uninstall, use:
msiexec.exe /x "{YOUR-PRODUCT-CODE-GUID}" /quiet /norestartReplace {YOUR-PRODUCT-CODE-GUID} with the value from Step 1.
Step 3: Wrap the MSI with the Win32 Content Prep Tool
Set up your folder structure first:
C:\Staging\
Source\
YourApp.msi
(any dependency files)
Output\Then run the Content Prep Tool:
IntuneWinAppUtil.exe -c "C:\Staging\Source" -s "YourApp.msi" -o "C:\Staging\Output"Parameters:
-c— source folder containing the MSI and all dependencies-s— the setup file (your MSI, not a subfolder path)-o— output folder where the.intunewinfile will be written
The tool produces YourApp.intunewin in the output folder. That file is what you upload to Intune.
Gotcha: The -s parameter must point to a file inside the -c folder. If the paths don't align, the tool either errors out or wraps the wrong file. Verify both before running.
Step 4: Upload to Intune and Configure the Win32 App
In the Intune admin center:
- Go to Apps > Windows > Add
- Select Windows app (Win32)
- Upload your
.intunewinfile - Fill in the app information (name, publisher, version)
Install and Uninstall Commands
Install command:
msiexec.exe /i "YourApp.msi" /quiet /norestartUninstall command:
msiexec.exe /x "{YOUR-PRODUCT-CODE-GUID}" /quiet /norestartInstall Behavior
Set to System for machine-wide deployments. Use User only if the MSI explicitly supports per-user install context. Getting this wrong produces install failures with generic error codes — the kind that take an hour to trace back to a context mismatch.
Return Codes
Intune's defaults cover most MSI scenarios:
0— success1707— success3010— success, reboot required1641— success, reboot initiated
Add 1603 as a failure code if it isn't already listed. It's the most common MSI failure code and you want it surfaced clearly, not swallowed.
Step 5: Configure Detection Rules
This is where most deployments go wrong. Intune needs a reliable way to determine whether the app is already installed on an endpoint. A bad detection rule means Intune reinstalls the app on every check-in — or never reports it as installed at all.
Option 1: Registry Detection (Recommended for MSI)
MSI packages write to the registry at install time. Use this path:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{YOUR-PRODUCT-CODE-GUID}In the Intune portal:
- Rule type: Registry
- Key path:
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{YOUR-PRODUCT-CODE-GUID} - Value name:
DisplayVersion - Detection method: String comparison
- Operator: Equals
- Value: The exact version string from the MSI (e.g.,
14.3.2)
Tying detection to a specific version matters for supersedence. If you only check for key existence, Intune can't distinguish between v14.2 and v14.3.
Option 2: File Version Detection
Use this when the MSI installs a binary with a predictable path and version stamp:
- Rule type: File
- Path:
C:\Program Files\YourApp - File or folder:
YourApp.exe - Detection method: File version
- Operator: Greater than or equal to
- Value:
14.3.2.0
Gotcha: Intune does not quote-wrap paths with spaces automatically. A path mismatch means the detection rule never fires, and every device shows as "not installed" regardless of actual state.
Step 6: Assign and Test
Assign to a test group first. Never deploy directly to all devices.
Check the Intune Management Extension log on the test endpoint:
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.logFind your app name in the log. A successful deployment shows the install command, exit code 0 (or 3010), and the detection rule result. A failed detection rule shows the rule evaluation as false even after a confirmed install — that's your signal the rule path or value is off.
Where the Content Prep Tool Stops
The Win32 Content Prep Tool wraps your MSI into .intunewin. That is all it does. It does not:
- Detect or validate silent install switches
- Generate detection rule GUIDs
- Produce uninstall strings
- Output ready-to-paste Intune deployment commands
Everything above the wrapping step is manual. That's manageable for a single app. It compounds fast when you're working through a backlog of 20 legacy MSIs or standing up a new client environment.
Automating the Packaging Pipeline
If you're regularly converting EXE installers into MSI and then wrapping for Intune, the manual steps add up quickly. InstallMage handles the full conversion in under 3 minutes: upload an EXE, get back a .intunewin with ready-to-paste install commands, detection rule GUIDs, and uninstall strings already included.
No local tooling, no scripting, no clean VM required. Each file processes in an isolated container and is deleted immediately after conversion.
The free Starter tier gives you 3 conversions per month at no cost. Pro is $39 per month for unlimited conversions with native .intunewin output and BYOC code signing.
If you're starting from a raw EXE rather than an MSI, the EXE to MSI guide covers that workflow in detail.
Common Failures and What They Mean
Symptom | Likely Cause
-------------------------------------------------|--------------------------------------------------
App shows "Not Installed" after confirmed install| Detection rule path or value mismatch
Deployment times out | Silent switch triggered a UI dialog
App reinstalls on every check-in | Detection rule evaluates false repeatedly
Install fails with error 1603 | MSI dependency missing from source folder
Uninstall fails | Wrong ProductCode GUID or context mismatchFAQs
Do I need to wrap an MSI in .intunewin to deploy it through Intune?
Only if you're using the Win32 app deployment type, which gives you full control over detection rules, return codes, and dependencies. Deploy as a Line of Business app and Intune handles the MSI directly — but you lose all Win32-specific features. For most production deployments, Win32 is the right choice.
What is the correct silent switch for MSI packages?
Standard MSI packages use /quiet /norestart. Some vendors require /qn instead. Always test in a clean VM before wrapping. A switch that triggers a UI prompt stalls the deployment silently, and Intune reports a timeout — not a dialog failure.
How do I find the ProductCode GUID for my MSI?
Query the MSI database using PowerShell with the WindowsInstaller.Installer COM object, or open the MSI in Orca and read the Property table. The ProductCode is a GUID in the format {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}.
Why does Intune keep reinstalling my app even though it's already installed?
The detection rule is evaluating as false. Check the path, key name, and value string exactly. Registry paths are case-insensitive but must be structurally correct. File version comparisons must match the exact version format the binary reports.
Can I include multiple files in a .intunewin package?
Yes. Put all required files in the source folder before running the Content Prep Tool. The -s parameter specifies the primary setup file; everything else in the source folder is included automatically.
What is the difference between per-machine and per-user install context in Intune?
Per-machine (System context) installs for all users and writes to HKEY_LOCAL_MACHINE. Per-user installs under the logged-in user's profile and writes to HKEY_CURRENT_USER. Most enterprise MSIs are per-machine. Mismatching the install context to the detection rule path is one of the most common sources of false "not installed" reports. See Per-Machine vs Per-User Installs in Intune for the full breakdown.
Does the Microsoft Win32 Content Prep Tool generate detection rules or uninstall strings?
No. It only wraps the source folder into a .intunewin container. Detection rules, uninstall strings, and install commands are all configured manually in the Intune admin center after upload.
Conclusion
The MSI to .intunewin conversion is straightforward once you have the ProductCode, verified silent switches, and a correctly structured source folder. The failure points are almost always in the detection rule or the install context — not the wrapping step itself.
Get the ProductCode before you wrap. Test the silent switch in a clean VM. Match your detection rule to the exact registry path or file version the MSI writes. Those three steps eliminate the majority of failed Win32 deployments.
If you want the detection GUIDs, uninstall strings, and .intunewin output generated automatically — without the manual steps — InstallMage covers the full pipeline.