The Microsoft-managed control-plane is a completely redesigned infrastructure that leverages native Azure platform services to scale automatically.

  1. Azure front-door as a global load-balancer for the RDP connection
  2. Azure App Services in Azure for hosting the infrastructure services
  3. Azure SQL DB for hosting the RDS Brokering databases

Leveraging these services is the main reason why this service is so cost-effective, which is the purpose of the Cloud and what it’s built for!

WVD User connection Traffic Flow

Connecting from your virtual machine in Azure to your Host Pool (session hosts in Azure Infrastructure-As-a-Service) works differently with Windows Virtual Desktop. It uses Reverse Connect, which means that no inbound ports need to be opened on the VM to setup the RDP connection. Once the connection flow proceeds, bidirectional communication between your session hosts/host pool will go over port https (443). This port is almost always open from the inside to the outside, so it’s perfect for a remote connection to Windows Virtual Desktop!

Windows Virtual Desktop is a global load-balanced service via Azure front-door. This means that the traffic flow below always goes via the nearest management control-plane/service location – which you can see in the middle bucket below.

  1. User launches RD client which connects to Azure AD, Azure MFA, user signs in, and Azure AD returns token
  2. RD client presents token to Web Access, Broker queries DB to determine resources authorized for user
  3. User selects resource, RD client connects to Gateway
  4. Broker orchestrates connection from host agent to Gateway
  5. RDP traffic now flows between RD client and session host VM over connections 3 and 4

WVD service network access requirements

To make this traffic flow possible – you need to have at least firewall rules / NSGs / service tags in place for the following network addresses – otherwise WVD won’t work correctly. There’s also the option to use Azure Service Tags with all the URLs/Ports pre-configured and auto-updated for you – this could make your life a lot easier.

To connect from the client – endpoint location. The following network access is required to setup the session to the WVD service.

When you use an ExpressRoute with force-tunnelling to your local gateway, make sure to configure the routing tables correct, as described for KMS in this article. Within configuring this – your virtual machines won’t be able to communicate to our Azure KMS server. 


Notify of
1 Comment
Inline Feedbacks
View all comments

[…] Understand the WVD user connection Traffic flow and Network access requirements […]