How to prepare .intunewin packages

What is a .intunewin file?

A .intunewin file is a single container that holds everything in your source folder plus a small metadata file describing the package. When you build it, the Content Prep Tool reads the source folder, records details about the chosen setup file, compresses the contents, and encrypts the payload. The encryption is why you can never just rename a ZIP to .intunewin — Intune validates and decrypts the wrapped content, and the Intune Management Extension on the device unwraps it before running your install command.

Everything that sits inside the source folder ships inside the package, so the folder is your unit of deployment. If your installer needs a transform file, a configuration XML, a license file, or a wrapper script, those belong in the source folder so they travel with the installer to the endpoint.

Why does Intune require this format?

Win32 deployments are handled by the Intune Management Extension rather than the native MDM channel used for simpler app types. Packaging into .intunewin gives Intune one predictable, encrypted object it can store in the service and stream down to targeted devices, regardless of whether the underlying installer is an EXE, an MSI, a batch file, or a PowerShell script. The format also lets the service capture metadata up front — most usefully, when the setup file is an MSI, the tool reads the MSI product code, which Intune can reuse to auto-generate an MSI detection rule.

The tool is open source and published by Microsoft at github.com/microsoft/Microsoft-Win32-Content-Prep-Tool. If you want a deeper look at how it parses input and what the metadata contains, see IntuneWinAppUtil tool explained, and for the broader picture of where this fits, see what a Win32 app is in Intune.

How do I create a .intunewin package?

Packaging is a three-input operation: a source folder, the setup file inside it, and an output folder. The command-line syntax is:

IntuneWinAppUtil.exe -c <SourceFolder> -s <SetupFile> -o <OutputFolder>

The three switches map directly to the inputs above:

• -c the content (source) folder that contains the installer and every supporting file.
• -s the setup file — the entry point recorded in the package (the EXE, MSI, CMD, or PS1 that starts the install).
• -o the output folder where the generated .intunewin is written. Keep this outside the source folder so old packages are never swept into a future build.

If you run the tool with no switches at all, it prompts you interactively for the same three values. For a scripted, non-interactive build, supply every switch and add -q for quiet mode:

IntuneWinAppUtil.exe -c .\Input -s setup.exe -o .\Output -q

-q suppresses the interactive prompts, which is what you want when scripting builds. The output file is named after the setup file with the .intunewin extension — packaging setup.exe produces setup.intunewin.

How do I choose the setup (entry-point) file?

The setup file you pass to -s is metadata only — it tells the tool which file is the package’s primary entry point and, for MSIs, where to read the product code. It does not set the command Intune runs at install time; you define that separately when you create the app. That said, the entry point you package should match how you intend to start the install, because it keeps the package, the install command, and the detection rule aligned.

For EXE and CMD entry points there is no product code, so plan a File, Registry, or custom-script detection rule. If you are unsure which silent flags an installer accepts, see silent install switches for common installers before you finalize the command.

What are the size limits and constraints?

A single .intunewin package can be up to 8 GB for a Win32 app. That is generous, but bloated packages slow uploads and downloads to devices, so include only the files the install genuinely needs. Resist the temptation to drop the Content Prep Tool, previous output packages, screenshots, or test logs into the source folder — they would all be encrypted into the payload and shipped to every targeted device.

• Reference supporting files by relative path from inside the package, never by a network share that may be unreachable at install time under the SYSTEM account.
• Use simple folder names without special characters to avoid quoting problems in the build command.
• Build a fresh source folder per app version so old binaries never leak into a new package.

What happens after I upload the package?

In the admin center you start a new app, choose Windows app (Win32), and upload the .intunewin in the App package file step. The service validates the upload and surfaces the package metadata; for an MSI it pre-fills the product code and install/uninstall commands. From there you configure app information, program settings (install/uninstall commands and install behavior), requirement rules, detection rules, and assignments — none of which are baked into the .intunewin itself.

The package is delivered and decrypted on the device by the Intune Management Extension, which checks for new Win32 app policy roughly every hour and after a device or service restart. Re-uploading a new .intunewin to an existing app is treated as a content update for already-assigned devices.

Common packaging mistakes