How Intune deploys Windows applications

What are the stages of an Intune Windows app deployment?

Every Windows app deployment moves through four logical stages. The first two happen in the Intune service (the admin center and Microsoft’s back end); the last two happen on the managed device itself. Keeping this division clear is the fastest way to reason about where a deployment is stuck.

Note the direction of travel: Intune never “pushes” an install in real time. The device asks Intune for new policy on a schedule, then the on-device agent carries out the work. That pull model is why a manual sync exists and why deployments are never instant.

What happens when you upload a Win32 app to Intune?

Win32 apps are not uploaded as raw installers. You first wrap the installer and its supporting files into a single encrypted .intunewin package using the Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe). The tool is open source and takes a source folder, a setup file, and an output folder:

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

When you add that file to Intune, you are not just uploading bytes. You attach the deployment metadata that the device will later act on: the install and uninstall command lines, the install behavior (System or User context), requirement rules, detection rules, return-code mappings, and restart behavior. The package itself is capped at 8 GB for a single Win32 app. All of this configuration lives in the Intune service and travels to the device as policy, separate from the encrypted content blob that the client downloads at install time.

How do assignments decide who gets the app?

An uploaded app does nothing until you assign it. An assignment binds the app to an Azure AD group of users or devices and declares an intent. There are three intents, and choosing correctly is the most common place admins go wrong.

• Required — the app installs automatically on every targeted user or device with no user action. This is what most managed software uses.
• Available for enrolled devices — the app appears in Company Portal for the user to install on demand. Because it surfaces to a person, it must target a user group; it is not supported for device-only targeting.
• Uninstall — Intune removes the app from targeted users or devices.

The difference between the first two is worth its own discussion; see Required vs Available app assignments for the trade-offs. A sound rollout starts with a small Required or Available pilot group, confirms the install succeeds and reports correctly, then widens the assignment to production groups.

What does the Intune Management Extension do on the device?

On Windows, Win32 apps and PowerShell scripts are not handled by the built-in MDM stack. They are processed by the Intune Management Extension (IME), which runs as the “Microsoft Intune Management Extension” service. IME is installed automatically the first time a device is targeted with a Win32 app or a PowerShell script, so you do not deploy it yourself.

When new app policy arrives, IME downloads the encrypted content, decrypts it, evaluates the rules in order, runs the install command in the configured context, interprets the return code, and reports status back to Intune. Everything it does is logged. When troubleshooting, read these files with CMTrace:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

The key files are IntuneManagementExtension.log (overall agent activity), AppWorkload.log (per-app install detail), AgentExecutor.log (PowerShell execution), and ClientHealth.log. AppWorkload.log is usually where you start when a specific app fails.

How often do devices check in for new app policy?

Two separate clocks matter here, and conflating them causes a lot of confusion about why an app “isn’t installing yet”. The general MDM device check-in for Windows runs on a variable schedule, commonly around every 8 hours and more frequently right after enrollment. IME, however, has its own cycle for Win32 apps and PowerShell scripts: it checks for new policy roughly every hour, and also after a device restart or when the service restarts.

When you are testing a deployment you should not wait for the timer. Force a check-in from Settings > Accounts > Access work or school > Info > Sync, or from Company Portal. For more on timing and how to speed up test loops, see how Intune device sync works.

In what order does IME evaluate requirements, detection, and install?

The on-device processing is not arbitrary; it follows a fixed sequence, and each gate can stop the deployment before the next one runs.

1. Requirement rules are evaluated first. These include OS architecture (x86/x64/ARM64) and minimum operating system, plus optional checks for disk space, physical memory, logical processors, CPU speed, and custom file, registry, or script requirements. If a device does not meet requirements, the app is reported “Not applicable” and nothing else runs.
2. Detection rules run next to decide whether the app is already present. Detection can use MSI product code, a file, a registry value, or a custom PowerShell script. A detection script reports “detected” when it exits 0 and writes output to STDOUT. If the app is already detected, IME skips the install.
3. The install command runs only if requirements pass and the app is not yet detected. It executes in System context (the local SYSTEM account, device-wide, the common default) or User context (the signed-in user, who must be present). After install, detection runs again to confirm success.

Because detection is what ultimately determines “Installed”, a wrong detection rule is the classic reason an app installs but reports as failed, or reinstalls on every cycle. See Intune detection rules for how to build reliable ones, and System vs User context for choosing the right install account.

How does Intune interpret install results?

When the install command finishes, IME reads its exit code and maps it to an outcome. Intune ships with default mappings, and you can add custom return codes on the Program tab. The defaults are:

Any code not listed defaults to Failed unless you map it. Restart behavior is controlled separately on the Program tab, with options of “No specific action”, “App install may force a device restart”, “Determine behavior based on return codes”, and “Intune will force a mandatory device restart”. For the full picture of how exit codes and reboots interact, see return codes and install behavior.

What does the user see during deployment?

For Required apps, installation happens in the background and may surface a brief toast notification; the user generally does nothing. For Available apps, the user opens Company Portal, finds the app, clicks install, and watches the status update there. Company Portal is also where users and admins confirm install state, which makes it a useful sanity check that policy actually reached the device and the install reported back.