Application Packaging: Win32 vs MSIX vs Store

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 deploy to those endpoints: applications.

And this is where things get messy.

Most organisations I encounter still package 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 ways to deliver applications through Intune:

Win32

IsolationNone

RollbackManual

VersioningExternal

SigningOptional

Clean uninstallUnreliable

MSIX

IsolationContainerised

RollbackBuilt-in

VersioningNative

SigningRequired

Clean uninstallGuaranteed

Store

IsolationContainerised

RollbackNone

VersioningAutomatic

SigningMicrosoft

Clean uninstallGuaranteed

Win32

IsolationNone

RollbackManual

VersioningExternal

SigningOptional

Clean uninstallUnreliable

MSIX

IsolationContainerised

RollbackBuilt-in

VersioningNative

SigningRequired

Clean uninstallGuaranteed

Store

IsolationContainerised

RollbackNone

VersioningAutomatic

SigningMicrosoft

Clean uninstallGuaranteed

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, isolated container, separate 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, built 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 to your groups, and Microsoft handles the packaging, signing and updates. The trade-off is version control: you can't pin a version or roll one back once Microsoft ships it, though you can still target who gets it by assigning to specific groups.

Each format fits a different situation. The problem starts when you use one format for everything without deciding which one you actually need.

---

Why Win32 is costing you more than you think

Win32 packaging is comfortable and familiar, and it's quietly creating problems that compound over time.

Win32 apps install directly into the system: Program Files, the registry, the system PATH, with no isolation between them. 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 running six different versions of the same runtime side by side, each required by a different application and each its own patching obligation.

Uninstalling a Win32 app is an optimistic exercise, and rarely a clean one. Uninstallers routinely leave behind registry keys, files, folders and environment variables. Over time, endpoints accumulate cruft that degrades performance and complicates troubleshooting, until reimaging becomes the only reliable way back to a clean state.

Packaging a Win32 app means writing custom detection rules, install commands, uninstall commands and dependency logic by hand for every application. Multiply that by a hundred applications and you've built yourself a full-time job wrapping installers and hoping the detection rules don't silently break.

Win32 apps can modify system files, write to any registry location and execute arbitrary code during installation, and code signing is optional. If you're working toward App Control for Business, every unsigned Win32 app is an exception you need to manage, and exceptions are where security postures go to die.

If you're pursuing certifications like Cyber Essentials, it gets worse. Cyber Essentials version 3.2 accepts one of two malware protection routes: anti-malware software, or application allow listing restricted by code signing. Most organisations default to anti-malware alone, and if you want the allow-listing route instead, you need signed applications. Win32 doesn't give you that without significant extra effort, because code signing is optional. MSIX gives you the signing for free, because every package must be signed. You still have to approve each application before you deploy it and keep the approved list current, as the allow-listing route requires, but you no longer have to sign anything yourself. Staying on Win32 adds operational overhead, and it limits your options for meeting security accreditations.

Win32 isn't bad; it should be the exception, not the default. Some applications genuinely need it: legacy software with custom install logic, apps that need kernel drivers, and vendor packages that 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 use

MSIX addresses almost every limitation of Win32. The difference is deliberate, built into the format rather than left to convention.

MSIX apps run in an isolated container, each with its own virtualised view of the file system and registry. 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.

Every MSIX package has a version number baked into its identity, and 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.

MSIX packages must also be digitally signed, and the platform enforces that; it isn't optional the way it is for Win32. If you're implementing App Control for Business, MSIX apps integrate naturally with your allow-listing policies because they're already signed. There are no exceptions to manage and no unsigned binaries to track.

Install, update and uninstall are all handled cleanly, with no orphaned files, no registry ghosts, and no "we should probably reimage this machine" conversations.

If you're running Azure Virtual Desktop, App Attach lets you deliver MSIX, Appx and App-V packages dynamically to session hosts without baking them into the golden image. That simplifies image management, and it 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 a fair concern. MSIX packaging is different from Win32 packaging, and it takes time to learn. 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.

When MSIX won't work: COM, drivers and edge cases

MSIX isn't a universal solution. Certain application architectures and system requirements fall outside its design boundaries.

COM interoperability is the most common limitation, though not in the way people expect. Both out-of-process and in-process COM servers work fine as long as they stay inside the package: processes and extensions packaged together can register and use COM freely. What fails is an in-process extension, such as a shell extension, that a process outside the package tries to load. MSIX's containerised registry doesn't expose those registrations system-wide, so that kind of cross-package activation breaks.

