One of the things I always consider when looking to solve a specific problem is what kind of tools is best suited for the job. Not always trying to push the same solution to every problem, issue or challenges that the customers are facing.
A particular topic of this which comes up everynow and then is in terms of using of Windows Virtual Desktop to handle heavy usage and especially CAD based applications or 3D heavy applications and services. One important thing is that since WVD runs in Azure you need to plan for optimal traffic flow to Microsoft Azure to ensure the best possible end-user experience.
While many focus on the datacenter side and try to optimize, it is important to understand that there are many “obstacles” in the way from the end-user to the virtual desktop where the application resides.
Like one important factor is if the end-user is sitting on WLAN or LAN. If you have your wireless access point in one part of the building and jumping back and forth between different access points, this will represent packet loss so no matter how much improvements you do on the backend solution it will never solve the problem. Also for HTML5 based access the browser has a lot to say when it comes to performance. Another forgotten aspect in DNS, sure it is only required for the initial connection, but since WVD uses DNS proximity if you come from the wrong point, the DNS request will forward the connection to the wrong endpoint. Then we have the Azure edge, ensure you having your solution running in the closest datacenter as possible (This is a good indicator on where your closest WVD frontend /control plane is running https://azure.microsoft.com/en-us/services/virtual-desktop/assessment/ ) It is however important to research if the required hardware is available in your current region you plan to do the deployment. For instance NVIDIA/AMD based GPU instances are only available in certain regions, example here –> https://azure.microsoft.com/nb-no/global-infrastructure/services/?regions=non-regional,norway-east,norway-west,europe-west,europe-north&products=virtual-machines
In terms of traffic flow for Windows Virtual Desktop.
1: DNS Request to the WVD service, which will be served trough Azure Front Door. Azure Front door uses Anycast, which means that traffic to the WVD service is routed to the closest Azure datacenter regardless of where the service is running.
2: Traffic is established trough the Gateway and session is brokered trough the Connection Broker.
3: The session hosts which have the WVD agent installed using a reverse TCP connect session back to the control plane and is listening for active sessions, will get notified of a new connection depending on host pool and application group and will start routing the traffic from the data plane.
4: User will get a connection established which will be proxied trough the data plane, but routed to the closest datacenter using Azure Front Door with Anycast.
The only issue with the current implementation that using this architecture it can only rely on a TCP based session. Which means that traffic flows trough reliable connection with TCP. Which when pushing audio/video content or applications which require constant changing of pixels on the screen a bit more poor experience compared to UDP. If you are looking in the direct on which the next generation of HTTP protocol is taking us with HTTP/3 using QUIC as transport protocol which is providing a hybrid between reliable but reduced latency connections compared to TCP (Which hopefully WVD would be able to utilize soon)
Microsoft also introduced a new optimized traffic flow called Direct RDP (Was announced during Ignite 2020) which allows endpoints or clients to “buypass” the gateway for the RDP traffic, and provide direct RDP connections to the sessions hosts trough a secure connection. Which is essentially reusing VPN or Expressroute connections which the end client is connected to. Authentication will still be done trough The WVD control plane but traffic will go directly as long as the client can reach the session host directly trough its known networks.
This feature is still rolling out but I would advise against using this on traditional IPSEC VPN. Since this would doing TCP/UDP encapsulation over a VPN tunnel. Using ExpressRoute from existing infrastructure would allow you to use TCP/UDP connection to your session hosts but still use the Windows Virtual Desktop components for authentication and session handling.
However now with the majority of the workforce working from home, this scenario will not apply. So my aim is that you can want to deploy a remote desktop / vdi service for users which require CAD based applications I recommend that you either use WVD with Direct RDP (When it is ready) and you work from workstations from the office, or that you invest into using VMware with Blast or Citrix and HDX protocol against Azure which both support direct gateway connections using their own optimized protocols.