Windows Virtual Desktop Rdp

What Microsoft has done with Windows Virtual Desktop is to abstract away these traditional Windows Virtual Desktop roles into “black box” web services that they control and maintain as part of Azure. As a result, all you are responsible for are the session hosts that serve up the apps/desktops into which your employees or customers connect. Windows Virtual Desktop is the only service that delivers simplified management, a multi-session Windows 10 experience, optimizations for Office 365 ProPlus, and support for Windows Server Remote Desktop Services (RDS) desktops and apps. With Windows Virtual Desktop, you can deploy and scale your Windows desktops and apps on Azure in minutes.

This is my take on RDP Shortpath for WVD. In this blogpost I will discuss the pro’s and cons of using this feature. Furthermore, I will talk about the configuration needed and the architecture involved. You can find the configuration below. I will first talk about the architecture and the pro’s and cons. I will then show how I configured this in my test environment.


Firstly, the architecture. This is architecture overview from the Microsoft Docs:

The architecture overview shows that it is now possible to connect to your WVD hostpools directly. You can do this is in a number of ways:

  • Public IP assignment to your sessionhost (not recommended)
  • Via Site to Site VPN
  • Via Point to Site VPN
  • Express Route

In addition, if you don’t use a solution based on the above this could result in worse performance then without RDP ShortPath.
Furthermore, it is worth noting that this is not a solution which creates a private endpoint for your VM’s. You still connect via the public endpoint for WVD in the microsoft cloud. When you log on using the Remote Desktop client detects that, if configured, that there a “ShortPath” available. Then the client switches over to the UDP connection. For example:

In addition, when the “ShortPath” is not available the Remote Desktop client automatically switches back to the public endpoint connection. This is the connection information for a normal connection:

You can see that the same gateway is used when connected via ShortPath and connected via the “normal” connection.

Pro’s & Cons

The pro’s of the solution are:

  • You are now able to fully control the connection to your WVD Sessionhost. Furthermore, you can apply QoS (Quality of Service) to the whole route to your sessionhosts.
  • There is more bandwidth available between the clients and the sessionhosts. This results in faster transfer times when copying files from and to the sessionhosts.
  • UDP is a protocol with less overhead, as a result, this could lead a much smoother experience for the end users.

The con’s of the solution are:

  • All the traffic now routes via the S2S VPN, Express Route or P2S VPN. This could lead to much higher costs. For example: You have Microsoft Teams offloading configured. Which offloads the rendering tasks for Microsoft Teams to the local clients. This takes about 1 Mbit/s of a bandwidth, this does not seem to be much… but if 500 users are doing this at the same time you could be looking at an upgrade for networking solution. This does not even take other applications in to account.
  • The Remote Desktop application decides whether Shortpath is being used or not. You can not control this. The application detects the best route and applies it if it thinks it is better.
  • RDP ShortPath is only available in the Remote Desktop Client.

Windows Virtual Desktop Rdp Properties


I have configured RDP ShortPath for WVD like this in my own testing environment:

The green connection represents the ShortPath connection and the red connection represents the normal connection via the public endpoint for WVD from Microsoft.

My “WVD Development” sessionhosts have RDP Shortpath configured and the “WVD Test” sessionhosts do not.
Configuring RDP ShortPath for WVD is fairly easy. Only the sessionhosts need to be configured. There is nothing to be done in the Azure Portal. Microsoft has provided scripts to implement this. You need to configure 2 things.

  1. Configure 2 registry keys. These enable UDP to be used for the Remote Desktop connection.
  2. After that you configure the Windows Defender Firewall on the session host to allow the 3390 UDP connection.

This is the script to configure the registry keys:

Windows Virtual Desktop Rdp
New-NetFirewallRule-DisplayName'Remote Desktop - Shortpath (UDP-In)'-Action Allow-Description'Inbound rule for the Remote Desktop service to allow RDP traffic. [UDP 3390]'-Group'@FirewallAPI.dll,-28752'-Name'RemoteDesktop-UserMode-In-Shortpath-UDP'-PolicyStore PersistentStore-Profile Domain,Private-Service TermService-Protocol udp-LocalPort3390-Program'%SystemRoot%system32svchost.exe'-Enabled:True

You can also configure this via Group Policy within Active Directory. I personally would put configuration like this in the WVD image so you don’t get a lot of overhead on the configuration. This is fairly easy to integrate in to your image creation process.

Virtual Desktop Windows 10 Download


Microsoft Doc about RDP ShortPath
More Posts about WVD and Azure DevOps:
Automated Bitlocker Encryption on your Session Hosts via Azure DevOps
OneDrive Machine Install Script