This article is more than 1 year old

The Remote Access arsenal

BOFH "killer feature"

Of all the tools in a system administrator’s arsenal, perhaps the most important are those related to remotely managing and administering the systems under their care. Just as computers span dozens of processor architectures and operating systems so to are the tools to manipulate these systems equally diverse. The rise of the graphical user interface (GUI) to become the primary method of interaction with modern computer systems has brought with it a requirement to administer these various systems remotely through their native GUIs.

Let us take a look then at the evolution of these tools, and where they sit today.

Almost a decade ago Windows XP hit the market and at the time it seemed little more than an incremental upgrade to Windows 2000. There wasn't a new server platform to accompany it, (the .net servers ended up delayed until 2003,) and the mystical longhorn was on the horizon. Many organisations took years to make the switch, and indeed there are some that still haven't. If you were around in the pre-SP2 days of XP, you will likely remember that XP had one killer feature that prompted corporations to make the jump to an operating system that came out only one year after 2000. I'm talking of course about the ability to "remote desktop" into all the copies of XP pro we had to manage. Sure, we all had VNC installed on our 2000 boxes…but RDP was less cranky, faster and was integrated into this newfangled OS to boot.

Since then applications providing remote GUI control have come and gone and more than a decade has passed since the use of these technologies for remote management, systems administration and teleworking went mainstream. It is time to review the state of this "killer feature" and so I am going to spend the next week picking apart three of the most common implementations.

RDP

Call it "Terminal Services" "Remote Desktop Services" or anything else you want, but the world knows it simply as "RDP." The Microsoft implementation of RDP can be found in versions of Windows ranging from NT 4 straight through to the latest and greatest. Back in the NT4 days Terminal Services was only provided in its own server edition and even today in Windows 7 Microsoft has chosen not to provide this feature to its "home edition" customers. Microsoft’s is not the only implementation however; it has also started to creep into other operating systems via projects such as FreeNX and xrdp.

RDP is fast, reliable, proven and even has an active ecosystem of companies that offer proprietary extensions to the protocol to speed up multimedia services or provide superior USB pass-through. (Wyse and Citrix spring immediately to mind.) RDP can pass audio, do file transfers pass through printers and (certain) USB devices unassisted. In Windows 7, RDP can accelerate Windows Media Player even without proprietary extensions.

Its greatest strength however is probably its ubiquity. It has been years since I have encountered a Linux system in which I couldn’t order up rdesktop from the package manager. On Windows anything XP or higher has an RDP client already installed. The server side of RDP can be found in both Windows and Linux, with both solutions being mature and speedy. RDP is absolutely everywhere, thus making it a natural consideration for any remote access projects.

VNC

VNC is a remote access application with so many forks and variants that testing and comparing them all is a significant project in its own right. In my particular case I have settled on UltraVNC as my default standard and (so long as I keep to my 1.0.2 installer) it has worked exceptionally well for me. VNC is a trusted old friend that works on every operating system I can think of, and has the advantage of allowing multiple people to remote in and share the same desktop space. It really comes in handy when I need to support computers in such a fashion that the user can see what exactly it is that I am doing. With Remote Assistance on Windows computers alternatives such as RDP can certainly provide this functionality, but VNC scores big points by making it easy.

Part of the ease of use behind VNC is what is now termed “traditional VNC authentication.” Fire up a VNC client, punch in the name or address of your target, enter a simple password and suddenly you are sharing the session of your user. Modern VNC variants offer more complex authentication methods, from active-directory integration to robust PKI implementations.

It is also possible to use VNC as a method of grabbing unique sessions rather than sharing them with another user. Given that VNC, even with the mirror drivers, is significantly slower than RDP I never saw the use of VNC as a method of remote accessing a unique session. Instead, VNC shines as a method to share a screen with a user, help them solve their problem all while they watch. Perhaps the best part is that unlike so many other remote access solutions it is open source and always will be.

Teamviewer

Teamviewer is a feature rich remote access application that has absolutely revolutionized support for me. It is one amongst many; a representative of a generation of similar competing remote access products which though free for personal use bear a commercial use price tag. Given this competitive landscape you may ask why I chose Teamviewer for my representative of commercial remote access applications. The truth of the matter is that the brass at my day job had already bought licenses for it before I ever really had a chance to pick apart competitive offerings. As such I not only got it for free, I’ve been using it every day for months now.

Unlike RDP or VNC, both of which are direct client-server apps, Teamviewer has a bit of a man-in-the-middle approach. When you launch the Teamviewer application, it sets up a session to the Teamviewer servers via HTTP. To connect to a given system, enter that system’s GUID and password. Voila: access to the system is provided via an HTTP tunnel bouncing off of the Teamviewer servers. Teamviewer’s website propaganda claims “If you use TeamViewer you don't have to worry about firewalls: TeamViewer will find a route to your partner.” I can’t dispute this; Teamviewer makes it through almost any firewall I’ve encountered. The rule of thumb seems to be that if you have a web browser that can find Google on the system you want to remote into, then Teamviewer will work.

A special mention should be made here of my favourite Teamviewer features; namely the self-contained executable and the ability to "switch sides." The self-contained executable means that you can have a user download the executable and run the application without installing it, (nor does the user need administrator privileges on their local system to do so.) Have the user launch the application, give you the GUID and the password and instantly you have access to their system. The ability to switch sides means that at the touch of a button on your end, that same user can now view (or interact with) your desktop. This turns Teamviewer from simply a remote management application to one I find myself increasingly making use of for presentations and training.

This past decade has seen remote access software evolve beyond simply providing keyboard, video and mouse access to a target computer. All have the ability to encrypt the communication between parties, as well as move files back and forth between the client and the server. VNC offers text chat, varied methods of handling individual windows or applications and plug-ins to help you circumvent NAT, or provide audio support. Teamviewer bears encryption, a VPN tunnel, text/VoIP/Video chat and the ability to reboot the server into safe mode and then reconnect to continue work. The newest versions of RDP offer up to 16 multiple monitors and with the right third-party extensions, absolutely unbelievable multimedia performance. (Thanks to the Wyse TCX Suite, I have watched 720p video from inside my XP VM from 800km away across a 20Mbit link.)

Each of these three applications sees use in my everyday life, but the evolution of features calls for some real testing. My next article will concern the implementation of these applications in the real world; exploring their features and exposing their limitations.

More about

TIP US OFF

Send us news


Other stories you might like