Deploying applications should be a simple process: you run the installer, and it’s done. Yet that’s often not the case. Any Windows app that isn’t a single MSI usually has to be deployed as a Win32 app, and Intune only accepts Win32 apps as .intunewin files. To create those files, admins use the Intune Win32 Content Prep Tool (IntuneWinAppUtil.exe).
While the tool is relatively simple, small mistakes, like a typo in the setup file, can cause installs to fail. Plus, every time a new app version comes out, you have to start the process from scratch.
This guide covers the full command syntax, every parameter, how to package MSI, EXE, and PSADT apps, what to configure in Intune afterward, and how to keep packages current. If you’re new to the topic, start with our overview of what application packaging is.
What the Intune Win32 Content Prep Tool does
The Intune Win32 Content Prep Tool is a free Microsoft command-line tool that converts an app’s installation files into the .intunewin format and detects some of the attributes Intune needs to determine its install state. This format is required for Intune to install Win32 apps, so converting them is often necessary.
For MSI setup files, the tool also reads the information that Intune needs from the MSI.
The tool compresses everything in the setup folder, including subfolders, into a single .intunewin file. That file holds the encrypted setup files and the information needed to decrypt them, so store it as carefully as the original installers. However, the tool only builds the package; it doesn’t write install commands or detection rules, nor does it upload anything.
What you need before you start
When you use the Intune Win32 Content Prep Tool, you’ll want to prepare to ensure a smooth and efficient process. Make sure you have the following before you start prepping applications:
A Windows machine with .NET Framework 4.7.2; a clean packaging workstation will help avoid pulling unrelated files into the package.
The Content Prep Tool itself, which you can download from Microsoft’s GitHub repo as a .zip. The current version is 1.8.7, and the .zip contains the tool, the license, a readme, and release notes.
An installer that supports silent installation, as Win32 apps deployed through Intune must install without user interaction. Our guides to MSI silent installs and EXE silent installs cover the switches for each.
An app under 30 GB. Intune caps Win32 apps at 30 GB each, so larger apps can’t be deployed this way.
Supported target devices. The devices you deploy to must run Windows Enterprise, Pro, or Education, be registered or joined to Microsoft Entra ID, and be enrolled in Intune.
How to create an .intunewin file with the Content Prep Tool
Once you have everything in place, you can use the Content Prep Tool to create .intunewin files. You can do so in a few steps:
Download and extract the tool from GitHub into its own folder (for example: C:\Tools\ContentPrep).
Create a source folder that holds only the installer and its supporting files, such as MST transforms, config files, or scripts (such as C:\Packages\AppName). The tool packs every file and subfolder in this folder, so both the tool and any unrelated files should stay out of it.
Pick an output folder outside the source folder (such as C:\Output). If it’s inside the source folder, the next run will pack the old .intunewin into the new one.
Run the tool. You can run IntuneWinAppUtil.exe with no parameters, in which case it will prompt for each folder, or run it in one line. Keep in mind that paths with spaces require quotation marks:
IntuneWinAppUtil.exe -c C:\Packages\AppName -s setup.exe -o C:\Output -qCheck the output folder for the new .intunewin file. Be sure to keep a separate output folder for each version of the app so versions don't overwrite each other, especially with -q.
If a supporting file needs to be referenced by the install command, you can put it in a subfolder of the source folder and use a relative path, such as licenses\license.txt.
IntuneWinAppUtil command-line parameters
When you use the Content Prep Tool, you can set parameters, such as running in quiet mode or where the contents go. Understanding these command-line parameters gives you more control over the installation and helps ensure a smooth deployment.
The command-line parameters are:
Parameter | What it does |
-h | Shows usage help |
-v | Shows the tool version (1.8.2 and later) |
-c <setup_folder> | Folder whose entire contents go into the .intunewin |
-s <setup_file> | The setup file, such as setup.exe or setup.msi |
-o <output_folder> | Where the .intunewin is written; created if missing in quiet mode |
-a <catalog_folder> | Catalog files bundled for Windows 10 S mode |
-q | Quiet mode: no prompts, overwrites existing output |
Everything in -q, plus no console output |
Note that if you use both -q and -qq, the latter will take priority.
Additionally, version 1.8.2 added support for redirecting output to a log file, which is useful when packaging runs in a script. For example:
IntuneWinAppUtil.exe -c SomeSample -s Setup.exe -o . -q > test.log
How to package MSI, EXE, and PSADT apps for Intune
If you want to package an app for Intune, the setup file will depend on the installer type. As a result, MSI, EXE, and PSADT installers have a few key differences. Keep these key points in mind when packaging your apps:
MSI installers
When you pass a .msi as the setup file, the tool will read the information Intune needs from the MSI. This makes MSI packages the easiest to set up. If it uses a transform (.mst), be sure to put it in the same source folder so it’ll be included inside the package. Our msiexec silent install guide covers the switches and properties to use in the install command.
While MSIs are easy enough to deploy without wrapping them as Win32, wrapping is sometimes still necessary. Intune’s line-of-business MSI type only allows one command-line argument, so anything more complex requires Win32.
EXE installers
Should you need to pass a .exe as a setup file, you’ll need to set the install and uninstall commands by hand in Intune, along with the detection rules, since the tool only reads app details from MSI files. The silent switches depend on the framework that built the installer, such as Inno Setup, NSIS, or InstallShield. Our guide to EXE silent installs explains how to find them.
PSADT packages
If you use a PowerShell App Deployment Toolkit (PSADT) package, you’ll want to run the tool on the whole deployment folder. From there, use Invoke-AppDeployToolkit.exe as the setup file, so the entire toolkit folder (including Files, Config, and the module) will go into the .intunewin.
For instance, it may look like:
IntuneWinAppUtil.exe -c C:\Packages\YourApp -s Invoke-AppDeployToolkit.exe -o C:\Output
What to configure in Intune after you create the .intunewin
After the .intunewin file is created, you’ll still need to configure Intune to set detection rules, requirement rules, and so on. Go to Apps → All Apps → Create → Windows app (Win32) and upload the .intunewin file, then make the needed configurations. Use the latest version of the Content Prep Tool, since Intune shows a warning when a package was built with an older version.
You can find a more in-depth guide on Microsoft Learn. If you deploy apps from the WinGet repository, see how to deploy WinGet apps with Intune.
Install and uninstall commands
The install and uninstall commands tell Intune how to run the installer. The install command can be a command line, such as ApplicationName.exe /quiet, or an uploaded PowerShell script of up to 50 KB. Calling powershell.exe in either command field launches 32-bit PowerShell, so use %SystemRoot%\Sysnative\WindowsPowerShell\v1.0\powershell.exe when you need 64-bit. The uninstall command doesn’t expand environment variables, so if you need them, include a wrapper script in the package.
When the installer finishes, its exit code tells Intune whether it succeeded (0), needs a retry (1618), or needs a restart to complete (3010 or 1641). You can review and edit how Intune treats each return code when you create the app. A retry code triggers up to three attempts, spaced five minutes apart.
Requirement rules
The requirement rules determine whether a device should receive the app. Every app needs an operating system architecture and a minimum OS version, and you can optionally set disk space, memory, logical processors, and CPU speed. You can also add rules that check files, registry values, or the outcome of a PowerShell script.
Detection rules
With detection rules, you set the parameters for how Intune decides the app is installed. You must set at least one detection rule, and all rules must be met for Intune to detect the app as installed.
There are four types of detection rules:
MSI product code (the Content Prep Tool stores the code in the package, and Intune fills it in when you create this rule)
File or folder
Registry
Custom PowerShell script (the script must exit with 0 and write to STDOUT to verify installation; any STDERR output will mean it’s not counted as installed)
Common mistakes that make Win32 app installs fail
Installing Win32 apps on Intune can have some challenges, even if you follow each step. If you encounter unexpected issues, such as a Win32 app install failing without explanation, you can follow these troubleshooting steps to identify and address missteps.
Common mistakes include:
Packing more than the app: When you pack the file, the tool zips everything in the source folder. This can accidentally include a copy of the tool, old packages, or unrelated files in the .intunewin, inflating the package.
Writing output into the source folder: If the output folder sits inside the source folder, the next build packs the previous .intunewin inside the new one.
An installer that isn't silent: Intune is designed to support silent installs and doesn't support interactive installs. Workarounds like ServiceUI aren't supported, so they can be unreliable at best. Be sure to test the install command from an elevated prompt before packaging.
A detection rule that doesn't match what the installer writes: Sometimes, the install can succeed while Intune reports it as missing. This is where detection rules come in, as you can adjust them to detect the application's specifics.
User-context installs that need admin rights: If a user-targeted Win32 app needs permissions the standard user doesn't have, it will fail. It’s important to ensure the install runs with the required permissions to succeed.
Large installers hitting the timeout: Exceptionally large installations can take too long and time out. The default install time is 60 minutes, but you can configure it up to 24 hours, so you may need to adjust the time limit for larger apps.
An outdated copy of the tool: If you’re using an outdated tool to package your applications, Intune will flag it. Keep the Content Prep Tool up to date, since newer releases fix bugs, such as an older version failing on files over 4 GB.
If you need further help, you can always check out Microsoft'sTroubleshoot Win32 app issues page for log-level diagnosis.
How to update a Win32 app when a new version ships
When a new version of an app is released, you’ll want to update your endpoints quickly. However, each .intunewin file is tied to one installer version, so there’s no simple “update” button: every new version means building and configuring a new package.
Rebuild the package for the new version
When you want to update a Win32 app, you’ll need to rebuild the package for the new version. You can do so in a few simple steps:
Replace the installer in the source folder, or create a new folder for each new version.
Run the Content Prep Tool to build a new .intunewin file using the source folder.
Create the new Win32 app in Intune and update anything version-specific, such as the install command, detection rule, and requirement rules.
Test the new version on a pilot group of devices before rolling it out to a larger group.
Whenever an app updates, you’ll need to repeat this process on every release. For apps that update monthly, this can become a lengthy, repetitive process.
How Intune app supersedence works
Supersedence links the new app to the one it replaces, so Intune knows to update or remove the older version instead of leaving both in place.
To update an app in place, you can turn off “Uninstall previous version.” Turning this on sends an uninstall command to the old app so it’s replaced with the newer one. Note that if the new installer upgrades the old version by itself, there’s no need to uninstall.
A supersedence relationship can include up to 10 apps, with each app linked in the chain counted. You can learn the setup steps for app supersedence on Microsoft’sAdd Win32 app supersedence page.
How to automate Win32 app packaging for Intune
Win32 app packaging for Intune can be time-consuming, especially if you have multiple apps with recurring updates. Fortunately, AI application packaging can take much of that work off your team. That brings us to Splashtop Agentic Packr, an AI-powered app packaging and deployment tool.
Splashtop Agentic Packr can package, validate, and deploy applications via Microsoft Intune, SCCM, and more without the manual work typically required. Because it’s built on PSADT, IT teams can open, review, and adjust any package, and they review test results before anything is published.
Splashtop Agentic Packr covers all the key steps for content prep and packaging, including:
Building the package: Splashtop Agentic Packr analyzes the installer and builds a PSADT package and an Intune package. This can be built from a WinGet or Chocolatey ID, its verified catalog, or your own installer, depending on your organization’s needs.
Detection rules: The AI writes detection rules for each app to verify it was installed correctly.
Testing: Every package is tested on a clean virtual machine and security-scanned before it’s published. IT teams receive a QA scorecard and logs to review each app and update before it goes out.
Publishing: You can connect an Intune tenant with Express connection to publish apps directly while receiving rollout status per device.
New versions: When a new app version becomes available, Splashtop Agentic Packr detects it and automatically builds updated packages, eliminating the need to manually create new packages for each version.
Stop rebuilding .intunewin files by hand
While the Win32 Content Prep Tool works well for creating packages, that’s only the start. IT teams still have to spend hours working on detection rules, testing, and creating new packages for each update.
Splashtop Agentic Packr takes that work off your team’s plate. It builds packages, writes detection rules, runs tests, and keeps apps current, so tested Win32 apps are published to Intune and stay up to date while IT focuses on more complex work.
See how Splashtop Agentic Packr can help your team package and deploy apps faster.
