The Minority Report

I have stated before that I use RDP on a daily basis. I basically like RDP now, but I used to hate it. I liked that VNC was an actual take over of the real screen of the target computer. It was easier to use and there weren’t any gotcha stuff like installing software with registry keys and stuff. Now I know that RDP /console is a much better way to go and I do that now.

I like that RDP is baked into every Windows machine that I use and need to use. That is terribly convenient and useful.

So I keep an eye on the developments in the RDP world and stumbled upon this article today. Top 10 RDP Protocol Misconceptions – Part 1. Not to nit pick but RDP Protocol is redundant…is redundant…Remote Desktop Protocol Protocol. I’m sure that Nadim Abdo is kicking himself today but whatever. I’m just busting balls.

I’m going to list the headings of the top 10 RDP misconceptions but I’ll leave as an exercise to the read to go visit the site and check them out. Enlightening.

My name is Nadim Abdo and I’m the development manager responsible for the Remote Desktop Protocol (RDP).

Since we first shipped RDP in 1998 with Windows NT Terminal Services Edition we’ve gotten lot of very useful feedback on RDP (please keep it coming!). But we’ve also heard a lot of ‘interesting’ myths and misconceptions about RDP and its performance. So I thought why not try to bust some of those myths.

This post will at times get technical for those inclined to those details but I’ll also try to share some useful tidbits that end-users can apply to get an even better RDP experience.Terminal Services Team Blog : Top 10 RDP Protocol Misconceptions – Part 1

1) Myth: RDP is pretty slow because it has to scrape the screen and can only send giant bitmaps

This is a common misconception. While many alternative protocols are principally screen scrapers, RDP uses sophisticated techniques to get much better performance than can be obtained with a simple screen scraping approach.

2) Myth: RDP uses a lot of bandwidth

This is a good question and the answer probably lies in the fact that RDP does not use a constant amount of bandwidth; it actually tries to reduce bandwidth usage to 0 when nothing is changing on the screen. Bandwidth consumption only goes up in proportion to what is changing on screen. For instance, if you just run a line of business app with basic graphics and not much animation you may end up sending just a few Kbps of bandwidth down the wire. Of course if you start running animation-heavy applications or graphics your bandwidth usage will go up to support that scenario.

3) Myth: I can’t get the same rich experience I get locally when working over RDP

This is also a misconception. RDP provides a scalable remoting experience. By default it cuts down on rich effects in the desktop and application experience in order to preserve bandwidth and save on server load (e.g. CPU, memory). However, if you want the highest end user experience it is possible to turn on many rich effects and display enhancements such as:

…

The key to enabling many of these effects is to run the Remote Desktop client, click Options, and then click the Experience tab. Here you can select and enable many high-end features. Note that in some cases your admin might have controlled access to these features with server-side group policies.

4) Myth: RDP can’t be tuned to get better performance

TIP: One of my favorite such settings is the ability to set policy on the server to optimize RDP compression. This can give you a boost of as much as 60% bandwidth improvement over previous versions of RDP. The tradeoff here is that you’d be consuming more server resources (such as memory and possibly CPU) to achieve that bandwidth reduction.

Administrative Templates\Windows Components\Terminal Services\Terminal Server\Remote Session Environment\“Set compression algorithm for RDP data”

5) Myth: Using lower color depths — e.g. 8bpp — gives the best end user experience

In general I’d recommend attempting to run your scenario at 32bpp and measuring the resulting bandwidth to see if it’s acceptable for your scenario. It will usually give the best visual experience and in several cases will consume only a small percentage more data than 16bpp.
Terminal Services Team Blog : Top 10 RDP Protocol Misconceptions – Part 1

I definitely saw something in that article, item 4, that I am going to be implementing on my servers to increase my RDP performance.

Here is a link to the RDP Performance Whitepaper.