MSI vs MSIX: a 2026 reality check for enterprise packaging

Every packaging team in the UK has had a version of this conversation. Someone senior reads that MSIX is "the modern Windows app packaging format", asks why the factory is still turning out MSIs wrapped in PSADT, and the honest answer takes twenty minutes to give. This is that answer, written down, with the 2026 facts attached.

The short version: MSIX is not dying, but its story has split in two. On virtual desktops it won outright. On physical endpoints it has quietly lost ground, and the tooling an enterprise repackager depends on has barely moved in two years. Meanwhile the MSI route got materially better. Both of those things are true at once, and both matter to how you plan.

Where MSIX actually stands in 2026

Start with the case for MSIX, because it is real. Microsoft's own overview page still describes MSIX as the modern Windows app packaging format and carries no deprecation notice. More tellingly, Microsoft is deprecating the MSI installer for PowerShell itself in favour of MSIX, from PowerShell 7.7-preview.1 onwards, and describes MSI in that announcement as "a legacy technology". Package identity is also becoming a gate: several newer Windows APIs - AI, notifications, security surfaces - require an app to have a package identity, which unpackaged Win32 does not.

In the same PowerShell announcement, though, Microsoft concedes the point that packaging teams have been making for years: "MSIX doesn't support all use case scenarios that MSI enabled, such as remoting and execution by system-level services (like Task Scheduler)." That is Microsoft, not a sceptical vendor, documenting the gap.

And then there is the tooling, which is where enthusiasm meets the floor:

• The MSIX Packaging Tool - the thing you actually convert legacy installers with - has shipped no release since version 1.2024.508.0 in May 2024.
• MSIX Core, the down-level support story, is dormant; its support page content dates to 2022.
• MSIX Hero, the community tool most packagers reach for, last released v3.1 in December 2024.
• Microsoft abandoned its own flagship MSIX-style deployment: the Microsoft Store installation type of Microsoft 365 Apps stopped receiving feature updates in October 2025, and security updates end in December 2026. Customers are being moved to Click-to-Run.
• Intune's 2026 investment is pointed elsewhere. The Enterprise App Management catalogue contains "Windows Win32 applications (exe and msi)" - no MSIX, and no published roadmap for it.

The split: MSIX won on virtual desktops

If your workload is Azure Virtual Desktop, the picture is completely different, and much more positive. Microsoft's App attach went generally available in June 2024 and replaced the original host-pool-scoped MSIX app attach, which was deprecated on 1 June 2025. The replacement is better in every direction that matters operationally: per-user assignment, one package across multiple host pools, in-place upgrades and side-by-side versions.

App attach now takes MSIX, MSIX bundle, Appx, Appx bundle and App-V packages, on CimFS or VHDX images, and as of April 2026 it is supported on Windows Server 2025 and 2022 session hosts as well. Nothing is lined up to replace it. If you are packaging for AVD, MSIX is the sensible target and this is settled.

A related detail catches people out: App-V's deprecation was reversed. Microsoft's support policy now states the App-V client and sequencer "have moved to fixed extended support and is no longer deprecated" - though also "no longer being developed". The nuance is that only the client and sequencer got the reprieve; App-V server components remain deprecated and their support ended in April 2026.

What MSIX still cannot do on a physical endpoint

This is the part that decides most real packaging tickets. Every item below is documented by Microsoft, not folklore:

Requirement	MSIX position
Device, printer or kernel drivers	Absolute no. "MSIX doesn't support Windows drivers." No manifest extension exists.
Windows services	Supported since Windows 10 2004, but the service account is limited to localSystem, localService or networkService. No custom or domain service accounts. No per-user services.
Writing to HKLM	Blocked. Any attempt to create or modify an HKLM key fails with access denied.
Apps that write to their own install directory	Not supported - WindowsApps is read-only at runtime. The exception, MutablePackageDirectory, is documented as limited to Microsoft and partner PC games. This is what kills in-app self-update.
ODBC drivers	No manifest support; registration lives in HKLM, which is blocked.
Machine-wide fonts	SharedFonts shares beyond the package but installs per-user.
COM consumed by other software	Packaged COM works with COM APIs, but "will not work for application extensions that rely upon directly reading the registry". Anything that enumerates CLSIDs from the registry will not see it. GAC assemblies cannot be exposed externally either.
True per-machine install	MSIX is per-user by design. All-users means provisioning, with registration happening per user at next logon - and a standard user can uninstall a provisioned package for themselves, after which re-provisioning will not bring it back.
Self-healing / repair	No MSI-style repair. Repair is user-initiated in Settings; the scriptable option, Reset-AppxPackage, destroys user data. Uninstall, in fairness, is genuinely cleaner than MSI.
Shell extensions	Partly solved. Classic context-menu handlers work via a COM surrogate, but only on Windows 11 21H2 or later. Icon overlay, preview and thumbnail handlers have no documented manifest support.

