Cooking with Azure Virtual Desktop
A bit of a hidden gem, Azure Virtual Desktop can solve a variety of end-user computing problems, including some that are especially notable in today’s IT world. This article explains the basics of what it is, where it fits and where it doesn’t, why you should be concerned and improvements coming soon.
the need
Do you have situations where users are working from home and connecting from personal devices? Do you trust those devices and the networks they connect to? Do you have compliance regulations that require strict control over local PC storage of data, something that is difficult to achieve with normal client computers?
The solution may be virtual desktops. These solutions aren’t new, of course, and we’ve been doing two flavors of these on-premises for a while now long time. The first is Remote Desktop computing where a Windows server serves desktops that multiple users can connect to. Windows Server offers T̶e̶r̶m̶i̶n̶a̶l̶ S̶e̶r̶v̶i̶c̶e̶s̶ Remote Desktop Session Host (RDSH), and of course Citrix is known for their offerings. The second variant is Virtual Desktop Infrastructure (VDI), where you boot virtual machines (VMs) – on Hyper-V or VMware – and each user is assigned their own VM running a Windows client. Several years ago there were many different hopefuls in this space. Microsoft had some cobbled together solutions, while VMware offers Horizon†
Both flavors have a lot of infrastructure and know-how overhead and require ongoing maintenance.
I recently implemented several Proof-of-Concept (PoC) projects for two of my clients, one with Windows 365 and one with Azure Virtual Desktops, so I’ll also share some lessons learned along the way.
Add cloud and mix
Unsurprisingly, the rise of public cloud computing has tackled this space from several angles, AWS WorkspacesGoogle offers Virtual desktops and Microsoft has two offerings on the market: Windows 365 and Azure Virtual Desktop (AVD). The first is a Software-as-a-Service (SaaS) version of AVD, with dead simple configuration, simple pricing (just pick your Cloud PC size and pay a fixed price per user per month), and limited configuration options.
The important thing to consider here is that once you increase the distance between the end user’s device and the desktop they are communicating with, you add latency. Yes, modern hyperscale clouds have amazing networks and nodes in almost every major city on the planet, but latency is a fact of life. This means that the success of remote desktop solutions strongly depends on the type of applications used, the individual user’s connection quality to the Internet/cloud data center, and your configuration settings.
Microsoft has a few up its sleeve when it comes to these services, most notably the introduction of Windows 10 (and now 11) Multisession† This is a special version of the Windows client that allows multiple users to connect to the same VM and each have their own desktop. This neatly circumvents one of the problems that arose with RDSH and similar solutions that relied on running Windows Server to serve multiple desktops: application compatibility. Sometimes an end-user application is not satisfied with running on a server operating system. Windows Multisession, available only in Azure Virtual Desktop (not on-premises or in any other cloud), neatly circumvents the app compatibility issue.
The second asset is Microsoft’s long experience with remote desktop computing. The first version was introduced in Windows NT 4 and essentially Azure Virtual Desktop is a hosted version of the same building blocks that make up RDSH on-premises.
Ingredients for Azure Virtual Desktop
there is Web Access Gateway, which in AVD ensures that no RDP port is open to the Internet, always performing a reverse connection operation to the client when you try to connect. there is the Estate agentwhich chooses which VM to connect to the first time and later reconnects to the same session if disconnected/returns on another day. Diagnostics of both health and performance is built-in (via an Azure Monitor Insight) and is managed via the usual Azure tools, web portal, PowerShell, CLI or API. All of these components are managed by Microsoft as part of the service.
Your responsibilities will include image management (if you bring your own Windows images instead of the built-in Marketplace images), profile management (see below), user management and identity (Azure AD), sizing, scaling, and access control. You must make at least one host poolwith at least one session host VM in it, and you can choose from one of the VM sizes that Azure provides. The recommended size of the VM depends on the number of users per VM and the type of user workload they generate (light, medium, heavy, and power user), but it should have a minimum of four vCPUs and no more than 24. It is better to add add more hosts to serve more users because it’s easier to schedule host reboots for maintenance when you have more of them. There is also little performance gain after 24vCPUs. If you need to provide graphics acceleration in the session VMs, there are several VM series that come with high-end GPUs, such as the NVv4 (AMD Radeon Instinct MI25 GPUs) or the NVv3 (NVIDIA Tesla M60 GPU).
There are two main flavors of AVD: personal or pooled desktops. With personal, each user is assigned their own VM that they are always reconnected to and can optionally be a local administrator (think developers or engineers who need a “meaty” machine for themselves). With pooled, each user is connected to any session of the sessions available on each session host and their user profile (Windows settings, configuration, files, OneDrive files, and so on) is stored outside the VM. The technology to store user profiles for a pooled host pool for sessions is called FSLogix (based on an acquisition by Microsoft several years ago). It creates a VHD(X) file for each profile associated with the session at the time of login, so that the experience is transparent to the user. However, this makes it easy to backup these profiles (if necessary) and to update or replace the Windows 10/11 desktop separately for the user profiles.
Using MSIX app Attach also allows you to create VHD files of the applications you want to deliver to the users and attach them in the same way as the user profiles at the time of login, which greatly simplifies the app deployment. You can also mount the MSIX app on any regular PC running Windows 10/11.
Network connectivity to AVD can be anywhere over the public internet (remember, no open RDP port) or limited to site-to-site VPN/ExpressRoute connectivity from on-premises to Azure. If you have full control over the network path (or assign a public IP address to the session host VMs), you can RDP Shortpath to switch from TCP to UDP for better performance.
Customers are available for PC, macOS, iOS and Android, plus a web client that works in any HTML 5 compatible browser. Note that the built-in remote desktop client in Windows (mstc.exe) does not work with AVD/Windows 365. You can also publish individual applications instead of an entire desktop with AVD, where the user simply runs an application side by side with their local applications, but it actually runs on a session in AVD.
Access to AVD sessions can be secured using Conditional Access policies, including ensuring that every connection contains a Multi-Factor Authentication (MFA) prompt.
In general, audio and video conferencing software and remote desktops do not work well together (capturing the audio and video on the local PC, then sending it to the AVD desktop in the cloud and then to the other meeting participants introduces too much latency). However, Microsoft Teams gets special treatment with optimizations that: increase performance with some limitations (e.g. 720p video only).