Application Packaging & MSIX

What is MSIX and why is Microsoft pushing it?

MSIX is Microsoft's current Windows application packaging format, and it's the direction of travel for anything new. It installs into a container with a defined identity, writes user data to a redirected location rather than scattering it across the file system and registry, updates differentially instead of reinstalling, and uninstalls without leaving debris. It's also the format that app attach on Azure Virtual Desktop is built around.

The practical benefit is predictability. An MSIX package behaves the same way on every machine that installs it, which is the thing that ad hoc MSI and EXE deployment never quite delivers. The practical cost is that MSIX is stricter: applications that assume they can write anywhere, install drivers, or register system-level services have to be reworked or left alone.

Do all applications convert to MSIX?

In a real estate you should expect a spread. A large share of well-behaved business apps convert with little or no work; a middle band converts but needs remediation, such as fixing hard-coded paths, splitting out a service component or reworking a shell integration; and a tail either can't convert or isn't worth converting.

Part of what an assessment buys you is knowing which application sits in which band before you commit budget, rather than discovering it one app at a time.

How does App-V to MSIX migration actually work?

App-V to MSIX migration is a repackaging exercise, not a file conversion.

Then rebuild the behaviour that App-V was providing using MSIX equivalents, test it against the real workflow, and roll it out in rings. App-V support is finite; the estates that struggle are the ones that leave the discovery until the deadline is visible.

What is MSIX app attach, and do we need it?

App attach delivers MSIX applications into an Azure Virtual Desktop session by mounting a disk image from a file share at sign-in, then registering the app for that user, instead of installing it into the gold image. The payoff is a small, stable base image and per-user application assignment, so adding or updating an app doesn't mean rebuilding and redeploying the image to every session host.

It's worth it once you have more than a handful of applications, more than one user persona, or an image rebuild cycle that's become an event. If you have a single-purpose host pool running two apps for everybody, baking them into the image is honestly the simpler answer, and we'll say so.

Microsoft has also moved on from the original per-host-pool model to a newer app attach design where packages are managed as subscription-level objects; which one you're on changes the operational detail, so we check before recommending anything.

CIMFS or VHDX for app attach images?

CIMFS uses noticeably less host resource per mounted image, which matters when a session host is mounting dozens of them for every user who signs in, so it's the default worth aiming at. VHDX is the older, broader-compatibility option and remains the reliable fallback. In hands-on testing we've hit packages that run correctly natively and from a VHDX image but fail from a CIM, so this isn't a purely theoretical choice.

The practical rule: build CIMFS first, smoke-test every package from the image rather than from the MSIX, and fall back to VHDX for the ones that misbehave. CIM images also need housekeeping, because each one produces a .cim file plus object and region files in the same directory. Generate several into one folder and you get sprawl that's genuinely difficult to untangle later, so one folder per image, always.

Certificate errors: why do app attach packages fail with "App contains untrusted signature"?

Because the certificate that signed the package isn't trusted on the session host. Every MSIX must be code-signed, and the signing certificate has to chain to something the machine trusts. With an internal or self-signed certificate that means deploying it into the machine's Trusted People store on every host in the pool. Miss it and AVD returns a metadata expand failure with exactly that message, and MSIXMGR throws 0x800B010A for the same underlying reason.

It's the single most common cause of a package that works perfectly on the packaging workstation and dies in production. The fix is boring and that's the point: decide early whether you're using a public CA certificate or an internal PKI, deploy trust as part of session host build automation rather than by hand, and track expiry, because a certificate that lapses takes every package signed with it down at once.

What are the prerequisites for MSIX app attach?

Six things, and a build stalls if any one of them is missing. A supported session host operating system, meaning Windows 10 or 11 Enterprise or their multi-session editions. A file share the session hosts can reach, usually Azure Files or Azure NetApp Files, with both the RBAC role and the NTFS permissions set. Every package expanded into a CIMFS or VHDX image rather than left as a raw MSIX.

A code-signing certificate that chains to something every session host trusts. The application registered in Azure as an app attach package and assigned to the right application group. And enough network throughput between hosts and share, because app attach mounts the image at sign-in and a slow share shows up directly as a slow logon.

Two things people expect to need and do not: a separate licence, because app attach is included with Azure Virtual Desktop, and a rebuild of the golden image, which is precisely the point of using app attach rather than baking applications in.

Does app attach work with Citrix, or only Azure Virtual Desktop?

App attach itself is an Azure Virtual Desktop feature, so on Citrix you would use Citrix App Layering or its own MSIX support rather than app attach. That said, the two coexist perfectly well in a mixed estate, and the packaging work carries across: an application correctly packaged as MSIX can be delivered through app attach on AVD and through Citrix on the Citrix side, without repackaging it twice. The format is the portable part, the delivery mechanism is not.