Licensing dongles - HASP, Sentinel, CodeMeter - fall foul of the driver ban, since they ship kernel or USB filter drivers. We have not found a vendor statement to cite on that, so treat it as a reasonable inference rather than a documented rule, but plan for it.

Signing: the operational difference people underestimate

MSIX must be signed - Windows will not install an unsigned package. An OV certificate is sufficient; EV is not required. The trap is elsewhere.

The manifest Publisher must exactly match the certificate's Subject distinguished name - every field, in the same order. Get it wrong and you see error 0x8007000B with Event ID 150, telling you the manifest publisher name must match the subject name of the signing certificate. This is the single biggest day-to-day difference from MSI, where any valid code-signing certificate will do and the installer does not care whose name is on it.

Three more things worth budgeting for:

• Hardware key storage is now mandatory for OV, not just EV. Since 1 June 2023 the CA/Browser Forum has required code-signing private keys to be generated and held in hardware meeting FIPS 140-2 Level 2, Common Criteria EAL4+ or equivalent. Reseller list prices at the time of writing run from roughly $219 a year for Sectigo OV to $685 for DigiCert EV.
• Azure Trusted Signing has been renamed Azure Artifact Signing and is generally available. Basic is $9.99 per account per month for 5,000 signatures, Premium $99.99 for 100,000. It signs MSIX, runs at FIPS 140-2 Level 3, and issues short-lived certificates that auto-renew - which removes most of the key-custody problem.
• Always timestamp. Without a timestamp, an expired certificate means the package fails to install; with one, it still installs. Already-installed apps keep running either way. This is a real gap for internal self-signed packaging, because self-signed certificates generally cannot be publicly timestamped.

For internal certificates, the trust has to be on the endpoint before or alongside the app - an Intune trusted certificate profile landing in Local Computer › Trusted People. Ship the app first and it will fail, cleanly and confusingly.

The Package Support Framework problem

PSF is the compatibility escape hatch: a set of runtime fixups that redirect file and registry writes, patch legacy registry behaviour, and generally make stubborn apps behave inside a container. Nearly every non-trivial enterprise MSIX conversion depends on it.

Microsoft's PSF repository last shipped a release in February 2024. The actively maintained version is a community fork by Tim Mangan, which states plainly that Microsoft has "neglected it for some time and seem disinterested in maintaining it", and which has builds through 2026. It also carries the successor to the file redirection fixup that the Microsoft repo never shipped.

The fidelity numbers are worth knowing, with their caveat. Mangan's MSIX Report Card 2025, published February 2025, tested 115 applications: 90.43% converted at high fidelity with PSF, 34.78% without it, against an App-V baseline of 94.78%. He graded the tooling B, down from B+. That is one researcher's fixed corpus rather than an industry survey, and should be quoted as such - but it is the most methodologically transparent figure available, and it is a long way from the "99.96% install and uninstall success" that appears on Microsoft's own overview page.

Deployment reality: Intune and Configuration Manager

Both support MSIX. Neither treats it as a first-class citizen.

In Intune, MSIX deploys as a Windows line-of-business app. The size ceiling is 8 GB, against 30 GB for Win32. The .appinstaller format is not an accepted upload type, so updates mean uploading a higher version rather than pointing at an auto-update manifest. All the richer app-management features - supersedence, dependencies, detection and requirement rules - live on the Win32 side. Microsoft's own documentation also warns that mixing LOB and Win32 apps can cause TrustedInstaller conflicts during Autopilot enrolment.

In Configuration Manager - current branch 2603 - MSIX has been in the application model since 1806, with manifest auto-detection and supersedence for updates. As in Intune, .appinstaller is not a supported deployment type.

