Deploying Win32 Apps with Microsoft Intune (2026 Guide)

Once a device is enrolled in Microsoft Intune, the next question is always the same: how do you actually get real-world software onto it? For most line-of-business apps, utilities and third-party tools, the answer is a Win32 app — Intune’s most flexible app type, and the one every Intune admin ends up learning properly sooner or later. This guide walks through packaging, detection, requirements and assignment, and the handful of places deployments most commonly go wrong.

What Makes an App a “Win32 App” in Intune?

Intune supports several app types — Microsoft Store apps, line-of-business (LOB) MSI/APPX packages, web links, and Win32. Win32 is the catch-all, general-purpose format: it wraps an EXE, MSI, or install script (including a full PSAppDeployToolkit package) into a single .intunewin file, then gives you full control over install/uninstall commands, detection logic, requirements, dependencies and supersedence. For anything beyond a simple single-file MSI, Win32 is the default choice for most organisations in 2026, precisely because every other app type is really a narrower, less configurable version of it.

The trade-off is that Win32 puts more of the decision-making in your hands. There’s no automatic detection the way there is for a Store app — you tell Intune exactly how to recognise a successful install, and if that logic is wrong, the deployment will look broken even when the software installed perfectly.

Packaging: The Win32 Content Prep Tool

Before anything can be uploaded to Intune, the source files (installer, plus any supporting scripts or config) need converting into the .intunewin format. Microsoft’s own Win32 Content Prep Tool does this: point it at a source folder and the setup file inside it, and it produces a single encrypted .intunewin package ready to upload. It’s a free, actively maintained command-line tool — no separate licensing, no GUI required, and it still gets regular updates.

For anything more involved than “just run this installer silently,” many admins wrap the install in PSAppDeployToolkit first (pre-install checks, user prompts, logging, close-running-app handling) and then run the whole toolkit folder through the prep tool. That combination remains the de facto standard for complex Win32 packaging in 2026.

Detection Rules: Where Most Deployments Actually Fail

The Intune Management Extension checks the detection rule before attempting an install — if the rule already matches, it skips straight past, which is also how Intune avoids re-installing software that’s already present. After the install command runs, the same rule is checked again to decide whether to report success or failure. Getting this rule right matters more than getting the install command right, because a wrong detection rule reports a perfectly successful install as failed (or worse, a broken install as successful).

• MSI product code — the simplest and most reliable option, but only works when the app is a genuine MSI.
• File — checks for a specific file’s existence, version, or modified date. Common for EXE and script-based installs, but brittle if the file path changes between app versions.
• Registry — checks a key or value the installer writes. Reliable when the app writes a predictable key, useless when it doesn’t.
• Custom script — runs a PowerShell script as SYSTEM; exit code 0 plus any STDOUT output means “detected.” Most flexible option, and the one worth reaching for whenever the other three can’t reliably tell the app apart from a partial or broken install.

Requirement Rules

Requirement rules are frequently confused with detection rules, but they answer a different question. Detection asks “is this already installed?” Requirements ask “should this device even attempt the install at all?” — checked against things like OS version, architecture, minimum free disk space, minimum RAM, a specific registry value, or another custom script. A device that fails a requirement rule is reported as “not applicable,” not “failed,” which is the cleanest way to keep an app assigned broadly (e.g. to a whole department) without it erroring out on machines it was never meant to touch.

Assignment: Required, Available, and Uninstall

Once packaged, an app is assigned to Entra ID groups with one of three intents. Required installs automatically, no user action needed. Available for enrolled devices lists the app in Company Portal so users can install it themselves on demand — useful for optional tools without pushing them to everyone. Uninstall does the reverse: removes the app from any device in the assigned group, using the same uninstall command defined during packaging. Multiple assignment groups with different intents can target the same app simultaneously, which is how most orgs handle “required for Finance, available to everyone else.”

Dependencies and Supersedence

Dependencies let one Win32 app require another to be installed first — a runtime library, for example — and Intune will install the dependency automatically before attempting the main app. Supersedence is different: it links an old app to a newer version so that installing the new one automatically retires the old, optionally uninstalling it first. Both are useful, but chain them carefully — long dependency or supersedence chains are harder to troubleshoot when something in the middle breaks, and circular dependencies will simply fail to resolve.

Troubleshooting Failed Installs

The Intune console shows a pass/fail status and an error code, but the useful detail is on the device: C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log records the actual install command that ran, its exit code, and the detection check that followed. The single most common root cause isn’t a broken installer — it’s a mismatch between what the install command actually does and what the detection rule is looking for (wrong file path, wrong registry hive, or an MSI that installs per-user when the detection rule checks the per-machine product code). When a deployment reports failing at scale but works fine in a manual test, that mismatch is the first thing worth checking, before assuming the installer itself is at fault.

Win32 apps are one piece of a wider Intune deployment strategy — for the bigger picture on licensing, enrollment and co-management, start with the Microsoft Intune complete guide. If you’re migrating application delivery over from ConfigMgr specifically, the SCCM to Intune co-management guide covers running both side-by-side during the transition, and if provisioning is next on your list, see how Windows Autopilot compares to Autopilot device preparation for getting devices enrolled in the first place.