Application Packaging: Win32, MSIX, and the Art of Choosing
Your packaging format isn't a technical detail — it's a strategic decision that shapes your security posture, operational overhead, and ability to move fast.
In Part 2, we talked about managing your endpoint configuration as code — treating Intune policies like source code, with version control, pull requests, and pipelines. But configuration is only half the story. The other half is what you're actually deploying to those endpoints: applications.
And this is where things get messy.
Most organisations I encounter are still packaging everything as Win32. Not because they've evaluated the alternatives and made a deliberate choice, but because it's what they've always done. The tooling is familiar, the processes are established, and nobody's made a compelling case for change.
This post is that case.
The Three Formats
Before we get into strategy, let's be clear about what we're comparing. Windows gives you three primary ways to deliver applications through Intune:
Win32
MSIX
Store
Win32
MSIX
Store
WIN32 = FLEXIBILITY · MSIX = CONTROL · STORE = SIMPLICITY
Win32 is the legacy format — .exe and .msi installers wrapped in .intunewin containers. It's flexible, widely supported, and capable of handling complex installation logic. It's also the source of most of your application management headaches.
MSIX is Microsoft's modern packaging format. Applications run in a lightweight container, isolated from the system and from each other. They install cleanly, uninstall completely, and support native versioning and rollback. Think of it as what Win32 should have been, designed for a world where manageability matters as much as compatibility.
Microsoft Store is the simplest delivery mechanism. You point Intune at a Store app, assign it, and Microsoft handles the packaging, signing, and updates. Zero packaging overhead. The trade-off is zero control — you can't pin versions, stage rollouts, or roll back.
Each has its place. The problem is when you use one format for everything because you haven't thought about which one you actually need.
Why Win32 is Costing You More Than You Think
Win32 packaging is comfortable. It's familiar. And it's quietly creating problems that compound over time.
No isolation. Win32 apps install directly into the system — Program Files, registry, system PATH. When two applications disagree about which version of the Visual C++ Redistributable they need, you get conflicts that are painful to diagnose and expensive to resolve. I've seen estates with six different versions of the same runtime installed side by side, each required by a different application, each representing an independent patching obligation.
No clean uninstall. Uninstalling a Win32 app is an optimistic exercise. Uninstallers routinely leave behind registry keys, files, folders, and environment variables. Over time, endpoints accumulate cruft that degrades performance and complicates troubleshooting. Reimaging becomes the only reliable way to get a clean state — which tells you everything about the format's limitations.
Manual everything. Packaging a Win32 app means writing custom detection rules, install commands, uninstall commands, and dependency logic. Every application is a bespoke effort. Multiply that by a hundred applications and you've built yourself a full-time job that consists entirely of wrapping installers and hoping the detection rules don't silently break.
Security opacity. Win32 apps can modify system files, write to any registry location, and execute arbitrary code during installation. Code signing is optional. If you're working toward Windows Defender Application Control (WDAC), every unsigned Win32 app is an exception you need to manage — and exceptions are where security postures go to die.
Accreditation friction. If you're pursuing certifications like Cyber Essentials, it gets worse. Cyber Essentials requires one of three malware protection approaches: antivirus, application allow-listing, or application sandboxing. Most organisations default to antivirus alone — but if you want to mature beyond that, you need either signed applications (for allow-listing) or isolated execution (for sandboxing). Win32 gives you neither without significant additional effort. MSIX, by contrast, gives you both almost for free through mandatory code signing and containerised execution. Sticking with Win32 doesn't just create operational overhead — it actively limits your options for meeting security accreditations.
None of this means Win32 is bad. It means it should be the exception, not the default. Some applications genuinely require it — legacy software with custom install logic, apps that need kernel drivers, vendor packages that simply don't work any other way. But the number of apps that truly need Win32 is usually much smaller than the number currently packaged that way.
MSIX: The Default You Should Be Using
MSIX addresses almost every limitation of Win32, and it does so by design rather than convention.
Containerised execution. MSIX apps run in an isolated container. They get their own virtualised view of the file system and registry. This means two apps can depend on different versions of the same component without conflict — a problem that has caused more weekend incidents than I care to count.
Built-in versioning and rollback. Every MSIX package has a version number baked into its identity. Upgrading is atomic — the new version installs alongside the old one, switches over, and the old version is cleanly removed. If the new version has issues, rolling back is a supported operation, not a prayer and a reinstall.
Mandatory code signing. Every MSIX package must be digitally signed. This isn't just good practice — it's enforced by the platform. If you're implementing WDAC, MSIX apps integrate naturally with your allow-listing policies because they're already signed. No exceptions to manage, no unsigned binaries to track.
Clean lifecycle. Install, update, uninstall — all handled cleanly. No orphaned files, no registry ghosts, no "we should probably reimage this machine" conversations.
AVD compatibility. If you're running Azure Virtual Desktop, MSIX app attach lets you deliver applications dynamically to session hosts without baking them into the golden image. This dramatically simplifies image management and means patching an application no longer requires rebuilding and redeploying your entire VDI stack.
The common objection is: "Our team doesn't know how to create MSIX packages." That's fair, and it's worth taking seriously. MSIX packaging is different from Win32 packaging, and the learning curve is real. But this is an argument for upskilling or engaging a packaging partner, not for staying on a format that creates more work than it saves.
Microsoft Store: Simplicity With Guardrails
The Microsoft Store is the right answer for a specific category of applications: low-risk, frequently updated tools where you don't need to control the exact version.
Think of apps like Microsoft Whiteboard, Power BI Desktop, or Company Portal. They update frequently. They're not business-critical in the sense that a specific version matters. Users benefit from always having the latest version, and the overhead of manually packaging and deploying updates adds no value.
For these apps, the Store is a gift. Point Intune at them, assign them, and move on. Your packaging team can focus their effort on applications that actually need it.
But the Store has hard limits:
- No version pinning. You can't control which version users get. If the vendor pushes a broken update, everyone gets it simultaneously.
- No deployment rings. There's no way to stage a rollout. It's all-or-nothing.
- No rollback. If an update causes problems, you wait for the vendor to fix it.
These limits are fine for low-risk apps. They're unacceptable for anything business-critical, anything with compliance requirements, or anything where a bad update could disrupt operations. The moment a Store app crosses that threshold, it needs to be repackaged as MSIX and brought under proper lifecycle management.
Making the Decision: A Framework
Rather than deciding format-by-format on a case-by-case basis (which is how you end up with inconsistent practices), establish a decision framework that your team can apply consistently.
Needs custom install logic or drivers?
→ Win32 (governed exception)
Low-risk, evergreen, no version pinning?
→ Microsoft Store
Everything else
→ MSIX (the default)
The logic is straightforward:
-
Does the app require custom installation logic, kernel drivers, or system-level modifications that MSIX can't accommodate? → Win32, with a documented exception and a plan to revisit.
-
Is it a low-risk, evergreen utility where version control doesn't matter? → Microsoft Store.
-
Everything else → MSIX.
The critical point is that MSIX should be the default. Win32 is an exception that needs justification. The Store is a convenience for a specific category. If you don't establish this hierarchy, inertia will keep everything in Win32 because that's the path of least resistance.
Deployment Rings: Don't Ship to Everyone at Once
Regardless of format, how you deploy matters as much as how you package. Pushing an application update to your entire estate simultaneously is the operational equivalent of testing in production — except the production is every endpoint your business runs on.
A ring-based deployment model is straightforward in concept:
- Test ring (~2%): IT staff and early adopters. They see updates first, absorb the initial impact, and report issues before anyone else is affected.
- Pilot ring (~10%): A broader group of business users who validate the update in real-world conditions. Their feedback determines whether the update is ready for general deployment.
- Broad ring (~88%): Everyone else. By the time an update reaches this ring, it's been validated by two groups and any issues have been resolved.
For estate-wide apps (Group 1 — things like browsers, runtimes, productivity tools), a single ring structure works well. Everyone gets the same app; the rings just control when.
For role-specific apps (Group 2 — department or function-specific tools), the picture is more nuanced. A finance application needs to be tested by finance users, not by IT staff who'll never exercise the workflows that matter. Per-application deployment rings, where ring membership is tied to the app's actual user base, ensure that validation is meaningful.
The tooling to support this already exists in Intune. Dynamic groups, assignment filters, and Endpoint Analytics provide the mechanics. What's usually missing isn't capability — it's discipline. Someone needs to define the rings, assign membership, and actually wait for validation before progressing. That "someone" is process, and process doesn't implement itself.
The Application Catalogue: Knowing What You Have
You can't manage what you can't see. And in most organisations, "what applications do we have deployed?" is a question that takes weeks to answer definitively — if it can be answered at all.
An Application Catalogue is exactly what it sounds like: a centralised, authoritative record of every application in your estate. For each application, you track:
| Field | Purpose |
|---|---|
| Application name | What it is |
| Current version | What's deployed |
| Packaging format | Win32, MSIX, or Store |
| Owner | Who's responsible for it |
| Deployment method | How it's delivered |
| Ring assignments | Who gets it, and when |
| Dependencies | What it needs to run |
| Lifecycle status | Active, deprecated, or retired |
This isn't glamorous work. It's a spreadsheet, or a SharePoint list, or a Power App — the platform doesn't matter. What matters is that it exists, it's maintained, and it's the single source of truth.
The catalogue enables everything else in this strategy. You can't plan a Win32-to-MSIX migration if you don't know which apps are Win32. You can't implement deployment rings if you don't know who uses each app. You can't patch effectively if you don't know which apps depend on which runtimes. You can't retire applications if nobody knows who owns them.
Start with what you have. Export your Intune app inventory, enrich it with ownership and dependency information, and you've got a working catalogue. It won't be perfect — it will never be perfect — but an imperfect catalogue is infinitely more useful than no catalogue at all.
Bringing It Together: The Application Lifecycle
Configuration management (Part 2) and application packaging aren't separate disciplines — they're two sides of the same lifecycle. Configuration as Code governs how endpoints are configured. Application lifecycle management governs what's installed on them. Together, they give you a complete, auditable picture of your endpoint estate.
The lifecycle is:
- Intake: A new application is requested. The decision framework determines the packaging format. It's added to the catalogue.
- Package: The app is packaged (MSIX, Win32, or assigned from the Store), signed, and validated.
- Test: Deployed to the test ring. IT staff validate installation, detection rules, and basic functionality.
- Pilot: Deployed to the pilot ring. Business users validate real-world workflows and report issues.
- Deploy: Rolled out to the broad ring. Telemetry confirms successful deployment.
- Maintain: Ongoing patching, version updates, and periodic review. Eventually, retirement.
Every application follows this path. No exceptions without governance — and "governance" means a documented decision, not a verbal agreement that nobody remembers in six months.
Getting Started
If you've read this far and you're feeling the weight of everything that needs to change, take a breath. You don't need to do all of this at once. Here's a pragmatic starting point:
-
Build your catalogue. Export your Intune app list. Add columns for format, owner, and lifecycle status. This is an afternoon's work and it immediately gives you visibility you didn't have.
-
Pick your next new app and package it as MSIX. Don't try to convert your entire Win32 estate. Just make MSIX the default for the next thing, and learn by doing.
-
Implement deployment rings for one app. Choose something visible — a browser update, or a productivity tool. Set up test and pilot groups. See how it feels.
-
Move your Store-eligible apps to the Store. Identify the low-risk utilities that don't need version control and shift them to Store delivery. Every app you move to the Store is one fewer app to package manually.
-
Document the decision framework. Write down the logic for choosing between Win32, MSIX, and Store. Make it a one-pager that anyone on the team can follow.
Each of these steps delivers standalone value. Together, they build the foundation for a mature application lifecycle practice.
This is Part 3 in a series on endpoint standardisation. Part 1: The Case for Standardisation covers the broader principles. Part 2: Configuration as Code tackles endpoint configuration management. Next, we'll look at how AI is about to change the way we think about all of this.