Where to use Remote Access
Remotely accessing the GUI
The ability to remotely access computers has become a ubiquitous tool used by individuals ranging from systems administrators to roaming business users and the proverbial Aunt Tilly. This is not about accessing the hosted services of a computer (such as a webpage) remotely, but rather remotely accessing the graphical user interface (GUI). It is through the GUI that we access our documents, fire up our word processors, web browsers or downloaded movies.
From a teleworking standpoint remote access to your own computer’s GUI is the holy grail of usability. Everything is right where we left it, and barring a new Facebook layout or an application spontaneously growing a ribbon bar, it will appear and behave exactly the same every time. For user support, the ability to see what your users are seeing on their screen is an invaluable tool.
In my previous article I explored the capabilities of three forms of remote access software: RDP, VNC and Teamviewer. I have taken the time to test them to their limits and see how real world implementation lives up to the theory.
When I compare the options available to me, the one thing that I keep coming back to is how fast RDP is. Whatever programming voodoo under the hood causes it, with a half decent connection between you and your target, RDP is the next best thing to sitting in front of the remote computer itself.
As a teleworking application where you must access a computer remotely for hours on end it simply can’t be beat. RDP is stable, mature and when you are remotely connected to a computer for even a few minutes it is fairly easy which computer you are actually sitting in front of. So long as you have the drivers on both sides of the equation, printers map just fine across RDP sessions. Although data transfers are slow, you can make the drives of your local computer available to your remote target. With third-party enhancements, RDP can even pass decent multimedia.
While these praises for RDP are well earned is not without some significant drawbacks. The biggest criticism I can level at RDP is that it was not designed for support purposes. My qualification for a remote access application to be usable for support purposes is one that makes it easy for me to share a desktop with the user I need to support. When held up against either Teamviewer or VNC for ease of support, RDP fails. Microsoft has tried to make support via RDP easy with a tool called “Remote Assistance.” With remote assistance the user having trouble can initiate a support request via e-mail, or by passing a special file on to the support personnel by other means. There are situations where having the user initiate the support request is a good plan, but the entire process requires too many things to be working in the first place and has a tendency to confuse and frustrate users who are already on edge due to whatever issue triggered the call to you in the first place. In addition, remote assistance only exists on Windows systems. I’ve yet to discover a FreeNX or xrdp equivalent to it.
By comparison, VNC is absolutely fantastic at support. I have VNC installed on every system on my network and so long as I am within the corporate firewall it works like a charm. I can punch in the IP address or name of the computer I need to connect to, enter a password and I’m in. It just works; perhaps more to the point, it works absolutely everywhere. For every operating system with a GUI that you can conceive of, someone has ported VNC to it. I have VNCed into iPhones, Linux, OSX, and Windows in every flavor of the rainbow. I even have an IP KVM that uses VNC as the interface to all the computers connected to it.
If there is an argument to made that open source software is a good idea, it is VNC that I would hold up as my example. RDP is a protocol controlled almost entirely by Microsoft; RDP on Windows works Microsoft’s way, and there is no room for extension or debate. Much of what Microsoft has done to the RDP protocol has had to be reverse engineered, and as a consequence the open source implementations of it aren’t as feature rich as Microsoft’s own. To contrast, VNC has been open source for a very long time. It has evolved so much over time that it has speciated; different species of this application serve specific purposes, and there is a variant for almost any need you can imagine.
Of course, no application is perfect, and VNC has its Achilles heel. In the case of VNC that would be raw speed. With the right drivers, configurations, tweaks and selective breeding you can get a reasonably acceptable level of performance out of VNC. VNC is certainly enough to do support, light administration or in my case remote control my projector-attached HTPC and turn VLC on or off. It isn’t fast enough for most people to comfortably use it to telework for hours on end. The infinite choice and possibility it offers in how to connect to it is huge, but the lag and screen redraws become quickly frustrating.
This brings us to Teamviewer. Like RDP and VNC, Teamviewer is cross platform. There are servers and clients available for Windows, OSX and Linux. They even have an iPhone client app. For commercial remote access software this is fairly rare, and a welcome change. It is nice to see Linux support on a product like this.
Teamviewer is aimed directly at end-user support and short-term administration. It has found its niche, and it fills it well. The quick support version is easier to use than RDP’s Remote Assistance. Host mode will run Teamviewer as a service, and in every case where you need it for desktop sharing it replaces and completely outclasses VNC. To top it off, it works from behind more firewalls and NATs than either RDP or VNC can lay claim to.
In the eight months I have been using this application, I have only ever found one significant bug; host mode very seriously dislikes being used on systems with more than one session. On a system capable of multiple sessions, host mode will only every give you access to the console session, though in many cases it will simply crash out entirely as soon as a second session is activated on that system.
One thing I truly enjoy is how smoothly it alters things like colour depth, compression, etc. based on available resources. It isn’t remotely in the same league as RDP for speed or experience, but it beats the pants off of VNC when it comes to lag. While I will stop short of saying it would work reliably over carrier pigeon internet, I have had it work smoothly and reliably for me over thready dial-up where VNC absolutely refused. (RDP got caught in re-connect loops and had a little lie down.)
In the end there’s a place for each of these protocols. RDP is the gold standard for teleworking, while Teamviewer is the best option for desktop sharing and user support. VNC will work anywhere, making it an ideal backup remote access method, and something that can be relied upon to work on systems where neither RDP nor Teamviewer will. Having tested these applications in a myriad of circumstances, my next article will focus on tips and tricks and lessons learned.