Is standard RDP 7 ready for everyday desktop replacement? I’m on a mission to find out!

I've been writing about remote display protocols for over six years now. In that time I've written about performance, user experience, bandwidth, and latency.

I’ve been writing about remote display protocols for over six years now. In that time I’ve written about performance, user experience, bandwidth, and latency. I’ve written about the importance of the display protocol in a desktop replacement environment, where real users will use the protocol every minute of every day. And of course I’ve played with all the various protocols in the lab.

But there’s one thing I’ve never done: I’ve never actually used a remote display protocol for my daily job, every minute of every day. Since joining TechTarget last November, I’ve started working in an office (my choice!) and using a real desktop computer. I still tend to travel a lot, but I would guess that I still spend probably 60-70% of my time working at this desk:



So now that RDP 7 is almost here, and now that people are talking about using remote display protocols to connect to desktops that will replace their local desktops, I figured I would “switch” to RDP for my every day primary computer to see what the experience is like. Is RDP good enough? Why or why not?

I intend to find out!

The hardware setup

For now I’m just testing the RDP protocol itself without any bandwidth constraints. Since I connect to the corporate LAN from my desktop via WiFi (don’t ask), I just plugged a Cat5 cable from the client to the unused wired NIC on the host directly, essentially creating a super-fast “RDP only” network. I manually configured TCP/IP with no DNS or anything for the wired network.

My hardware looks like this:

Remote host (the machine I’ve been using for months)

  • Intel E2200 (dual core 2.2GHz)
  • 4GB RAM
  • NVIDIA GeForce 9500 GT, PCI Express x16
  • Windows Experience Index of 5.3

Client device

  • AMD Phenom 8400 (triple core 2.1GHz)
  • 4GB RAM
  • ATI Radeon X1550, PCI Express x1 (!), dual displays
  • Windows Experience Index of 3.2 (This is due to the graphics card, since it’s x1 only. Actually I’m surprised that Aero glass runs at all!)

The software setup

Both desktops are running Windows 7 Ultimate build 7100. The remote host is the domain-joined desktop machine I’d been using for the past six months or so, so I didn’t need to make any changes to it other than enabling remote desktop and disabling the Windows firewall.

On the client side, I’m just running the built-in Remote Desktop Connection client software, manually connecting to the IP address of the remote host. Since I’m looking for the “full” desktop experience, I went through all of the connection properties tabs and enabled every single option. :)

The usage experience

When I login to the remote session, it correctly identifies both of my displays and uses them correctly. (By “correctly,” I mean the remote host recognizes there are two separate displays, so my task bar only shows up on one and I can identify and reorient each display as expected.)

Overall feel seems okay, although the “show contents while dragging” window effect exhibits some tearing and lag.

I also like the option that directs Windows key combinations (ALT+TAB, etc.) to the remote host when in full screen mode. That works with everything except for CTRL+ALT+DEL, which is fine since I can still CTRL+ALT+DEL + Enter to lock the client screen.

Client device throughput seems good also. I plugged in a USB drive which was recognized and automatically popped up in the remote session. Windows Explorer reported a 2.09 MB/second file copy rate when copying to the drive which worked out to about 5 minutes for 600MB or so. I don’t know if it’s a USB 1 or 2 drive, but I feel like that’s about what I’d expect natively.

In general everything seems usable and feels right, and after a few minutes I don’t even remember that I’m using a remote desktop save for the occasional “hiccup” when typing.

My running list of the “little things” that are missing / complex / not quite right

Remember that the main goal of my RDP use is to learn exactly what it can and can’t do in a desktop replacement scenario. To that end, I’m compiling a running list of the things that aren’t quite the same as local Windows. I’ll continuously update this list as I come across new challenges.

The problems so far:

1. No Aero glass with multiple displays.

