You are excited since MSIX App Attach for Windows Virtual Desktop is in GA – Please consider few things before you introduce it to production

In any VDI technology, App delivery is an important part of the VDI Lifecycle process. Typically, in any enterprise when you will plan for the App Delivery, you can’t stick to a single method. It is unlikely that a single application delivery method will meet all the requirements of the various applications that must be included in an environment. Based on the outcome of the application categorization assessment process and the overall image management strategy (installed images, scripted images, and layered images), several application delivery methods can be considered. In general. the below options are some of the available VDI App Delivery methods which are widely accepted in most enterprises globally.

Option 1: Create a separate image for each department. (Multiple Images by Role)
Option 2: Load image with all the applications required. (Mega single image with hidden Apps)
Option 3: App sitting outside of the virtual machine. (Only attach the Apps to VMs)

The 3^rd Option is something that is very new for WVD, it’s currently in GA in Azure dated April 13^th as you can see here, This option is currently gaining huge popularity due to the feature of the containerization of the Applications.

What is MSIX App Package?

MSIX is a Windows app package format that provides a modern packaging experience to all Windows apps. The MSIX package format preserves the functionality of existing app packages and/or install files in addition to enabling new, modern packaging and deployment features to Win32, WPF, and Windows Forms apps.

What is MSIX App Attach?

MSIX App Attach enables users to skip having to maintain multiple master images for different applications and enables packaged applications to be stored outside a virtual machine so that each application can attach itself when users need it. It’s a step beyond traditional app layering and app streaming.

Picture Credit: Microsoft Corporation.

MSIX feature support

The following table shows which MSIX features and scenarios are supported in different versions of Windows.

For more details, you can check the MS Article here.

The architecture of MSIX Apps

Apps that are packaged using MSIX run in a lightweight app container. The MSIX app process and its child processes run inside the container and are isolated using a file system and registry virtualization. All MSIX apps can read the global registry. An MSIX app writes to its own virtual registry and application data folder, and this data will be deleted when the app is uninstalled or reset. Other apps do not have access to the virtual registry or virtual file system of an MSIX app.

Why MSIX App Attach is gaining popularity?

The MSIX App Attach is gaining the popularity for the following reasons:

Network bandwidth Optimisation – MSIX decreases the network impact by using the 64k block. This is done by using the AppxBlockmap.xml file contained within the MSIX Application package. MSIX has been specifically designed to support cloud and modern systems.

Disk Optimisations – MSIX removes file duplication across apps and windows, enabling shared files across applications. The applications are still independent of each other, and updates will not impact any other application that may share a file.

Reliability – MSIX provides a reliable install, and it’s suggested that the success rate is around 99.96% over millions of installs with a Microsoft guaranteed to uninstall.

Cost Savings– Storage Costs will be saved for the organization.

The success rate of the MSIX App Conversion/Creation

The process for creating MSIX App Attach “Applications” is lengthy and time-consuming. MSIX Apps are widely created, tested, and deployed in many enterprises and the success rate is 75% to 90% as per the recent webinar hosted by various experts of the MSIX technology. The MSIX App Attach is already in GA since April 23^rd, and many organizations are started rolling out MSIX Apps in Productions however there are few steps that initially can left unnoticed, Today I am going to write about that.

Inside in an MSIX Apps

Since this article is not to discuss the Architecture of the MSIX Apps so I will skip that section and directly jump into the use case which I would like to discuss here.

Use Case: A Matured DevOps Organization which has deployed the complete Automation for the Azure WVD Life Cycle Management can find Session Host Unavailable post the next run of the recycle pipeline of the Session Host.

Challenges with existing Automation Steps, when MSIX App Attach is Deployed.

Now let’s see some of the issues which admins can face if they don’t follow few new steps in the WVD Automation workflow or Modify their DevOps Pipelines when they wanted to add new Session Hosts in an existing WVD Host Pool in which they have recently added MSIX App Attach.

Let’s see what has happened, the general workflow or steps of the automation to add new Session Hosts to an existing WVD Hostpool is as follows:

1. Download the WVD agent
2. Download the WVD Boot Loader
3. Check if already an existing hostpool registration token is available
4. If not generate a new registration token
5. Install the WVD Agent, using the existing/generated hostpool RegistrationToken
6. Install the WVD Boot Loader
7. Set the WVD Host into drain mode – Optional

