MSIX App Attach - the future of application delivery, a sneak peek of the upcoming Azure portal integration

At the time of writing this, the ability to manage MSIX App Attach inside the Azure portal is in internal testing, what we refer to as dogfooding.

This is a sneak peek at this new capability. The public preview will be starting shortly, look out for further announcements on this, the screen shots below, are not yet available in the Azure portal, but show you the user experience you will have when the preview commences.

The underlying capability of MSIX App Attach itself has been in preview for some time but it required using only PowerShell scripts to achieve the management, and many customers were explaining that this was a little cumbersome and problematic.

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"

In this blog, I cover:

1. A brief introduction to MSIX App Attach.
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.
4. Potential cost savings.
5. FAQ's.
6. Best practices.

1. Introduction to MSIX App Attach
If you haven't yet used MSIX App Attach, then this is a brief introduction to this new capability.

The first thing is that MSIX App Attach is the combination of two separate items:

MSIX + App Attach

1. MSIX is our new application packaging format, that will effectively replace everything before it, but is not an exact replacement for all previous capabilities however.  It will eventually replace App-V which is not getting any new updates, however as above MSIX App Attach is NOT application virtualisation. MSIX applications run within a container, that has a virtual file system and registry. This is completely separate to Windows Virtual Desktop. Many applications are out there already in this format, and many developers are also producing their applications in MSIX format. We also have a packaging tool, that allows you to take non MSIX format applications and convert them to MSIX. This MSIX Packaging Tool can be found in the Microsoft store:

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.

The cloud introduced the paradigm of virtual machines being treated as cattle rather than pets. Pet VM's are those you care a lot about, the cattle less so, or at all.

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.

App Attach does for applications, what FSLogix does for the user profile. However it is not using any FSLogix technology. The support for App Attach is built into Windows 10 2004 natively.

This now provides the nirvana of total separation of profile, applications and operating system, without affecting the user experience.

The goal here is to remove or reduce the need for multiple images and the resulting silos containing specific applications for specific groups of users, and the complexity and time needed to update individual images when needed and specific apps in the silo. Enabling us to move to a single image and user applications dynamically presented as required.

2. How to Configure MSIX App Attach in the Azure Portal

So let's look at how to set this up. This blog won't cover the two pre-requisites steps of converting an existing application into MSIX format, and expanding that MSIX package into an MISIX image. 
  • 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.
You will need to have at least one application in MSIX format that has been expanded into a VHD, and have that VHD stored on an SMB share that the VM has access to.

Note that with App Attach, the session host VM's need read only access to the file share. This is simple to configure if you have a Windows file share. If you want to use Azure Files (AZF) then you need to follow this guide written by Stefan Georgiev, PM for App Attach, to enable this capability on your Azure Files Share. This guide does a great job to explain the process, but it can be summarised by stating that you need to:
  • 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.
Look out for a similar guide on configuring Azure NetApp Files.

To start you will need to have:
  • 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:
          Machine boot/sign in:  10 IOPS
          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.

1. To access the preview you need your subscription to have been whitelisted. To request this complete this form

Go to Windows Virtual Desktop
There are two steps to present an MSIX App Attach application to end users.
The first is to present the MSIX package to the session hosts in your host pool. The second is to present the same MSIX application to the specific users of the application. This will allow those users to launch it on any session host they connect to on any given day.

The App Attach management capability is built into version 1.0.2659+ of the Remote Desktop Services Infrastructure Agent. Also the session host VM's need to be Windows 10 Enterprise version 2004 where the support for App Attach is built in. Check the RDS infrastructure Agent is 1.0.2659 or later before proceeding.

2. Go to Host pools, and select the host pool you want to present the App Attach apps. This host pool needs to be in the validation ring. This is a setting in the Properties section:

In the Manage section you will notice the new "MSIX packages" section
3. Click on Add at the top

4. In the resulting "Add MSIX Package" screen paste in the UNC path to your VHD(x) or cimFS file. This is the SMB share that you have located your VHD's on, and provided your session hosts read only access to. In my example I am using an Azure Files share. Once you have entered the UNC path, tab out of the field, and the WVD management plane will instruct a random session host VM in the pool to read the referenced file.

