I’ve been writing and speaking a lot lately about the improvements found in version 8 of the Remote Desktop Protocol, which is used in Windows 8 and Windows Server 2012. Version 10 of RDP was just introduced in Windows 10, and it soon will be implemented in Windows Server 2016, adding some new enhancements over Version 8 which we’ll talk about soon. But back to the topic at hand…
UDP Transport in RDP 8 Boosts Throughput And Enhances User Experience
RDP version 8 is the first generation of the Remote Desktop Protocol that uses UDP alongside TCP for data transmission. Provided the RDP client supports RDP 8 (e.g. Windows 7 with RDP 8 Update, Windows 8, or Windows 10), the Windows 2012 RDSH server can transmit data using both UDP and TCP. This is a big deal, because UDP doesn’t suffer from TCP’s enforcement of its congestion-avoidance algorithm, so RDP 8 can push more data across the wire in a selected chunk of time via UDP (e.g. 2x to 8x more compared to TCP transport only), even over high latency links. Couple that with some nifty forward error correction techniques, and RDP 8 is able to boldly go into sketchy network conditions that previous versions would run screaming from.
But Watch Out For the Following Gotchas That Can Block UDP in RDP 8
Believe it or not, there are several common “gotchas” that can conspire against you to prevent UDP transport use with an RDP 8 or later Remote Desktop Connection. Let’s look at them in order:
Using a Windows Server 2008 Remote Desktop Gateway With Windows Server 2012 Remote Desktop Session Hosts
The Remote Desktop Gateway Role Service in Windows Server 2008 does not support UDP transport, so all connections via this legacy gateway will be forced to use TCP only. Not good. Make sure you upgrade your Windows 2008 server running the Remote Desktop Gateway Role Service to Windows Server 2012.
Forgetting to Explicitly Add an Endpoint For UDP in Windows Azure
This one is BIG if you are hosting your Remote Desktop Session Hosts in Windows Azure (or any other cloud service provider for that matter). By default, when you create a new Windows Server 2012 instance (with or without the RDSH role implemented), only the TCP endpoint for RDP will be created. See below:
You’ll need to go back behind any newly provisioned RDSH servers in Azure and remember to explicitly define a UDP endpoint for RDP like so:
Accidentally Disabling UDP Transport Via Server Side Group Policy Objects
One other potential problem is incorrectly setting the “RDP Transport Protocols” Group Policy setting, located under Computer Configuration, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Session Host, Connections. By default, both UDP and TCP will be used if the client supports it, but administrators can explicitly disable the use of UDP transport in this area.
So, there you have it. UDP transport in RDP 8 opens up so many possibilities in terms of user experience an overall Remote Desktop performance. However, you have to double check and make sure that it’s not being restricted right out of the gate.
Leave a Reply