Learning the features and limitations of MSIX app attach

Features and benefits of using MSIX app attach

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

MSIX offers support for other OSes, such as Windows Server as well as a combination of single and multi-sessions for Windows 10 and 11.

Every AppContainer application can access the global registry. However, it only writes to its individual virtual registry and application data directory, ensuring this 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.

MSIX app attach uses a unique format for its package definitions, differing from the standard MSIX format. This ensures fast availability for end user applications when they log into a virtual or local desktop session running Windows. Specifically, the package format is a Windows disk partition, or volume, that is remotely mounted rather than copied into the user's session and then integrated into the environment.

MSIX app attach adds no new capabilities to the standard MSIX deployment and execution other than the speed of getting the package ready for the user. Though it has multiple uses, Microsoft designed MSIX app attach to work with Azure Virtual Desktop (AVD) to provide application streaming.

Admins can integrate MSIX packages into an AVD host pool and manage the distribution of applications through either desktop or RemoteApp application groups in Azure Virtual Desktop. For a user to access the application on the desktop, two conditions must be in place:

• The user must be able to log into session hosts in the host pool, which requires inclusion in a Desktop or RemoteApp application group.
• The host pool must have the MSIX image assigned.

The MSIX packages must be stored on an SMB version 3 file share, which is mounted on each session host at user sign-in. This setup is independent of the storage type used by the file share. Microsoft recommends using Azure Files for this purpose due to its compatibility with the supported identity providers for MSIX app attach. Alternatively, Azure NetApp Files or file servers can be used, although this requires that the session hosts are joined to Active Directory Domain Services.

MSIX app attach had one major limitation: a dependency on Active Directory.

The integration process of an MSIX application on a virtual desktop 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 may be omitted for packages that are already added for another user. Once the application is registered, it operates within the same MSIX container as it would if deployed using the traditional MSIX format. This approach lets the application to function as though it were natively installed.

For MSIX App Attach IT can use the new Composite Image File System (CimFS), VHDX or VHD for disk images, though Microsoft does not recommend using VHD. Mounting and unmounting CimFS images is also significantly faster than VHD and VHDX, and it consumes less CPU and memory. Microsoft specifically recommends CimFS for application images if the session hosts are running Windows 11. However, there is not much tooling available for the use of CimFS. But it circumvents the 256-character path limit that VHD and VHDX have, which commonly affects applications 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 will take up to 2.5 times the storage that the MSIX packages do on the file share they are stored on.

One of the strengths of app attach is that it does not require any additional infrastructure, just some storage. Many other app layering, deployment and virtualization services have some infrastructure requirements.

Limitations of MSIX app attach

MSIX app attach had one major limitation: a dependency on Active Directory. This means that IT cannot use it with Entra ID or even Entra ID Domain Services. Admins would need to set domain controllers or allow communication with existing ones, just to allow the users to get the applications mounted within the AVD session hosts. If an IT department planned on having machines only joined to Entra ID, then it would need to use something else to resolve the issue with application management.

Fortunately, Microsoft released a new feature called app attach recently, which removed this limitation and also added a set of new capabilities:

• IT can assign across any host pool or session host and distribute application packages to multiple host pools.
• This feature provides user-specific application assignments both for desktop and remote app sessions.
• The management of application assignments, removals and upgrades can now happen without a maintenance window.
• App attach added support for Microsoft Entra ID, but admins can also still use hybrid join if needed.

This means that IT departments can use app attach with Entra ID joined machines, removing the need for domain controllers. There is now a way to provide centralized application management with sandbox and isolation features if needed. This can lead to fewer images to maintain.

With these new capabilities now available in public preview, it removes many limitations that MSIX app attach has had and provides IT admins with a way to manage applications more easily via a cloud native approach.

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