And organizations who follow the monthly recycling of their Windows 10 Multisession WVD session hosts will run the pipelines between 20^th to 30^th of the month, in line with MS patch cycle. And these pipelines or automation workflow generally run at non-business hrs, generally, it adds many new session host for the users and deletes the old ones.

Let’s see the problem which admin can see the next day, the screenshot depicts a scenario where the automation pipeline has run and added a new session host in a WVD Host Pool as you can see below, however, the new session host is showing unavailable, although there is no code change has been done by the DevOps folks.

To troubleshoot this issue the first step is to click on the view details section of the status as you can see below.

This is generally a JSON file that will store the error details in JSON format, where the admin can find the cause of the issue.

As you can see above it has clearly mentioned that MSIX AppAttach Health check has been failed, so the session host is showing unavailable, when this is the case Admin should immediately switch ON the drain mode of this session host so that no users should be directed to this session host when it’s not available.

Since the admin has identified the root cause of the problem which clearly indicates that MSIX App Attach is the culprit, the next troubleshooting step is to check if the required permissions are in place, admin should make sure the newly added Session Host Computer Account Should be part of the security group which has the required read-write NTFS permissions on the Azure File Share.

In this case, it was not there so the admin has to manually add the computer account to the security group as you can see below.

The next step is to make the force Sync of the Azure AD Sync Cycle so that the changes made in the security group should immediately replicate in Azure AD, the PowerShell Command of the below is shown as follows.

Once the admin is sure that changes are replicated in Azure AD they should restart the Session Host VM, to validate if the problem has been resolved or not. As you can see below still the problem persists.

In the next step of the troubleshooting process the admin should test the host pool without the MSIX App Attach and MS Azure WVD management GUI has given a very easy way to do that

In the manage, MSIX App Attach the admin need to change the state of the MSIX package to Inactive

As you can see once it’s done the State of the MSIX App will show inactive.

The next step is to restart the VM and check if the problem resolved. As you can see the problem has resolved and the 4^th newly added session host is showing as available.

However, this is not something that will work since MSIX Apps should be available to the newly added Session Host so the admin again has changed the state of the MSIX App to Active, as you can see below.

And again restarted the VM, to verify if the Status change to unavailable.

As expected the status of the newly added host again changed to unavailable.

Now there is a need to login to the VM to check the event logs pertaining to the Remote Desktop Services. The event logs clearly show another error related to the certificate as you can see below.

The error is “A certificate chain processed but terminated in a root certificate which is not trusted by the trust provider.” So now Admin needs to make sure that he should add the MSIX App Attach Code Signing certificate to the trusted certificate store of the newly added Session Host VM.

And once it’s done as you can see below

And the VM is restarted

The admin can find after few minutes that the newly added session host is available and ready for users.

Conclusion: The three main components of an End-user compute environment are typically the operating system, applications, and user profile. Unstitching or separating these components enables you to simplify deployments, virtual desktop delivery, and operating system updates/upgrades. And if you have already automated all these steps it’s important that you should add few new steps in your Azure DevOps Pipelines or workflows.

The additional steps 8 to 9 which you need to automate will be something like this.

1. Download the WVD agent
2. Download the WVD Boot Loader
3. Check if already an existing hostpool registration token is available
4. If not generate a new registration token
5. Install the WVD Agent, using the existing/generated hostpool RegistrationToken
6. Install the WVD Boot Loader
7. Set the WVD Host into drain mode – Optional
8. Add the MSIX App Code signing certificate to the trusted store of new VM
9. Add the Computer account of the newly built VM to the Security Group which has the required NTFS permissions in the Azure Storage Account File Share.

There are many ways to do it, you can use the GPO, PowerShell, and MS Intune/HCL BigFix for step number 8 and simple PowerShell automation for step number 9.

MSIX App Attach is an interesting concept, and since it’s already in GA so many organizations are planning to roll that out to production, if organizations can pass through the initial hiccups like the above, the adoption rate of the MSIX App Attach will increase exponentially in future.

That’s all for today, have a great weekend and stay safe at home.