This may fail if your VM does not have permissions or network connectivity to this UNC location or you don't have the certificate installed on the session host VM (if it is a self signed cert). If you have any errors please reconfirm you have followed all the steps of this guide to provide the session host VM's read access to the file share.

This needs to be the absolute path to the MSIX package, and only .VHD, .VHDX and .Cim extensions are supported.

If successful the following fields will then appear:

5. Provide a Display Name and change the State to Active
Click on add at the bottom

You have now added your MSIX application to this host pool, all session hosts can attach this VHD(x), CIM and you will be able to present it to users configured next.

If you are logged on to this session host VM and launched Disk Manager you will now see there is an extra disk mounted without a drive letter. This will be the VHD(x) containing your expanded MSIX application, (in my example I have four separate MSIX packages attached). You may need to wait up to five minutes* before the VHD is mounted, see the How does this work section below for more details.

* see the FAQ section to see how to reduce this time.

Nte that if you are using cimFS then you will not see a disk attached. The only way to see that the cimFS disk is mounted is by running mountvol from a command prompt.



6. You now need to present this Application to your users. Back in the Windows Virtual Desktop hub in the Azure portal go to Application Groups. MSIX Applications can be added to either the Desktop Application group or to any RemoteApp group. We will add Chrome to a Desktop Application Group

Go to your Desktop Application Group and in Manage select Applications

7. Click on Add at the top. 

8. In the MSIX package drop down select your MSIX package, provide an Application name, display name and description.

Click on Save at the bottom.

The presentation of the icon to the user only occurs at user logon. Now when a user who has been provided access to this Desktop Application Group signs in the MSIX application will be registered with the operating system and the relevant icons will be presented in the normal location in the Start Menu as well as the recently added section, the point being, this is the exact same behaviour as if the application had been physically installed onto the local file system and the OS.

You have now dynamically delivered an MSIX application via App Attach to a Windows Virtual Desktop session host VM using the Azure portal.

How do you present different applications to different users or sets of users from the same host pool?

This is the nirvana of having any user launch any application they have access to on any VM they log into.

This is actually very simple. You basically need to follow the two steps above. The MSIX package needs to be presented to the host pool. This will ensure that the VHD(x)/cimFS disk is mounted and the application staged across all session hosts in the pool that a user could log in to.

To get different applications to different users, all you need to do is create multiple "RemoteApp Groups" (RAG). In the example above we added an MSIX application to the "Desktop Application Group" (DAG). This means any user who has been assigned to the DAG can launch any MSIX application.

But if you create let's say two RAGs each with a different MSIX application assigned, and then assign those two RAGs to two different users and then have those two user's login to the published desktop only the applications assigned to them via the RAG will be registered in the OS, resulting in those two different users only seeing the specific MSIX application assigned to them via that RAG.

This can also be acheived via Powershell. You will need V2 of the Az.Desktopvirtualization cmdlets released on 18 Nov 2020. This version includes the new cmdlets for App Attach. The cmdlets fall into three categories:
Add an MSIX package to a host pool:
    Expand the MSIX image: Expand-AzWvdMsixImage
    Add MSIX package to host pool: New-AzWvdMsixPackage
    Confirm package created: Get-AzWvdMsixPackage

Publish MSIX apps to an app group
    Publish the app: New-AzWvdApplication

Remove an MSIX package from a host pool
    Remove package: Remove-AzWvdMsixPackage

3. How does this all work?

So as mentioned earlier the App Attach capability is built into version 1.0.2659 and above, of the WVD agent running on the session host which must be at least Windows 10 Enterprise 2004. The WVD management plane has been updated to support this new capability.

1. The WVD admin assigns an MSIX package to the host pool.

2. A session host is selected at random to interrogate the VHD file containing the expanded MSIX application, in order to retrieve the information about the application itself. It also validates the structure of the package, confirms a valid certificate is installed and checks for any application dependencies. The VHD has not been mounted at this point.

