My home office set-up includes a pair of 27″ Dell monitors (2707 WFPs) on my primary production desktop. I say this by way of explaining why one of my favorite working techniques is to stay logged into that machine, and to use Remote Desktop Connection (and the RDP protocol) to reach out from that desktop to other machines I want to work on here and there around the house. In particular, I’ve got 2 Windows 8 test machines that I work on quite regularly — a Lenovo X220 Tablet with an i7-2640M and 12 GB of RAM, and a home-built desktop with an Asus P8Z68V-PRO GEN3 mobo, an i7 2660K CPU, and 32 GB of RAM — where my preference is to remote into those machines and work on them.
But alas, that doesn’t always work, because not all applications are 100% (or even a little bit) compatible with RDP. And figuring out what’s compatible and what’s not can be interesting, too. Until some time in 2011, Microsoft offered a free tool called the RDS Application Compatibility Checker. But in 2011 they handed off this functionality to a Dell-owned software company formerly known as Quest Software, whose ChangeBASE product includes a variety of tools, including automated application compatibility testing that incorporates a variety of remote access compatibility checks. I’ve launched inquiries to find out more about this capability, because I have to imagine that many IT professionals (and network/data center/virtualization admins) will want to know what’s safe to use with RDP and what’s not, particularly when it comes to custom applications of the mission critical variety, as well as any number of common desktop tools and utilities.
What spurred this blog post from me was the discovery, upon installing and learning to use StarDock Software’s ModernMix utility (which permits Modern UI apps to run in Windows on the Windows 8 desktop, instead of taking over the whole screen — or part of it, if you’re inclined to run multiple Modern UI apps in tandem) that it worked wonderfully when I was sitting at the real physical keyboard for those PCs, but not at the remote keyboard. The issue is that it uses the F10 function key to instruct the program to switch from filling the entire display to displaying inside a window, and function key presses are notoriously tricksy to transport across a remote link. However, after setting up one app in a desktop window, all other apps would then appear via remote access. Nevertheless, I had to make that happen at the real physical keyboard to enable the remote connection to work properly. Here’s a screencap of the Skydrive app running in a window, after the initial set-up was handled on the actual machine:
I have discovered other apps that are even less well-behaved when using remote access to my Windows 8 desktop. On the Lenovo machine for example, Lenovo System Update v5 works perfectly when run from the local keyboard; if you launch the program from a remote connection, nothing ever appears on the display to indicate that the program is running (nor does an application entry appear in Task Manager, either). The only way to get the program to work remotely is to fire it off before starting a remote session, after which it stays up and running in the remote window that Remote Desktop Connection opens to that machine. I assume the same conditions might hold for programs that operate on hardware at a low level, too: that’s why I’d be leery of trying a disk partitioning program through a remote connection, for example, or nervous about other, similar low-level hardware configuration or set-up tools.
All of this, of course, confirms the notion that testing of applications in a corporate environment must include checking them through a remote access window as well as on the local desktop. It will be even harder for help desk or tech support folks to get their jobs done if the tools they’d like to use don’t work that way: far better in fact, to find tools that are amenable to remote control and operation, to ensure that when those hard-working IT pros must reach out to a user’s desktop their chosen tools will work as needed and expected.