IntuneWinAppUtil tool explained
Overview
The Microsoft Win32 Content Prep Tool, run as IntuneWinAppUtil.exe, is the utility that wraps a Windows installer and its supporting files into the .intunewin format that Intune requires for Win32 app deployment. Without this step, Intune has nothing to upload: the portal only accepts the .intunewin container, not a raw .exe or .msi sitting in a folder.
This guide explains exactly what the tool produces, the three parameters it depends on, how it differs for MSI and EXE installers, the size and encryption rules you need to know, and how the resulting package flows into the App information step and onto the device. By the end you will understand not just the command, but why each part of it matters.
What does the Win32 Content Prep Tool actually do?
IntuneWinAppUtil.exe takes everything in a source folder, compresses it, and produces a single encrypted .intunewin file. It reads three things from you: the folder that holds your installer (and any dependencies), the name of the primary setup file, and where to write the finished package. It then captures the entire contents of the source folder, not just the setup file you named, which is why folder hygiene matters.
The tool is open source and published by Microsoft at github.com/microsoft/Microsoft-Win32-Content-Prep-Tool. It is intentionally narrow in scope: it does not write your silent install and uninstall commands, it does not test whether the installer succeeds, and it does not create detection rules. It only builds the container. Everything else is configured later in the Intune admin center.
One detail that surprises people: the contents of the .intunewin file are encrypted. The package is protected in storage and in transit, and the Intune Management Extension decrypts and extracts it on the target device at install time. You cannot simply rename a .intunewin to .zip and read it, and you should never try to hand-edit one.
What are the -c, -s, and -o parameters?
The tool runs from a command prompt with three required switches. The syntax is fixed and order-independent:
IntuneWinAppUtil.exe -c <SourceFolder> -s <SetupFile> -o <OutputFolder>A concrete example, packaging an installer that lives in an input folder and writing the result somewhere separate, looks like this:
IntuneWinAppUtil.exe -c C:\Packaging\Input -s install.exe -o C:\Packaging\Output| Switch | Meaning | Common mistake |
|---|---|---|
| -c | Source (content) folder containing the setup file and every dependency. | Pointing at a parent folder that drags in unrelated files. |
| -s | Name of the primary setup file. Must reside inside the source folder. | Giving a full path or a file that lives outside -c. |
| -o | Output folder where the .intunewin is written. | Using the same folder as -c, which mixes source and output. |
| -q | Optional. Quiet mode; suppresses the interactive prompts. | Expecting it to validate the install — it does not. |
If you run IntuneWinAppUtil.exe with no switches, it falls back to interactive mode and prompts you for the same three values one at a time. The command-line form is preferred because it is repeatable and scriptable, which is exactly what you want when you rebuild a package after every installer update.
How does the package flow from folder to device?
The journey from raw installer to deployed app is a short, predictable chain. Understanding it helps you know where packaging ends and the rest of the Win32 app configuration begins.
After the tool writes the .intunewin file, you create a Windows app (Win32) in the Intune admin center and upload the package at the App information step. Intune reads the embedded metadata and pre-fills some fields, then you supply the program commands, requirements, detection rules, and assignments. For a deeper walkthrough of that broader packaging workflow, see how to prepare .intunewin packages.
Is packaging an MSI different from an EXE?
The command is identical, but the metadata captured differs, and that changes what you have to configure afterward. When you point -s at an MSI, the tool reads the MSI product code and other properties out of the installer. Intune can then offer to auto-detect the app using that product code, and it can pre-populate default install and uninstall commands. With an EXE, none of that exists, so you must supply both commands and a detection rule yourself.
| Aspect | MSI setup file | EXE setup file |
|---|---|---|
| Metadata captured | Product code, version, package details | Minimal; no product code |
| Detection | Auto-detection by product code offered | Manual file, registry, or script rule |
| Install command | Often pre-suggested (msiexec) | You must define the silent switches |
| Uninstall command | Derivable from product code | You must define it explicitly |
What are the size and content limits?
The current maximum size for a single .intunewin package used by a Win32 app is 8 GB. That ceiling is generous for most line-of-business installers, but large media or driver bundles can approach it. Keep packages lean: include only the files that one app needs, because the tool captures the whole source folder. A bloated folder produces a bloated, slow-to-download package and makes troubleshooting harder. The principle of one app per source folder, and one source folder per package, keeps everything predictable, as covered in what a Win32 app is in Intune.
Common mistakes and how to avoid them
- Setup file outside the source folder. The file named with -s must physically live inside the -c folder, otherwise the tool errors out. Pass just the file name, not a path.
- Reusing an old package after updating the installer. A new installer version means a new .intunewin. The tool does not auto-refresh anything.
- Trying to inspect or edit the .intunewin. The contents are encrypted; treat the file as a sealed container and rebuild instead of editing.
- Assuming a successful build means a successful install. The tool only validates packaging. Install success depends on your commands, requirements, and the device. Test those separately.
- Mixing source and output folders. Always send -o to a separate, empty directory so the previous build never gets swept into the next package.
Quick checklist
- Place the installer and all dependencies in a single, clean source folder.
- Confirm the -s file name exists inside the -c folder before running.
- Send -o to a separate, empty output directory.
- Keep the package under the 8 GB Win32 limit and free of unrelated files.
- Remember the package is encrypted; rebuild rather than edit, and re-package after every installer update.
- Upload the .intunewin at the App information step, then configure commands, detection, and requirements.
Leave a feedback
Include versions, steps, and any error text if you have them.