Windows Virtual Desktop is now generally available! from the evolution of RDMi and now to Windows Virtual Desktop has been an interesting journey in how Microsoft has now converted the RDS components into PaaS services which they are now provinding in combination with Windows 10 Multi-user and a pretty good licensing model makes this an interesting service.
Essentially Microsoft is hosting all the services in the middle (Web Access, Gateway, Broker and Diagnostics) the rest is still our responsibility when it comes to building the backend.
I’ve previosly blogged about Windows Virtual Desktop in terms of what you need to consider –> https://msandbu.org/windows-virtual-desktop-in-prevew-what-you-need-to-think-about/ where I focused a lot on the license entitlements. But let’s take a look at the architecture behind this and what we still need to get fixed.
1: Traffic flow – Just some time before it went GA – Microsoft also announced that the management components are also now available in West Europe (Before they were just in US) so if you are hosting your VDI instances or RDS servers in another region traffic will still flow trough the West Europe Region. Now however WVD is using a Reverse connect technology means your destination VM doesn’t need any inbound ports to be opened. Even the default RDP port, TCP/3389, doesn’t have to be open. Instead, an agent on the session pool creates an outbound connection using TCP/443 into the Windows Virtual Desktop management plane.
Azure is doing reverse proxy for RDP traffic. This traffic is encapsulated using WebSockets so not as native UDP.
The estimated MS depending on where you place your session pool can also be viewed here –> https://azure.microsoft.com/nb-no/services/virtual-desktop/assessment/ essentially this means that you will get a better user experience if you build the session pool within the same region where the WVD management and data plane is configured now within West Europe.
2: Domain required – For setting up WVD in Azure you need to have an Active Directory in place to ensure that machines can join a domain ,and no direct support for Azure AD Joined devices. Meaning that the session pool cannot be joined to an Azure AD tenant, only using Hybrid AD Joined mode is supported.
3: Automated Scaling needs to be configured internally – If you want to have autoscaling for WVD you will need to have a seperate virtual instance that is always-on that needs to be configured accordingly to the scripts defined here –> https://docs.microsoft.com/en-us/azure/virtual-desktop/set-up-scaling-script
4: If using NetApp files for Profiles understand the limits – One of the ways to configure Profile Containers for FSLogix is to use Azure NetApp files ( documented here –> https://docs.microsoft.com/en-us/azure/virtual-desktop/create-fslogix-profile-container) there is currently an limitations on the Azure NetApp files and that is if there is more then 1000 IP’s on the same VNET the fileshares will not be accessable, (more info about that here –> https://docs.microsoft.com/en-us/azure/azure-netapp-files/azure-netapp-files-resource-limits)
5: MFA using Conditional Access – If you want to configure MFA for access to the service you would need to use Conditional Access for Windows Virtual Desktop here –> https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/app-based-mfa this applies for both client and web based access.
6: Beware of Office 365 VoIP optimization – If you are entitled to use WVD you can also use FSLogix to ensure optimal performance and management of Office 365 profile data on WVD, but you should be aware of that as part of WVD there is no native optimization of use of Skype and or Teams such as what VMware and Citrix has developed. Something however is in the works here –> https://www.microsoft.com/en-us/microsoft-365/blog/2019/07/01/improving-office-app-experience-virtual-environments/
7: Automatic update of the WVD Agent – For most newer operatingsystems, the WVD agent which is installed on the session hosts will perform automatic update of the agents as part of the service. There is however no current way to get information about when the update mechanisms.
8: No Direct SSO using Azure AD Native – If you today are using SAML based SSO with for instance Azure AD or other iDP’s such as if you have end-users on Azure AD joined machines and want to provide SSO directly to a WVD desktop this is not currently possible and it requires that you have configured an ADFS.
9: If using Azure AD Domain Services with AD based synced users – This scenario is not currently supported and therefore will not work to provide access –> https://techcommunity.microsoft.com/t5/Windows-Virtual-Desktop/Announcement-Connectivity-issues-from-synchronized-users-to-VMs/m-p/759642
10: There is no image provisioning feature in the product – As of now there is no image provisioing feature in the product so deployment of the service and the backend servers/VDI are done using ARM templates or using Terraform as an alternative. Or static machines and therefore you would need to use management tools within Azure such as update management and desktop analytics against the session hosts / VDI to ensure update compliance.
11: What about Management tools? – Since essentially WVD is a broker, licensing, web access and no image provisioning or central policy management solution there is limited management capabilities to WVD. The capabilities that the solution exposes is trough the REST API or as part of the PowerShell cmdlets. Some have built management capabilities on top of it, but you can find the REST API here –> https://docs.microsoft.com/en-us/rest/api/virtual-desktop/
I see now already that many partners are now moving towards WVD and building solutions on top to make application migration easier, management tooling, monitoring and as well.