3. Every five minutes the WVD agent on the session hosts reach's out the WVD management service to check for any updates, this means it may take anywhere up to five minutes for the VHD to become attached to all the session hosts in the host pool.

4. If there is a change as above, then the session host VM's will attach the VHD file, known as staging. The VHD's are then visible in Disk Management to an administrator (only if they are VHD(x)'s).

5. The WVD admin then assigns the same MSIX application(s) to the Desktop or Remote Application group, which itself is assigned to users. This enables the users to see the relevant icon.
The users then sign into their desktop at which point the application is registered with the operating system and it can then be launched.

The reverse of the above process is also true for the emoval of applications. When an MSIX package has been removed from the host pool it will take up to five minutes for the VHD to be detached from
the session host. To prevent the app from being launched it can be set to Inactive in the host pool.

Similarly a user will need to logoff for the application to be removed. In like manner publishing new apps to users will require them to sign in again to see the newly attached application. It's important to remember that user sign in's and logoff's are the action required to see new applications and likewise remove them.

4. Potential cost savings.

How is it possible to achieve cost savings using MSIX App Attach in Azure? Well it comes down simply to two things.

Firstly, the cost difference between Managed Disks in a VM, and the storage you choose to host the MSIX Packages, let's say Azure Files.

Secondly, the cost effect of scale, in that you are saving local disk costs across a number of VM's compared to only having one singular Azure Files service to host all apps.

Let me explain.
Traditionally with applications being physically installed or streamed in, both require local disk storage. Plus every VM in a host pool would need the same amount of local storage to accommodate all the applications in scope, for all users.

So lets say you have a host pool of ten session hosts. The OS would take 30GiB, and then 20GiB for any specific VM apps needed, leaving a total of 50GiB of local disk requirement.

Then add to that the space required for user applications. Let's say 100GiB. Add this to the 50GiB and you have a requirement for 150GiB local disk space.

If you go into Azure and look for a Managed Disk that is 150GiB you won't find one. The closest one that will accommodate this space is a P15 which is 256GiB, and costs £34.28 (in UK South) per month.

Now App Attach has no local storage requirements, as all the packages are stored on Azure Files.
This means we can take that 100GiB that was required above and remove it, meaning our local disk requirement reduces to 50GiB. The closest managed disk is a P6 which is 64GiB, and costs £9.20 per month.

This gives us a per VM disk saving of £25.08

We do need to add in 100GiB of Azure Files. Azure Files has lots of options so we could take the worst case (in terms of cost) and use Premium which would cost £13.12 per month. Or if we opted for Transaction-optimised it would cost £5.59 per month.

So for this one VM scenario we have reduced the disk cost by: £25.08. But need to add either £13.12 or £5.59.
So for one VM + Azure Files premium our costs are £9.20 + £13.12 = £22.32
For one VM + Azure Files Transaction-optimised our costs are £9.20 + £5.59 = £14.79

The result is that by moving to MSIX App Attach, and using Azure Files we will see cost savings of:

Azure Files Premium:                         £11.96
Azure Files Transaction-optimised:    £19.49

This isn't massive amounts of money, but when you do this at scale the savings will start to add up. The Azure Files cost will stay the same as you only need one of these, However if you have ten session host VM's all using P6 and using the one Azure Files Transaction-optimised location, you will see overall costing savings of £194.90. per month.

But that is still a small host pool, if you have 100 sessions host you will see a saving of £1,949 per month which does begin to add up nicely.

*This is a simple illustration, your environment will likely varyin numerous ways and any cost savings may well be different from above. 

5. FAQ's
Some other points that are worth considering

  • 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

356 ms

255 ms

Average unmount time

1615 ms

36 ms

Memory consumption

6% (of 8 GB)

2% (of 8GB)

CPU (count spike)

Maxed out multiple times

No impact

 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.

6. Best Practices
  • 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

As mentioned the public preview will be starting shortly, so watch out for further announcements on that so that you can see this in action yourselves. 


Post a Comment

Popular posts from this blog

Reassign a WVD Personal Session Host

AVD and Azure Active Directory Domain Join public preview

How to deploy a Windows Virtual Desktop host pool using Infrastructure as code from Azure DevOps