What is a Win32 app in Intune?

What is a Win32 app in Intune?

A Win32 app is a packaged Windows desktop application that Intune installs, updates, and removes through a device-side agent rather than through the operating system’s built-in MDM stack. The name comes from the Win32 API that classic desktop software is built against, but in Intune terms it simply means “any installer you wrap and manage yourself” – typically MSI or EXE setups, but also wrapper scripts, ZIP-based deployments, or batch and PowerShell installers.

What separates a Win32 app from a simple file upload is that it carries logic, not just bytes. A single Win32 app definition bundles the installer content with an install command, an uninstall command, the device eligibility rules (requirements), the logic that decides whether the app is already present (detection), the codes that define success or failure, and the assignment that decides who receives it. Because all of that lives in one app object, Intune can install on the right devices, report accurate status, and uninstall cleanly later.

Why are Win32 apps packaged as .intunewin files?

You cannot upload a raw installer to Intune as a Win32 app. The source files must first be wrapped into a single encrypted .intunewin file using the Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe). The tool is open source, takes a source folder plus the primary setup file, and produces one compressed, encrypted package that Intune stores and delivers to devices. Encryption matters because the content is decrypted only on the target device by the management agent, not exposed in transit.

The basic packaging command takes a source folder, the setup file inside it, and an output folder:

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

The current maximum size for a single .intunewin file is 8 GB, which is generous enough for most desktop suites but worth remembering for very large installers. For a step-by-step walkthrough of staging source files and running the wrapper, see how to prepare .intunewin packages.

How the Intune Management Extension processes Win32 apps

Win32 apps are not handled by the standard Windows MDM channel. They are processed by the Intune Management Extension (IME), a service called “Microsoft Intune Management Extension” that is installed automatically the first time a device is targeted with a Win32 app or a PowerShell script. The IME downloads the encrypted package, decrypts it locally, evaluates requirements, runs detection, executes the install command, and reports the result back to Intune.

Timing is a common source of confusion. The IME checks for new Win32 app and PowerShell-script policy roughly every hour, and also after a device restart or whenever the service restarts. That is separate from the general Windows MDM device check-in, which runs on a variable schedule (often around every 8 hours, more frequently right after enrollment). If you do not want to wait, a manual sync from Settings > Accounts > Access work or school > Info > Sync or from the Company Portal forces a check-in. When something goes wrong, the IME writes detailed logs to C:\ProgramData\Microsoft\IntuneManagementExtension\Logs (notably IntuneManagementExtension.log and AppWorkload.log), which you can open with CMTrace. The IME log guide covers how to read them.

Install and uninstall commands, and run context

Every Win32 app needs an install command and an uninstall command that run silently, with no user interaction. For MSI packages this is usually an msiexec line with quiet and no-restart switches; for EXE installers it depends on the vendor’s supported silent switches. The matching uninstall command lets Intune remove the app cleanly when you change an assignment to Uninstall. Getting these strings right is the difference between a clean rollout and a stuck deployment, which is why install and uninstall commands have a guide of their own.

You also choose an install behavior, or run context, on the Program tab:

• System context runs the install as the local SYSTEM account. It is device-wide and the common default, ideal for software every user on the machine should have.
• User context runs in the context of the signed-in user. The user must be signed in, and it suits per-user installers that write to a single profile.

Requirements vs detection rules: what is the difference?

These two stages are easy to confuse, but they answer different questions and run in a specific order. Requirement rules are evaluated first – before detection and before the install command ever runs – and decide whether a device is even eligible. They cover OS architecture (x86, x64, ARM64) and minimum operating system version, plus optional checks for disk space, physical memory, logical processors, CPU speed, and custom file, registry, or script conditions.

Detection rules answer a different question: “is this app already installed on this device?” Intune supports four detection types – MSI (matched by product code), File, Registry, and a custom PowerShell script. A detection script is treated as “detected” only when it exits with code 0 and writes output to STDOUT; exit 0 with no output still counts as not detected. Detection is what prevents needless reinstalls and what reports an app as installed in the console. Read more in Intune requirements and Intune detection rules explained.

What do Win32 return codes and restart behavior mean?

When the install command finishes, the IME interprets the process exit code against a set of return codes to decide the outcome. The defaults cover the most common cases, and you can map additional custom codes if a vendor installer uses non-standard values.

Separately, the Program tab offers a restart behavior setting: No specific action, App install may force a device restart, Determine behavior based on return codes, or Intune will force a mandatory device restart. For most apps “Determine behavior based on return codes” is the safest choice because it lets codes like 3010 and 1641 drive whether a reboot happens.

How are Win32 apps assigned to users and devices?

An app is only delivered once you assign it. Win32 apps support three assignment intents. Required installs the app automatically on targeted users or devices. Available for enrolled devices publishes the app in Company Portal so a signed-in user can install it on demand – because it needs a user, it is not supported for device-only targeting. Uninstall removes the app from members of the target group. Required apps install in the background and may show a toast notification, while Available apps surface in the Company Portal app and website with live install status. For the trade-offs, see Required vs Available app assignments.

Common mistakes to avoid with Win32 apps

Most Win32 problems trace back to a handful of recurring errors:

• Detection that never matches the install. If the detection rule points at a path, registry key, or product code the installer does not actually create, Intune will reinstall on every cycle or report failure forever.
• Non-silent install commands. A command that triggers a UI prompt hangs in System context where no user can click it.
• Wrong run context. Per-user installers placed in System context, or device-wide installers in User context, lead to inconsistent results.
• Requirements set too tightly. An over-specific OS or architecture requirement quietly makes devices “not applicable” so the app never installs.
• Expecting instant results. Remember the IME cycles roughly hourly; force a sync rather than assuming a deployment failed.