Customers who have invested in a virtual desktop infrastructure based on Windows 2008 may be reluctant to spend more money to upgrade their servers to Windows Server 2012. To make the sale, solutions providers need to demonstrate how the benefit of the upgrade outweighs the cost.
Virtual desktop infrastructure (VDI) deployments that are built on top of Windows Server use the Remote Desktop Services (RDS) tool. Microsoft has made a number of
Prior to the release of Windows Server 2012, RDS published virtual desktops and RemoteApps over the Internet using either HTTP or HTTPS. This required encapsulating the Remote Desktop Protocol (RDP) inside of Transmission Control Protocol (TCP) packets. The problem with this approach is that WAN connections and Internet-based connections often have a high latency and a high degree of packet loss (at least compared to a large area network connection). The latency and packet loss generally gets worse as the distance between hosts increases. But the TCP does not handle packet loss and latency very well, especially for applications that require real-time service such as a remote desktop session.
In Windows Server 2012, this problem has been addressed by making User Datagram Protocol (UDP) the default protocol for high-latency networks. This should make for a much improved experience for remote users. But client support for UDP is not required. If your customers have users that are using older RDP clients that do not support UDP, then the Remote Desktop Gateway will automatically sense the lack of UDP support and revert to using TCP instead.
More on Windows Server 2012 VDI
Remote desktop services in Windows Server 2012
Advising customers on VDI options
What's new in Windows Server 2012?
Introducing Microsoft Systems Center 2012 add-ons
Adding support for the UDP protocol isn't the only thing that Microsoft has done to improve the end-user experience. Another improvement is something that Microsoft refers to as Adaptive Network Auto Detect.
To see why this change is important, consider what happens when a user connects to a virtual desktop using the Windows 7 RDP client. The Windows 7 RDP interface is condensed by default, which means that most of the configuration options are hidden from view unless the user expands the window. If a user establishes a session without first specifying a connection speed, then Windows will assume that the user has a low-speed connection and will disable various visual elements such as the desktop background.
There is nothing stopping a user from expanding the interface and adjusting their connection speed. But if the user picks a connection speed that exceeds the bandwidth that the connection can actually deliver, then the user's experience will likely suffer because the connection is unable to keep up with the demands that are being placed upon it.
The Windows 8 client does things differently. The RDP client does not rely on the end user to select the correct connection speed. Instead, the client automatically senses the connection speed and enables the visual elements that are most appropriate for the amount of bandwidth that is available.
The best part of the Adaptive Network Auto Detect feature is the fact that the client continues to monitor the connection speed. We have all seen connections that start out reasonably fast, but eventually slow to a crawl as conditions on the network change. The Windows 8 RDP client can sense such a change and dynamically adapts the session to deal with the sudden decrease in available bandwidth.
The fact that Windows 8 and Windows Server 2012 offer features to make remote desktop sessions more reliable might be enticing to some of your customers. It is important to point out, however, that the Windows Server 2012 RDS offers much more than just connectivity improvements. Customers may also benefit from features such as multitouch support, single sign-on and even USB redirection.
Finally, Microsoft has also added support for Kerberos authentication to the Remote Desktop Gateway. Not only does adding Kerberos support help to simplify the configuration process, but it also opens the door for organizations to use smart card authentication for remote clients.
About the author: Brien M. Posey, MCSE, is a six-time recipient of Microsoft's Most Valuable Professional award for his work with Exchange Server, Windows Server, Internet Information Services, file systems and storage. Posey has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, he has written for TechTarget, Microsoft, MSD2D, Relevant Technologies and other technology companies. You can visit his website at www.brienposey.com.
This was first published in October 2012