Learning the features and limitations of MSIX app attach

Recent changes to Microsoft app virtualization

In April 2023, Microsoft announced that App-V as a product was no longer in development and would reach its end of life (EOL) in 2026. However, in November 2024, the company announced the following changes:

• The previous EOL announcement for the App-V client was revoked.
• The deprecation of the App-V Sequencer was revoked.
• App-V Server will still reach its EOL on the same date. 
• The app attach feature in AVD would now support delivering both MSIX packages and App-V packages. 
• The original MSIX app attach feature would be deprecated on June 1, 2025. 
• The new app attach would feature integrations from third-party vendors, enabling package delivery through additional third-party software that integrates with the Azure Console for AVD.

As a result of these changes, the main delivery method for App-V packages will be through app attach, so organizations that still use App-V can continue to do so with app attach in AVD. 

What is app attach? 

App attach is a feature that delivers MSIX-, App-V- and AppX-based applications to AVD VMs. App-V is a virtualized application format, and AppX is mostly a wrapper for Universal Windows Platform apps.

MSIX, in its simplest form, is a packaging format for Windows apps. It offers an updated and improved packaging experience and lifecycle management compared with the traditional Microsoft Installer (MSI) format. It also maintains the functionality of current app packages and installation files. In addition, MSIX introduces new features for packaging and deploying Win32, Windows Presentation Foundation and Windows Forms apps. 

IT can also configure MSIX-packaged applications to operate within a container called AppContainer. Within this container, both the main app process and its child processes operate, letting them run isolated through file system and registry virtualization similar to what App-V provided. This lets IT pros have multiple versions of the same app running on the same machine without causing any conflicts if they need to read or write to the same set of files or registry.

Every AppContainer application can access the global registry. However, it only writes to its individual virtual registry and application data directory. This ensures that the data is removed upon app uninstallation or reset. The virtual registry and file system of an AppContainer app remain inaccessible to other applications on the same host. 

How app attach works in AVD

App attach uses a unique format for its package definitions, differing from the standard MSIX format. This ensures that apps become available to users quickly when they log into a Windows VDI session. Specifically, the package format is a Windows disk partition or volume that is remotely mounted rather than copied into the user's virtual machine and then integrated into the environment. 

App attach adds no new capabilities when it comes to delivering standard MSIX packages, other than the speed of getting the package ready for the user. Additionally, Microsoft designed the feature to work with AVD to provide app streaming.

IT can assign app attach packages across any host pool or session host and distribute them to multiple host pools. One of the benefits of app attach is that it now supports both common identity options: either Active Directory (AD)- or Entra ID-joined. This enables IT to handle app deployment without the need for any AD domain controllers. 

App attach works by storing app images on an SMB version 3 file share, which gets mounted on each session host at user sign-in. This setup is flexible in terms of storage, so IT isn't limited to a specific storage type. The recommendation from Microsoft is to use Azure Files since it's compatible with both Microsoft Entra ID and AD Domain Services (AD DS). 

An alternative option is Azure NetApp Files, but it requires session hosts to be joined to AD DS, since it doesn't support Entra ID. 

Each host in AVD mounts the application images from the file share. This means that each host needs to have NTFS and share permissions to read objects from the file share. 

For instance, if an admin plans to use AVD app attach with Entra ID-joined devices, they only need to assign the "Reader and Data Access" role to both AVD and Azure Resource Manager Provider service principals. 

When planning to deploy this for a production environment, IT must take the following measures: 

• Make sure the file share is in the same Azure region as the session hosts.
• If using Azure Files, make sure the storage account is also in the same region as the session hosts.
• Exclude the disk images containing the apps from antivirus scans such as Defender, since they're read-only.
• Make sure the storage and network fabric can deliver sufficient performance.
• Avoid using the same file share for FSLogix profile containers.

The integration process of an MSIX application on a VDI host involves three steps: mounting, staging, and registering. For single-user OSes, these steps are performed for each package individually. In a multi-user OS, the mounting and staging might be omitted for packages that are already added for another user. Once the app is registered, it operates within the same MSIX container as it would if deployed using the traditional MSIX format. This approach lets the app function as though it were natively installed. 

App attach implementation requirements

MSIX offers support for other Windows OSes, including Windows Server and Windows 10 and 11 for both single-session and multi-session configurations. However, the app attach feature specifically requires Windows 10 or 11.

For app attach, IT can use the new Composite Image File System (CimFS), VHDX or virtual hard disk (VHD) for disk images, though Microsoft does not recommend using VHD. Mounting and unmounting CimFS images is also significantly faster than VHD and VHDX. In addition, these processes consume less CPU and memory. Microsoft specifically recommends using CimFS for app images if the session hosts are running Windows 11. However, there is not much tooling available for the use of CimFS. It also circumvents the 256-character path limit that VHD/VHDX has, which commonly affects apps such as those bundled with a Python distribution.

In all three of the formats, the MSIX files are stored uncompressed using app attach, unlike the original MSIX package, where they are compressed. Therefore, on average, applications take up 2.5 times the storage that the MSIX packages do on the file share that they are stored on.

However, one of the strengths of app attach is that it does not require any additional infrastructure, just storage. Other app layering and virtualization services have some infrastructure requirements. 

The future of app attach

App attach will most likely become the default service to deploy applications to AVD. The news of App-V support in app attach made it easier for organizations to postpone the job of converting their existing App-V applications, since not all apps can be directly converted to the new MSIX format. 

Even with higher levels of compatibility due to the changes made in the MSIX format with the release of Windows 11 version 24H2, some are still struggling with old apps. 

This is also why Microsoft has started to allow third-party vendors to build integrations on top of app attach. It helps with app compatibility, but it also provides more control mechanisms to handle app distribution more dynamically. The following vendors are now able to integrate with app attach: 

• Liquidware FlexApp.
• Numecent Cloudpager.
• Omnissa App Volumes.

One of the upsides of using a third-party vendor is support for non-Azure platforms and the ability to run on physical devices. They also provide higher compatibility rates compared with traditional MSIX-based apps. Another feature is support for application grouping. This enables, for instance, two given apps to interact in their own virtual environment, which is useful for apps that have some form of integration. 

MSIX-based apps also need to be signed with a code certificate, which can be from a trusted certificate authority or self-signed certificate, which must be trusted by the host pools. This process is much simpler with third parties that do not have the same requirement. 

What do these changes mean for organizations?

Because app attach supports Entra ID and doesn't require dedicated infrastructure, it provides a cost-efficient way to deliver applications for AVD. 

With Microsoft's strategy of only supporting App-V for AVD-based environments, it's clear that the company wants to push existing App-V customers to move their VDI workloads to Azure as well. While the features it provides might work for many organizations, others have requirements or a complex list of apps that require third-party tools.

These developments show Microsoft's intent to make app attach the standard for application delivery in AVD, giving organizations a scalable foundation for workspace management.

Editor's note: This article was originally published in 2024 and was updated in 2025 to improve the reader experience.

Marius Sandbu is a cloud evangelist for Sopra Steria in Norway who mainly focuses on end-user computing and cloud-native technology.