5.1 App Deployment Decision Matrix and Packaging

Deployment starts with the app type

Intune can deploy many app types, but MD-102 expects you to recognize when a scenario needs full Windows desktop app management. A classic installer packaged as .intunewin belongs to the Windows app (Win32) app type. That is the app type that gives you install and uninstall commands, return codes, requirement rules, detection rules, dependencies, supersedence, and installation context (system or user). It is delivered by the Intune Management Extension (IME), which is an important detail for Autopilot scenarios below.

Use the Microsoft Win32 Content Prep Tool to create the .intunewin package before upload. The package should include the installer and supporting files, and the installer itself must be able to run silently. Intune does not support interactive application installs that wait for a user prompt during deployment, so an installer that pops a wizard with no silent switch is not deployable as-is.

Requirement rules versus detection rules

These two are the most-tested packaging concepts. Requirement rules are checked before installation and answer: is this device eligible for the app? Examples include minimum operating system version, architecture (x86/x64/ARM64), free disk space, physical memory, registry checks, file checks, or custom script logic. If a device fails a requirement rule, Intune reports it as not applicable rather than failed.

Detection rules are checked to decide whether the app is already installed and answer: is the desired app state present? Detection can use the MSI product code, a file (version/date), a registry value, or custom script logic. Poor detection rules are a leading cause of unreliable reporting, repeated install attempts, or apps that never remediate because Intune already believes the app is present. On the exam, a stem describing an app that "keeps reinstalling" or "never shows as installed" usually points to a detection-rule mistake.

Dependencies and supersedence

Use dependencies when one Win32 app must be installed before another can succeed, such as installing a runtime or certificate utility before a VPN client. A dependency must also be a Win32 app; a line-of-business MSI app type or a Store app cannot be used directly as a Win32 dependency. You can also choose whether a dependency is auto-installed.

Use supersedence when a newer Win32 app should update or replace an older Win32 app. If the newer installer upgrades the old version in place, you may configure supersedence without an uninstall of the previous version. If the new app is a product replacement, configure the supersedence relationship to uninstall the previous app before installing the new one. Supersedence has depth limits and should be planned so chains do not become unmanageable.

Autopilot app installation tradeoffs

Autopilot app strategy is an exam favorite because the best answer is rarely "deploy everything immediately." The Enrollment Status Page (ESP) can block users from reaching the desktop until required apps and policies finish, but every blocking app adds time and failure surface. Use blocking only for security agents, network/ZTNA clients, remote-support prerequisites, and essential productivity apps that must exist before first use.

Avoid mixing fragile install technologies during Autopilot. The standard Microsoft 365 Apps app type is installed by the Office Click-to-Run mechanism, not by the Intune Management Extension, and it cannot be reliably tracked as a blocking app on the ESP. When Office must be tracked during ESP, Microsoft recommends packaging it as a Win32 app so the IME installs and reports it. If Office installs concurrently with tracked Win32 apps, ESP can fail due to installation concurrency.

A practical Autopilot approach is:

1. Block on a small baseline: management agent, security agent, VPN or ZTNA client, and required certificates or runtimes.
2. Use dependencies for prerequisites instead of making every helper app a separate required deployment.
3. Let large, nonessential apps install after the user reaches the desktop.
4. Keep Office aligned with the design: the Microsoft 365 Apps type for ordinary post-enrollment deployment, but a Win32 Office package when Office is a tracked ESP app.
5. Use device filters and pilot groups before broad rollout so a bad detection rule or command-line typo does not stall new-device provisioning.

Install behavior, return codes, and context

Two Win32 settings beyond the basics show up in scenarios. Install behavior chooses system context (installs as SYSTEM, the right choice for machine-wide apps and device-targeted assignments) or user context (installs in the signed-in user's profile, used for per-user apps assigned to users). Choosing user context for a machine-wide MSI, or system context for a per-user app that writes to the user profile, leads to failed installs and confusing detection results.

Return codes tell Intune how to interpret the installer's exit code: Success, Soft reboot, Hard reboot, Retry, or Failed. Mapping 3010 to Hard reboot, for example, lets Intune coordinate a required restart instead of treating the install as failed. A scenario where an app installs but Intune reports failure often comes down to an unmapped return code.

Assignment targeting and filters

App assignments target users or devices through groups, and assignment filters refine those groups by device properties such as OS version, ownership, manufacturer, model, or Enrollment Status. A filter can include or exclude devices without creating a new group, which is the cleaner way to scope a Required app to, say, only x64 Windows 11 corporate devices. On the exam, when a requirement needs precise device-attribute targeting on top of an existing broad group, the answer is usually an assignment filter, not a new dynamic group.

Combining the right app type, assignment intent, requirement and detection rules, context, return codes, and filters is what makes a deployment both reliable and well-scoped.