5.1 App Deployment Decision Matrix and Packaging
Key Takeaways
- Use Windows app (Win32) for .intunewin packages, silent installers, detection rules, requirements, dependencies, and supersedence.
- Required assignments push apps automatically, Available assignments publish self-service installs, and Uninstall assignments remove apps that Intune previously installed.
- Requirement rules decide whether an app is eligible to install; detection rules decide whether Intune considers it already installed.
- Win32 dependencies must be Win32 apps, and supersedence is the Intune relationship used to update or replace older Win32 apps.
- During Autopilot, keep blocking apps limited to apps that are truly needed before desktop access because every blocker increases provisioning risk and time.
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, requirements, detection rules, dependencies, supersedence, and installation context.
Use the Microsoft Win32 Content Prep Tool before upload. The package should include the installer and supporting files, but the installer still must be able to run silently. Intune does not support interactive application installs that wait for a user prompt during deployment.
| Scenario clue | Best Intune choice | Why |
|---|---|---|
Custom desktop app with setup.exe or MSI plus helper files | Windows app (Win32) | Supports .intunewin, commands, detection, requirements, dependencies, and supersedence |
| Simple store-sourced Windows app | Microsoft Store app (new) | Intune can browse, deploy, monitor, and keep supported Store apps updated |
| Standard Office suite deployment | Microsoft 365 Apps app type | Built for Word, Excel, PowerPoint, Teams, update channel, languages, architecture, and shared activation settings |
| Optional app users should install themselves | Available assignment | Shows the app in Company Portal instead of forcing installation |
| Mandatory app needed on all targeted devices | Required assignment | Intune installs automatically on applicable devices |
| Pilot app must be removed when testing ends | Uninstall assignment | Intune removes the app if the app was installed by that deployment |
Requirement rules versus detection rules
Requirement rules are checked before installation. They answer the question: is this device eligible for the app? Examples include operating system version, architecture, disk space, memory, registry checks, file checks, or custom script logic.
Detection rules are checked to decide whether the app is already installed. They answer the question: is the desired app state present? Detection can use MSI product code, file, registry, or custom script logic. Poor detection rules cause unreliable reporting, repeated installs, or devices that never remediate because Intune thinks the app is already installed.
Dependencies and supersedence
Use dependencies when one Win32 app must be installed before another app can succeed. For example, install a certificate utility or runtime before a VPN client. A dependency must also be a Win32 app; a single MSI line-of-business app or Store app cannot be used directly as a Win32 dependency.
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 might not need to uninstall the previous version. If the new app is a product replacement, configure the supersedence relationship to uninstall the prior app.
Autopilot app installation tradeoffs
Autopilot app strategy is an exam favorite because the right answer is not always deploy everything as soon as possible. The Enrollment Status Page (ESP) can block users until required apps and policies finish, but every blocking app adds time and failure surface. Use blocking only for security agents, network clients, remote support prerequisites, and essential productivity apps that must exist before first use.
Avoid mixing fragile install technologies during Autopilot. When Microsoft 365 Apps must be tracked during ESP, Microsoft recommends packaging it as a Win32 app because the normal Microsoft 365 Apps app type is not installed by the Intune Management Extension. If Office installs at the same time as tracked Win32 apps, ESP can fail from installation concurrency.
A practical Autopilot approach is:
- Block on a small baseline: management agent, security agent, VPN or ZTNA client, and required certificates or runtimes.
- Use dependencies for prerequisites instead of making every helper app visible as a separate required deployment.
- Let large, nonessential apps install after the user reaches the desktop.
- Keep Office deployment aligned with the Autopilot design: use the Microsoft 365 Apps app type for ordinary post-enrollment deployment, but consider a Win32 Office package when Office is a tracked ESP app.
- Use device filters and pilot groups before broad rollout so failed detection or command-line mistakes do not stall new-device provisioning.
A payroll application uses setup.exe, must install silently, and needs a prerequisite runtime installed first. Which Intune app design best matches the requirement?
A Win32 app should install only on Windows 11 64-bit devices with at least 8 GB of RAM. Which configuration should you use?
You are building an Autopilot ESP profile. Which app strategy is the most defensible?