Intune supports multiple application packaging models and the choice between them is consequential. Not because one is universally better, but because each model makes different assumptions about installer behavior, detection capability, and deployment reliability – and choosing wrong produces failures that are hard to diagnose after the fact.
The mistake isn’t choosing the wrong model. The mistake is choosing without intent – defaulting to whatever is easiest to upload without considering whether it’s appropriate for what you’re deploying.
Win32 applications are the most capable and most commonly used packaging model for complex deployments. You wrap an existing installer – MSI, EXE, or script – using the Microsoft Win32 Content Prep Tool, which produces an .intunewin file. That package is uploaded to Intune with detection rules, requirement rules, and dependency configuration. Win32 apps run in the system context by default, support custom detection logic, support dependencies on other applications, and handle complex installation scenarios that simpler models can’t accommodate.
Win32 is appropriate for most traditional enterprise applications – anything that requires a complex installer, custom detection, pre/post-install scripts, or precise control over installation behavior. It’s also the model that surfaces installer quality problems most clearly, because Intune’s evaluation loop runs the detection logic repeatedly and expects consistent, reliable results.
Line-of-business apps are the simplest model. You upload an MSI or APPX directly and assign it. No wrapping, no prep tool, no custom detection required – Intune uses the product code from the MSI for detection automatically. LOB works well for clean, straightforward MSI packages that install reliably without custom logic. It breaks down when you need transforms, custom detection, reliable uninstall behavior, or dependency management. For simple applications with well-behaved MSI installers, LOB is the right choice. For anything more complex, Win32 is more appropriate even if the additional setup feels like overhead.
LOB apps look like the easy option and are – until you need to do something the model doesn’t support. Win32 requires more setup but ages better as requirements evolve.
Microsoft Store apps – deployed through the new Microsoft Store integration – are the right model for applications that are available in the Store and maintained by the publisher. Microsoft 365 Apps, Teams, and many modern applications are available this way. The Store handles the installation, update, and detection automatically. The tradeoff is that you give up control over update timing and version pinning – the application updates on the publisher’s schedule, not yours. For most productivity applications this is acceptable. For applications where version consistency is a requirement, it’s a constraint worth understanding before you commit to Store deployment.
Winget-sourced applications through the Windows Package Manager represent a modern alternative for a wide catalog of software. Intune can deploy applications using Winget as the installation mechanism, either through the Store integration for Winget-capable apps or through Win32 wrapper scripts that call Winget directly. The catalog is extensive – over ten thousand packages – but package quality and reliability varies. Winget deployment is powerful for well-maintained packages and frustrating for packages with inconsistent installer behavior or unreliable detection.
MSIX is worth understanding even if you don’t deploy it frequently. MSIX is Microsoft’s modern packaging format – containerized, clean installation and uninstall, no registry sprawl, designed for the modern app delivery model. Applications packaged as MSIX install predictably, update cleanly, and uninstall completely. The practical limitation is that not all applications can be packaged as MSIX – applications with complex system-level dependencies, kernel drivers, or deep OS integration often can’t be containerized. For applications that can be MSIX-packaged, it’s the cleanest deployment model available.
The decision framework is straightforward in practice. Does the application have a Store listing and is update timing flexibility acceptable? Use the Store. Is it a simple, clean MSI? Use LOB. Does it require custom detection, scripts, dependencies, or complex installation logic? Use Win32. Is it available as a well-maintained Winget package? Evaluate Win32 with Winget as the install mechanism. Is MSIX packaging available and the application compatible? Prefer MSIX for the cleaner lifecycle management.
The packaging model determines what’s possible. Detection logic – covered in the next article – determines whether what’s possible actually works reliably in production.
Intune Deployment Guide · Phase 7: Applications
‹ Previous: [7.1.4] EAM Auto-Update: Trading Control for a Managed Patch Service
Next: [7.3] Detection Logic: The Part Everyone Gets Wrong ›