The first thing I noticed was that my theme was configured back to the “Basic” theme and that Aero glass wasn’t working. While this isn’t a huge problem, I have to admit that I do miss the cool effects and the live preview and stuff. Plus I heard that it was supposed to work. (After all, I followed the instructions in this article to get glass working from 2008 R2-to-Win7, so I figure that Win7-to-Win7 should be a no-brainer.)

After poking around gpedit for awhile I finally gave up and re-read the 2008 R2 instructions. I worked my way through the troubleshooting notes until I came to Note #3: Aero Glass remoting is currently not supported with the new multimon feature in RDP 7.

Bummer. I emailed my contacts at Microsoft to find out if this limitation will be in the final product or whether it’s just a release candidate thing.

UPDATE: Microsoft confirmed this will be the case for Windows 7 / Server 2008 R2 RTM: Customers will have to choose Aero glass remoting or multi-display, but not both. :(

2. No insert notification of cards into SD slot.

I took the photo of my cubie for this article with a regular camera, and I popped out the SD card and stuck it into the slot in my monitor just like I always do. Except this time, the Picasa app didn’t come up to automatically start copying my photos. I played around with it a bit and realized that while I can access the client drives no problem, sticking media into them doesn’t trigger the autorun feature. (Although plugging in a new USB drive or inserting a DVD both do trigger autorun.) I also tried manually mapping a drive from the remote host to the \\tsclient share, but that didn’t help. (I did manage to crash explorer.exe on the client a few times while testing and playing with this, although I couldn’t do it consistently enough to figure out exactly what triggered it.)

Overall this is not a huge problem, and I just launched Picasa manually from the Start Menu. When I did I got this fun notification:


They’re right. It was uglier—almost like it was running in 16 color mode or something. I quickly exited and relaunched, clicking “No” to run in normal mode. Picasa ran fine and identified and copied the photos from my SD card no problem.

3. CardScan scanner doesn’t work (resolved partially)

I use one of those CardScan business card scanners that scans and OCRs cards and drops them into Outlook as contacts. I plugged it in like I always do, except this time the normally blue status LED was amber. :( I manually launched the CardScan software but an error told me no scanner was found. Then I broke out of the remote session to check the local client OS, and sure enough there was a dialog box indicating that an unrecognized device was inserted.

I dug out my CardScan disc and installed the driver onto my client computer. (The driver and application software were already installed on the remote host since that was previously my everyday desktop.) Now the CardScan LED turned from amber to blue and I heard the little gears turning. Hooray!

Unfortunately this was short-lived because the remote CardScan software still can’t find the local scanner. I actually just emailed Steve Saroff at RemoteScan to see if this is a situation they can help out with, because as it is now, this is a pretty big show stopper for me. So we’ll see what Steve says...

UPDATE: Steve was a big help and provided me with a copy of RemoteScan to try. You have to install a RemoteScan component on the workstation with the scanner attached as well as in the remote host. Then they communicate directly via IP (outside of RDP). Getting that installed was easy enough, and the workstation agent recognized the CardScan scanner as a WIA device no prob.

Unfortunately the CardScan software still didn't recognize the scanner. I emailed Steve again, and he explained that while RemoteScan can make scanners appear as "normal" devices (TWAIN, WIA, etc.), a lot of times the apps that come with scanners use private APIs and stuff to communicate with the scanner directly. And unfortunately that's what the CardScan software does.

As a workaround, I reconfigured the CardScan software to use a TWAIN scanner instead of the CardScan scanner, and the TWAIN option detected the CardScan device connected to the client via RemoteScan no problem. So now when I click "scan" in the CardScan app, the RemoteScan window comes up and I can scan and process cards that way.

So the solution technically works, although it's more cumbersome than before. With the CardScan scanner connected locally, I just stick a card in, the scanner wakes up, and then I feed the cards through as fast as I can. Now with the remote desktop, I have to launch the CardScan app, click "Scan," then click "scan" again in the RemoteScan window, which I have to repeat for each card. So it's more time-consuming, but better than nothing.

4. iPhone isn't recognized via iTunes (Day 1 update)

When I plug in my iPhone, the little bubble pops up saying that it recognized the "Apple iPhone" and that the drivers were installed successfully. Cool! And I can pull images from it via Picasa. Cool!

Unfortunately, it's only recognized as a USB storage device, and NOT a real iPhone. So iTunes doesn't see it at all, which means I can't sync up songs and content. Ordinarily it sits plugged in all day, downloading podcasts as they're available. Then I have stuff to listen to on the way home. But not anymore. :(

Next steps

I’m not sure how long I’ll use RDP 7—I guess until I hit a show-stopper or until it’s been long enough that I’m comfortable stamping it as “usable.” I might play with some network simulation tools to learn more about how RDP works over various network conditions, although that’s not really the point of my test. (I’m more interested in desktop replacement scenarios which will probably be LAN-based. WAN scenarios have a lot more to them, what with client hypervisors and local OSes and everything.)

Maybe once I’m done with RDP I can try out some other protocols, like ICA or RDP + Wyse TCX? The only protocol I don’t need to try is PC-over-IP, because I used it for a week when I tried out Teradici’s PC-over-IP protocol test kit with a Devon IT thin client. The “problem” was that PC-over-IP was so good there was really nothing to test! In other words I could have used it for a week, a month, or a year and I wouldn’t have even realized it!

So as I said, I’ll update this post as I learn more. Stay tuned...

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Shame on your Brian! Until you use ICA/RDP 24/7 for accessing remote desktop or terminal server, you cannot fully appreciate the problems with the environment. Yes, they are niggles, but niggles have a nasty habit of joining together to cause a big problem. This is why I'm still dubious about VDI because the pressure within our organisation to dump Citrix XenApp is purely because of these niggles you mention plus the fact that without a combo like HDX, the user experience will *always* be worse to some degree.

Cheers, Rob.


It would be helpful to clarify why you believe Desktop replacement will be LAN based? Do you really believe people who invest in Hosted Virtual Desktops will build local datacenters or have local Clouds, or never have their users travel? WAN is everything, if the protocol can't do that well, it's an extreme limitation. Try POoIP in the real world and see how you do.


/me beginning to wonder if I'm sleep-commenting under an alias since appdetective keeps posting pretty much everything I'm thinking.  Get out of my head dude! ;)


Shawn, it's good to know that real world torture is teaching us similar lessons :-)


Accessing UDP devices that require drivers, like scanners, can be a real pain.  This is why you have things like "virtual channels" in both RDP and ICA so that a vendor can install the driver remotely and "forward" whatever is needed to the app running on the server.  Your site also advertises a vendor that does a general solition for ICA, but it is pricey.

We eventually need this stuff baked into the protocols, eliminating the need for any driver on the client, in order to achieve mass deployment of VDI.


Re: LAN testing only, I guess then really that this is just a start. I still want to use RDP over the LAN for awhile, and then I can switch to a cloud desktop, and then I can try some other protocols.

My point for wanting to test RDP was simply to see how good it was in box.. so just sort of as the baseline.

Regarding desktop replacement being LAN only, I guess I should clarify that I mean desktop replacement with RDP as the protocol. I think there will probably be a lot of people who run desktops from the cloud, but I doubt many of them will do it via RDP. (Or maybe they will? Dunno.. we'll see how well this experiment goes I guess.)


Unless RDP 7 is available downlevel, it won't "take off" and won't be ready for everyday deployment. The RDP team isn't even clarifying if it's going to be available downlevel, is it?


Can you use a webcam, or perhaps a USB headset over RDP 7, if so how is the performance for this?  Would you want to use it for video teleconferencing?


Its nice to hear that you working as a typical SBC user for a while. Everyone in IT should do this from time to time, I try to work like this for a full week every six months or so. Only then do you really see the little things that berate thin-client users. Its easy to see why most users don't like thin-client computing as their primary application delivery method. Working from home or on the road? Its great but there's still a long way to go before it is truly a solution that is comparable with the traditional PC Client/Server set-up.