Kernel drivers are unsupported. MSIX is designed for user-mode applications, so if yours includes a kernel driver, a hardware controller, a security agent or another low-level system utility that needs one, Win32 is your only option. Windows services are more nuanced: MSIX doesn't support a per-user service, but it does support a per-machine service that runs under LocalSystem, LocalService or NetworkService. If your application's service fits that pattern, MSIX still works.

Complex licensing models tied to machine identity can fail in MSIX containers. An application that writes licensing state to specific registry paths or system directories may not find those locations inside the container, which triggers a "licence not found" error.

MSIX supports a "runFullTrust" capability that disables isolation and allows system-level access, but enabling Full Trust defeats most of MSIX's benefits: clean uninstall, containerisation and security boundaries all go. If your application requires Full Trust, Win32 packaging is more honest about what you're actually deploying.

If your application needs kernel access, an in-process extension loaded outside its own package, or Full Trust capabilities, document it as a Win32 exception with justification and move on. Work within MSIX's limits rather than trying to force it. Save MSIX for the 80% of applications that genuinely benefit from it.

---

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, and 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 real limits:

• You can't pin a version. Apps stay on whatever Microsoft is currently shipping, so if the vendor pushes a broken update, everyone assigned the app gets it.
• There's no rollback once an update ships. If it causes problems, you wait for the vendor to fix it.

The first deployment is less blunt than it used to be. You can stage it by assigning the app to specific groups with a restart grace period and an installation deadline, the same mechanism you'd use for a Win32 or MSIX app. That controls who gets the app first, but it doesn't stop later vendor updates reaching everyone at once.

Intune's Store integration now also supports Win32 apps sourced from the Store catalogue, though that's still in preview and not every Win32 app is available through it. That blurs the line between a "Store app" and a "Win32 app" a little, but for now, treat it as an early option rather than a dependable path.

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, which is how you end up with inconsistent practices, establish a decision framework your team can apply consistently.

Needs custom install logic or drivers?

Result: Win32 (documented exception)

Low-risk, evergreen, no version pinning?

Result: Microsoft Store

Everything else

Result: MSIX (the default)

The logic is straightforward:

1. Does the app need custom installation logic, kernel drivers, or system-level modifications that MSIX can't accommodate? If so, use Win32, with a documented exception and a plan to revisit it.
2. Is it a low-risk, evergreen utility where version control doesn't matter? If so, use Microsoft Store.
3. Everything else goes to MSIX.

The key point is that MSIX should be the default. Win32 needs justification as an exception, and the Store is a convenience for one specific category of app. 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 it. 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 works like this:

The test ring, about 2% of the estate, is IT staff and early adopters. They see updates first, absorb the initial impact, and report issues before anyone else is affected.

The pilot ring, about 10%, is a broader group of business users who validate the update in real-world conditions. Their feedback decides whether the update is ready for general deployment.

The broad ring, the remaining 88%, is everyone else. By the time an update reaches this ring, two groups have already validated it and any issues are resolved.

For estate-wide apps (Group 1: things like browsers, runtimes and 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), a single ring doesn't work as well. A finance application needs finance users testing it, not IT staff who will never exercise the workflows that matter. Per-application deployment rings, where ring membership follows the app's actual user base, make that validation meaningful.

The tooling to support this already exists in Intune: dynamic groups, assignment filters and Endpoint Analytics provide the mechanics. What's usually missing is discipline, not capability. Someone needs to define the rings, assign membership, and actually wait for validation before moving to the next one. Without a named owner for that job, it doesn't happen.

---

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:

This isn't glamorous work. The catalogue can be a spreadsheet, 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. Patching depends on knowing which apps depend on which runtimes, and retiring an application depends on knowing who owns it.

Start with what you have. Export your Intune app inventory, enrich it with ownership and dependency information, and you have a working catalogue. An AI-assisted approach can speed this up considerably, though even a manual catalogue beats none at all.

---

Bringing it together: the application lifecycle

Configuration management, covered in Part 2, and application packaging are 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.

1

Intakerequest & assess

2

Packageformat & sign

3

Testring 1 validation

4

Pilotring 2 feedback

5

Deploybroad rollout

6

Maintainpatch & review

The lifecycle runs in six stages:

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

You don't need to do all of this at once. Here's a pragmatic starting point:

1. Build your catalogue: export your Intune app list, and add columns for format, owner and lifecycle status. This is an afternoon's work, and it gives you visibility you didn't have before.
2. 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.
3. Implement deployment rings for one app. Choose something visible, a browser update or a productivity tool, set up test and pilot groups, and see how it feels.
4. 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 is one fewer app to package by hand.
5. Document the decision framework. Write down the logic for choosing between Win32, MSIX and Store, and make it a one-pager anyone on the team can follow.

Each step delivers value on its own.

---

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. Part 4: AI and Endpoint Management explores how AI is changing all of this.