Now that MSIX app attach has been formally launched (find out more here), many users are asking themselves “How do I move my workloads to Windows Virtual Desktop (WVD)?” and even more importantly “Why should I move to WVD?”.
First, let us address the Why. Virtual Device Infrastructure (VDI) or Desktop as a Service (DaaS) is of course not a new technology, but WVD does offer some unique advantages, making the system feel more like a standard RDS session (multi-session) rather than a full-blown VDI system: it is more lightweight. It is also more cost-effective; it offers the ability to have users’ desktops entirely in the cloud with the usual advantages such as reliability, accessibility, and the removal of the necessity to maintain a data center. WVD, however, offers some unique key advantages worth mentioning:
1. Windows 10 multi-session: This is a version of Microsoft Windows 10 created specifically for WVD and not available outside the Azure WVD environment. It includes multi-session support, meaning it allows several desktops to be served from the same physical or virtual device. This dramatically reduces costs, makes the system more scalable, and improves the user. Windows 10 multi-session also maintains the Windows 10 user feel which is more familiar to most users than Windows Server used in other DaaS offerings.
2. FSLogix Profile Containers — When Microsoft acquired FSLogix in 2019, it acquired two key technologies: one is app attach (see next point) and the other one is the Profile Container technology. The Profile Container technology revolutionizes user experience in non-persistent sessions by allowing a user profile to follow the user even across sessions (same applications, same settings, same work files, and directory structure). This provides a consistent user experience every time they connect, regardless of which server they happen to be on.
3. App attach — App attach makes it very easy for administrators to deploy and remove applications from the desktops of specific users. As we reported previously, it is a major step forward from the existing solution.
4. Cost — Hosted on Azure and utilizing Windows 10 multi-session, costs are significantly lower than RDS or on-premises VDI.
So, how do you move existing workloads to WVD? There are four basic steps (see diagram):
Assess. In the assessment stage, IT must carry out an audit of their current on-premises environment as well as plan how their deployment will look. Consideration should be given to where the migration starts and how much data needs to be migrated (i.e., not just applications). It should be noted that some applications may not work post-migration and should be tested. This is typically the most time-consuming task of the process.
Migrate. The migration phase is where the actual “lift and shift” happens. Applications need to be converted to MSIX and then deployed through app attach. User desktops must be created, provisioned, and tested. MSIX conversions (Find out more here) are particularly difficult as each package must be tested for suitability.
Optimize. Since all these workloads are now in Azure, there’s obviously a cost involved based on the applications’ resource usage. Unfortunately, there is an obvious trade-off here between cost and end-user experience. Provision too little and user experience degrades to an unacceptable level. Provision too much and costs rise.
Manage. At this point, users are now actively using WVD. IT must also add users, desktops, and apps in line with the business requirements. IT must also monitor performance to ensure optimal user experience.
The importance of Testing
While the process looks straightforward, there are significant challenges to adoption. One challenge is that there is no single toolset that allows users to manage the entire process from a single management plane. While both Microsoft and 3rd party vendors offer solutions that assist through the four stages, none are “one-stop-shops”, and users will often need to use solutions from several vendors for a holistic toolset.
However, the biggest challenge to adoption is the applications themselves. Many of them will not transfer to WVD easily for a variety of reasons and administrators will struggle to predict which of their apps will fail in the transfer. To be deployed properly to WVD, an application needs to have a known “footprint” for performance (to be used in planning and post-deploy monitoring), it needs to be converted to MSIX (a significant challenge — as discussed here (find out more here). It also needs to work on Windows 10 multi-session, which isn’t guaranteed. IT can only be certain that these issues have been addressed through testing — a significant challenge when there are hundreds or even thousands of applications to be deployed (full disclosure; my employer, Rimo3, offers a software solution for testing at scale, which can help with these efforts).
The Diagram below shows how every stage of the process requires testing:
In post-assess testing — Applications need to be validated for Windows 10 multi-session friendliness as many applications, particularly legacy and home-grown apps, could fail. Also, the application's performance can be significantly different in Windows 10 multi-session, and it is useful to validate this beforehand as it may adversely affect the end-user experience.
In post-migration testing — Applications need to be individually converted to MSIX, then convert ed to app attach useful formats such as VHD, VHDX, or CIMFS. All these conversions need to be validated, because, as pointed out previously, they are not 100% guaranteed to work and even if they do, there may be a performance impact.
In post-deployment — Any change to the environment or any additions (such as updated applications) should be retested. Also, for security reasons, Windows patch releases may affect specific application behavior — whether compatibility or performance.
In future blogs, we’ll look at tools and methods that can help with this process and make it easier.