And the web-install path is largely gone. Microsoft disabled the ms-appinstaller: URI scheme by default in December 2023 after threat actors used it for one-click malware delivery. It can be re-enabled by policy, but the frictionless "click a link, install an MSIX" story that was once part of the pitch is now off by default on every endpoint.

Meanwhile, the MSI route got better

This is the part that gets left out of MSIX comparisons. While MSIX tooling stalled, PSAppDeployToolkit had its biggest release in a decade.

PSADT v4.0 went GA in December 2024, and the current stable release is v4.1.8, from 14 January 2026. There is no v5. What changed:

• It is now a proper PowerShell module with compiled C# underneath, rather than a dot-sourced script. All VBScript is gone.
• Every function carries an ADT prefix - Execute-Process became Start-ADTProcess, Write-Log became Write-ADTLogEntry. The entry point moved from Deploy-Application.ps1 to Invoke-AppDeployToolkit.ps1, and configuration from XML to Config\Config.psd1.
• The whole module is code-signed, and there is a new Fluent UI with light and dark modes alongside the classic dialogs.
• The v4.1 headline: ServiceUI is no longer required. User interaction now runs in a separate process in the user's session, with no token manipulation - which removes one of the most brittle parts of any SYSTEM-context deployment.
• v3 script format still runs via automatic remapping, and Test-ADTCompatibility and Convert-ADTDeployment exist to help migrate. Note that Fluent UI does not work in v3 compatibility mode, and custom variables or code outside the main script blocks will not transfer.

Two practical notes: avoid 4.1.1 and 4.1.2, both of which were pulled for QA issues, and be aware that PSADT has no native MSIX support - there is no MSIX function, people call Add-AppxPackage directly, and Uninstall-ADTApplication does not handle MSIX. Patch My PC now stewards the project; it remains free and open source, with paid commercial support available separately.

A triage rule you can actually apply

Rather than a migration programme, run a decision at intake. Nothing here requires judgement calls in the moment - each row is a documented constraint.

Verdict	Signals
Hard stop - stay on MSI / PSADT	Needs drivers or a licensing dongle · needs a custom or domain service account · writes to HKLM · registers an ODBC driver · needs elevated custom actions at install time · writes to its own install directory or self-updates · is consumed by another process that reads COM or the GAC from the registry · target estate is Windows 10 or LTSC
Good fit for MSIX	Target is AVD or a session-host estate using App attach · app is modern, self-contained and per-user · no shell integration beyond a classic context menu on Windows 11 · you have a signing story that survives certificate rotation
It depends - and it depends on PSF	Everything else. Budget for fixups, test on the actual target build, and accept that the fixup layer is community-maintained

Microsoft's own packaging decision guide, updated in May 2026, presents packaged, packaged-with-external-location and unpackaged as three legitimate choices and recommends unpackaged for broad Win32 distribution. If you need a citation to justify keeping MSI in the factory, that is the one to use.

One licensing detail worth checking before you plan anything

If part of your answer to "how do we modernise packaging" is Intune's Enterprise App Management, check what you are entitled to first. EAM is a paid add-on requiring a subscription beyond Intune Plan 1 or Plan 2 - list price $2.00 USD, £1.54 GBP per user per month. But Microsoft's pricing page now states that select advanced endpoint management capabilities are being rolled into Microsoft 365 E3 and E5, and from July 2026 E5 gains Enterprise App Management while E3 does not. For an E5 tenant it is effectively free; for Plan 1 or E3, it is a line item.

Worth knowing what it does and does not do, too. It gives you a catalogue of Microsoft-prepared Win32 apps with prefilled install commands, detection and requirement rules, and auto-update for Required assignments. The documented limits are that it works on Required assignments only, updates all devices simultaneously, and offers no phased rollout and no rollback - which is precisely the gap third-party patching products exist to fill.

The bottom line

MSIX is not a trap and MSI is not a legacy embarrassment. They are converging on different jobs. If you run virtual desktops, App attach is where MSIX earned its place and you should use it. If you run physical endpoints across a mixed Windows 10 and 11 estate, packaging to MSI and wrapping with PSADT v4.1 is the pragmatic, well-supported, better-tooled choice - and it just got a significant upgrade while MSIX tooling stood still.

The strategic answer is not "pick one". It is to run a triage rule at intake so that each application ends up in the format that can actually deploy it, and to keep the capability to do both. That is boring, and it is right.