This year, I’ve spent many months head down in Windows Virtual Desktop (WVD) projects and have come across several common lessons learned from these projects. In this article, I’ll cover 5 things I learned deploying Windows Virtual Desktop.
1. Windows Virtual Desktop is an Azure service first
WVD is a VDI solution built on top of a public cloud service, rather than a product which has added support to public clouds for virtual desktops. If you were to compare WVD to traditional VDI solutions, you’ll quickly see WVD is very different.
Microsoft’s approach to building WVD has been to build a virtual desktop solution which adds a desktop broker service on top of existing Azure services. This means you can apply the same cloud adoption framework and automation principles to WVD as with the rest of Azure.
2. Build WVD on a Solid Foundation
Being successful means planning your WVD deployment by building upon an Azure adoption framework. There are many Azure components which should be planned and deployed correctly including identity, regions, networks, management, and security frameworks that are key to success when deploying any workload into Azure.
A Windows Virtual Desktop deployment will rely primarily on three things — choosing the right region for your desktops, configuring your virtual networks for access to applications and data, and storage to ensure good performance. Each of these you would have had to consider when deploying services into Azure before starting on WVD.
3. Ensure WVD Service URLs Aren’t Blocked
If you’re deploying WVD into an isolated virtual network, especially for a POC, it’s unlikely you’ll have issues with enabling access to a virtual desktop. However, pay careful attention to your networking configuration when integrating proxy servers and firewalls.
If traffic to these URLs is blocked or routed incorrectly, WVD virtual machines may fail to talk to the WVD control plane or perform poorly. Ideally, those destinations should be excluded from your proxy server and routed directly out via Azure.
4. WVD Uncouples RDP from the OS
Previously with Remote Desktop Services and remote Windows desktops using RDP, the version of the RDP protocol was tied to the version of Windows. Newer Windows releases provide new capabilities requiring an OS upgrade to take advantage of those capabilities.
WVD has now uncoupled the RDP stack from the operating system, meaning the RDP capabilities in WVD are supported across each of the supported Windows versions on WVD.
The next release of Windows 10 which should be here in May, is bringing additional enhancements to RDP, so in theory we should see these on WVD with down-level operating systems including Windows Server 2019, 2016 and Windows 7.
5. RDP can Perform Better than HDX
OK, some caution here as I need to perform some additional testing, so put this one down as anecdotal – RDP on WVD can perform better than Citrix HDX.
I’ve performed some basic testing of accessing a virtual desktop via WVD and another desktop in the same Azure region (and network) via Citrix Cloud. The virtual desktop provided by WVD over RDP outperformed a desktop over HDX.
In this test, the Azure virtual network and the virtual desktops, along with Citrix Cloud Gateway were all in the same region; however, there is a difference in how the client accesses a desktop. With Citrix Cloud, the connection was over the public internet to Citrix Gateway. I suspect that the connection to WVD was via a local ingress point and then routed over the Microsoft backplane.
As I’ve said, more testing is required here and I’m hoping that I can share results of testing in a future article. My recommendation to you is when testing WVD, also test with Citrix Cloud to get a full picture of the performance and management capabilities Citrix brings to Windows 10 on Microsoft Azure.
This article has only touched on a few lessons learned in deploying Windows Virtual Desktop. There’s plenty more to share, so keep an eye out for my next article on WVD.