Best practices for packaging Win32 apps

Why does package structure matter for Win32 apps?

A Win32 app is delivered to Intune as a single encrypted .intunewin file produced by the Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe). The tool takes a source folder, a setup file inside that folder, and an output folder, then wraps and encrypts everything in the source folder into one package. That has a direct consequence for hygiene: whatever you leave in the source folder ships inside the package. Stale installers, old MSPs, unrelated scripts, or a copy of last quarter’s build all inflate the upload, slow the download to the device, and make it harder to reason about what is actually being installed.

Keep one source folder per application, and put only the files that installer needs into it — the setup binary, any transform or configuration file it consumes, and supporting scripts. Use a consistent layout across all your packages (for example a predictable parent path with one subfolder per app) so that anyone on the team can find the source, rebuild the .intunewin, and understand the package without a tour. The current maximum size for a single .intunewin file is 8 GB; clean folders keep you comfortably under that and keep IME downloads fast. For the full mechanics of wrapping, see how to prepare .intunewin packages and the IntuneWinAppUtil tool reference.

IntuneWinAppUtil.exe -c .\Input -s installer.msi -o .\Output

How should you write install and uninstall commands?

Predictable commands are the heart of a maintainable package. The install command must run completely silently — no dialogs, no “Next” buttons, no prompts that wait forever on a device where no one is watching. For MSI packages that usually means msiexec with quiet and no-restart flags; for EXE installers it means the vendor’s documented silent switch, which varies by installer technology. Get the right switches for each installer family from silent install switches for common installers before you wrap the package.

Always pair the install command with a matching, tested uninstall command. Intune uses the uninstall command for the Uninstall assignment intent and for app supersedence, so an app that installs cleanly but cannot be removed is only half packaged. Standardize on a pattern and keep both commands in your package documentation. A typical MSI pair looks like this:

msiexec /i "installer.msi" /qn /norestart
msiexec /x {PRODUCT-CODE-GUID} /qn /norestart

System or user context: which should you pick?

On the Program tab you choose whether the install runs in System or User context. System context runs the installer as the local SYSTEM account, installs device-wide regardless of who is signed in, and is the common default for most applications. User context runs in the signed-in user’s session and requires a user to be present, which suits per-user installers that write to the user profile or HKCU. Choosing the wrong context is a frequent packaging mistake: a per-machine installer forced into user context, or a per-user app deployed as System where it never appears for the user. Match the context to how the installer is designed to install, and make detection match the same scope. The distinction is covered in system vs user context in Intune.

How do you make detection rules reliable?

Detection is how Intune decides whether the app is already installed. If detection is wrong, everything downstream is wrong: Intune will report “installed” when nothing is there, or keep reinstalling an app that is already present. You can manually configure detection rules, or use a custom detection script instead. There are four rule types to choose from:

• MSI — Intune auto-detects using the MSI product code. The simplest and most reliable choice for MSI installers because the product code is exactly what the installer registers.
• File — checks for a file existing, a version, a date, or a size at a stable path. Use a path that the installer always writes, never a temp or per-user location that varies by machine.
• Registry — checks a key or value, optionally a version comparison. Good when the app writes a reliable version stamp under HKLM.
• Custom script (PowerShell) — for anything the built-in rules cannot express. The script must report “detected” by both exiting 0 and writing output to STDOUT; exit 0 with no output is treated as not detected.

Whatever rule type you choose, test it against the actual post-install state — install on a clean machine, then confirm the file, registry value, or product code your rule targets really exists. Detection that was written from assumption rather than observation is the single most common reason a package behaves unpredictably. Full coverage lives in Intune detection rules explained.

How do requirement rules and return codes affect the result?

Two settings determine whether your install command even runs and how its outcome is interpreted. Requirement rules are evaluated before detection and before the install command — they gate applicability by OS architecture (x86/x64/ARM64) and minimum operating system, with optional checks for disk space, physical memory, logical processors, CPU speed, or a custom file/registry/script requirement. Set these deliberately so a package never attempts to install where it cannot succeed; that keeps your failure reports meaningful instead of full of unsupported devices.

Once the command runs, Intune interprets the process exit code against the mapped return codes. Knowing the defaults prevents a successful install from being reported as a failure (or vice versa):

On the Program tab, restart behavior can be “No specific action”, “App install may force a device restart”, “Determine behavior based on return codes”, or “Intune will force a mandatory device restart”. Pairing return-code mapping with the right restart behavior is what makes reboot-requiring installers behave predictably. See return codes and install behavior in Intune for the full mapping logic.

What does a clean packaging workflow look like?

Treat packaging as a short, repeatable pipeline rather than a one-off. Each stage feeds the next, and documenting the output of each stage is what makes the package troubleshootable later.

How should you pilot a package before broad rollout?

Never make an app’s first audience your whole estate. Assign the package as Required or Available to a small pilot group first. Required apps install automatically in the background on targeted devices and may surface a toast notification; Available apps appear in Company Portal for users to install on demand (Available needs a user, so it is not supported for device-only targeting). During the pilot, confirm four things: the app installs silently, the uninstall command removes it, detection flips to “installed” only when it truly is, and any reboot behaves as expected.

When something does not work, the device tells you why. The Intune Management Extension (IME) — the “Microsoft Intune Management Extension” service that runs all Win32 and PowerShell-script processing — writes detailed logs to C:\ProgramData\Microsoft\IntuneManagementExtension\Logs, with IntuneManagementExtension.log and AppWorkload.log being the most useful for app installs (read them with CMTrace). IME checks for new Win32 policy roughly every hour, and also after a restart or service restart; a manual sync forces a check-in, so you do not have to wait an hour to retest a fix. Note that this hourly app cycle is separate from the general Windows MDM device check-in, which runs on a longer, variable schedule. The packaging details above are exactly what determine whether those logs show a clean success or a puzzle — see troubleshoot Win32 app deployment failures when a pilot install does not land.