This matters most to organisations part-way through a Citrix to AVD migration, where both platforms run side by side for a while. Doing the packaging properly once, in MSIX, means the migration stops being an application project as well as an infrastructure one.

Can you use app attach on-premises, or is it cloud only?

App attach is an Azure Virtual Desktop feature and needs the AVD control plane, so there is no on-premises-only version of it. On a traditional on-premises RDS farm the equivalent is delivering MSIX packages through the tools you already have, or using an on-premises file share with a third-party layering product.

What does carry over is the packaging. MSIX packages built for app attach install perfectly well on on-premises RDS session hosts and on physical Windows 11 devices, so the conversion work is not wasted if part of the estate stays on-premises or moves later. We package for the format first and the delivery mechanism second, precisely so that decision stays open.

What does Azure Files need for MSIX app attach?

The share needs both layers of permission, and this is where most builds stall. Every session host's computer account needs access, which in practice means putting the machine accounts in a directory group, syncing that group to Entra ID, granting it the Storage File Data SMB Share Contributor role on the storage account, and then also setting the NTFS-level permissions on the file share itself. Getting the RBAC role right but not the share ACL produces a failure that looks like a packaging problem and isn't.

Placement matters too. The whole operation of reaching the storage and mounting the image needs to complete inside roughly 400 milliseconds, so the share should sit in the same region as the session hosts, as close as the topology allows. Then exclude .VHD, .VHDX and .CIM files and the UNC path to the share from antivirus scanning; without those exclusions you get sign-in latency and intermittent registration failures that are miserable to diagnose.

MSIX or Intune Win32: which should we use for what?

Use MSIX where you want clean install and uninstall, containerised identity, differential updates, or app attach on AVD. Use Intune Win32 (.intunewin) where the application won't convert, where you need custom detection and requirement rules, dependencies and supersedence, or where you're wrapping an installer that has to run with full system access. Most estates end up running both, and that's the correct answer rather than a compromise.

The decision is per application, not per organisation. A modern, well-behaved LOB app is a good MSIX candidate. A CAD package with a licensing service and a hardware dongle driver is not, and forcing it costs more than it returns. What we care about is that the routing decision is made deliberately and recorded, so the next person doesn't have to reverse-engineer why an app was packaged the way it was.

Can you build us a CI/CD packaging pipeline?

Yes, and for most organisations this is the part with the longest tail of value. A packaging pipeline takes a source installer or captured application, builds the package, signs it, runs automated install, launch and uninstall checks, publishes to your distribution point or app attach share, and records what was produced and by whom. Vendor releases a new version, the pipeline runs, and nobody has to remember the manual steps.

We build it around what you already have, typically Azure DevOps or GitHub Actions with Intune or AVD at the delivery end, and we hand it over with documentation rather than keeping it as something only we can operate. The point is that packaging stops being a person and becomes a governed, auditable process.

What if we've lost the installer for an application?

It can usually still be packaged, by capturing the application from its current working installation rather than from setup media. This is the situation that blocks more Windows 11 and server migrations than any technical incompatibility: the vendor's gone, the source is gone, the MSI is on a share that was decommissioned in 2014, and one department still depends on the thing daily.

For that work we use our delivery partner EtherApps Forge, which captures the installed state of a running application and repackages it for a modern, supported operating system. It's not magic and it isn't right for everything, but it turns "we can't move off that server" into a scoped piece of work with a testable output.

How do you prove a package works before it reaches users?

Every package gets tested against the way the application is actually used, not just whether the icon launches. That means install, launch, core workflow, file associations, printing where relevant, licensing activation, uninstall, and then re-install over the top. For app attach we test from the mounted image on a real session host, because a package can pass on a packaging workstation and still fail on stage or registration.

When something fails, the evidence is in the MSIX and app attach event logs, which record the staging and registration sequence and the time each application took to register per user. That timing data is useful beyond troubleshooting; it tells you which applications are quietly adding seconds to every sign-in. Where user acceptance testing is needed, that's coordinated with your application owners, since they're the ones who know what "working" looks like.

Why use an MSP rather than buying a packaging tool?

Because the tool is the cheap part. Licensing a packaging product still leaves you needing someone who knows why a converted app crashes on second launch, how to structure a signing certificate strategy that doesn't expire into an outage, and what to do with the tail of your estate that won't convert. That knowledge takes years to build and walks out of the door when the person holding it resigns.

Our packaging work sits on genuine first-hand ground. Our founder, Ryan Mangan, is a Microsoft MVP, a Fellow of BCS and the author of Mastering Azure Virtual Desktop (Packt), and maintains a public MSIX app attach reference wiki and open-source tooling on GitHub. You get that depth as a service you can scale up and down, based in Brough, East Yorkshire, working with organisations across the UK.