MSIX App Attach - the future of application delivery, a sneak peek of the upcoming Azure portal integration
What we will be announcing shortly is the public preview of the consolidation of the management natively inside the Windows Virtual Desktop hub in the Azure portal. This brings the App Attach capability to the same place where you already manage the Windows Virtual Desktop objects.
"MSIX App Attach - the future of dynamic application delivery"
2. How to configure it in the Azure Portal, this is the upcoming preview capability.
3. A brief overview of how this actually works under the covers.
2. App Attach is a Windows Virtual Desktop specific service that enables the dynamic presentation of these MSIX applications to any session host VM and to the end user. This enables the full separation of the applications from the underlying operating system and thus the virtual machine, providing you with more control and flexibility in the presentation of your enterprises applications.
MSIX App Attach enables this cattle paradigm as you no longer care about the VM's as they are all the same, they don't have any applications installed (outside of those in the base image) and not dedicated or silo'd for specific apps or users. You now have a generic grid of VM's any user can log into and launch any app.
- How to package an application into the MSIX format, for further info on this review this article. The result of this is you will have a .msix file that contains your application. The next step will make that available in a file format that can later be used to "attach" to a WVD session host.
- "Expanding" an MSIX package into an MSIX image to a VHD(x) or cimFS is a simple and quick process. Once you have your MSIX package (.msix file) the next step is to expand that into an Image. To do so yo use Msixmgr.exe, follow this guide.
- Create a new (or use existing) Global Security group in your local AD, that contains your WVD Session host VM's and sync that to AAD.
- Assign RBAC permissions to the Azure Files share using the "Storage File Data SMB Share Contributor" role, for the group above. This is the equivalent of Share level permissions. Make sure you reboot the session host VMs as they won't pick up that SID of this group until they are rebooted.
- Assign NTFS File permissions on the folder to the same group, this is done from a Windows machine that has mounted the AZF Share.
- An Azure subscription
- A Windows Virtual Desktop deployment (or at least the ability to create one).
- An MSIX application, expanded into a VHD(x) or cimFS.
- A file share to house the VHD's. This could be either a file share from a VM, Storage Spaces Direct, Azure Files or Azure NetApp Files. In fact the choices for MSIX App Attach storage locations are similar to those for FSLogix profiles, this document compares the options.
For testing purposes likely the easiest and quickest way to get this up and running is just to use a standard file share from either another VM or actually from your session host VM itself. Just remember to assign the session host VM's read access to the share.
This share should be in the same region as the session hosts, as there is a requirement that the session hosts must be able to mount an MSIX package in less than 400ms. If this is exceeded the package will not mount.
App Attach has the following IOPS requirements:
Steady State: 1 IOPS
- Your application certificates are installed into the Local Computer, Trusted People certificate store on the session hosts. The easiest way to get started is to create a self signed certificate. To make this even easier you can use this PowerShell script in my Github repo to create the certificate.
Once you have the cert then you just install it onto the session hosts making sure it goes into the Local Computer > Trusted people certificate store. If you use the defaults the publishing process later will fail.
In the Manage section you will notice the new "MSIX packages" section
7. Click on Add at the top.
How do you present different applications to different users or sets of users from the same host pool?
The users then sign into their desktop at which point the application is registered with the operating system and it can then be launched.
- What are the storage options?
The storage options are the same as for FSLogix profile storage, namely Azure Files, Azure NetApp Files or a VM based storage service such as Storage Spaces Direct
- What are the storage connectivity requirements?
What is the connectivity requirement to the storage for App Attach to work, i.e. if the storage goes down do I lose the application?Connectivity is only required for the staging of the VHD. Once the VHD is mounted to the VM, then the application is running within its own container (not to be confused with a K8's container) but its running in memory. This means that the application will continue to function whilst connectivity to the storage location is lost. In fact the application will remain until the session host is restarted.
- Is CimFS supported?
You may have heard a lot about CimFS. App Attach will support our new file system known as CimFS. CimFS has lower staging and de-staging times, as well as less resource utilisation than compared to VHD(x)'s. The CimFS performance inprovments are shown below. The below table shows the results of a simple test with 500 files in each format, each being 300 MB running on a DS_V4 Azure VM.
Average mount time
Average unmount time
6% (of 8 GB)
2% (of 8GB)
CPU (count spike)
Maxed out multiple times
CimFS support will be available only in the public preview. CimFS packages are not just one single file such as VHD(x)'s. They are actually a collection of individual files:
The file that needs to be referenced to mount will have an extension of .cim
- Do CimFS files show up in Disk Management like VHD(x)’s?
No. This is by design, they will appear in “mountvol”. CimFS unlike VHD(x)s is not one singular file.
- How are application dependencies handled?
For applications that have dependencies these will be shown the host pool MSIX packages:
Our recommendation is to place these dependencies into the base image. More information is available here
- How are Windows services handled?
Applications that require Windows Services are supported and behave in exactly the same way as when using MSIX natively. In MSIX a service is installed machine wide and is not part of the container that the apps is running within. So whilst a user does not have the application registered can see the service they will not be able to interact with it as they will be missing the application. The Appx readiness service that parses the MSIX package (regardless of MSIX, or App Attach) installs the service. The service will remain on the VM until deregistration removes the service when the last user logs off.
- Does App Attach handle application licensing?
App Attach will not handle or enforce licensing. MSIX App Attach is just the application delivery mechanism.
- Can the five minute time period to mount the VHD be decreased?
Yes. To change the interval that session hosts check in with the WVD broker to see if any new packages have been assigned, create the following key and value. The minimum is one minute:
- How many MSIX images can be attached to a VM?
There is no limit, however using CimFS will increase density due to lower resource utilisation.
- What’s the size limitation to MSIX App Attach VHD(x) files?
- Can an app be auto-updated?
No. Auto update is not supported and would need to be disabled. Updates need to be managed by IT and rolled out as a separate package but with the same Family name.
- Can Microsoft Store apps be used with MSIX App Attach?
- Can I monitor/troubleshoot App Attach?
Yes. Log Analytics/Azure monitor and Kusto queries, will be supported.
- What process assigns/removes the apps (icons) to users?
User sign in/logout. WVD management plane registers apps in session through RD-Agent.
- Exclude VHD(x)'s and CimFS files from profile containers and Anti-Virus scanning
- For production, don't locate MSIX packages on the same storage as FSLogix profiles
- If you have a DR process for your session hosts, then consider extending that to include the storage location hosting the MSIX packages
- Any application dependencies should be put in the base image. Whilst they can be put into the package it is not recommended as there is no guarantee the dependency will be delivered before the application
- Locate the storage service in the same region as the session hosts