Remote access in real life
Lessons from the front line
Blog In order to have a meaningful discussion about the specifics of remote access software, we need to get a few concepts out of the way, and some terminology nailed down. The first concept that needs to be dealt with is that of “sessions”. A session is the interface you see on the screen when you log in: your background, your applications available to you, your bookmarks and shortcuts and all other things that make your desktop yours. When you sit down in front of your computer and log into it, you are accessing the “console session”.
Some operating systems such as Windows XP, Vista or 7 only have one session; if you log in using remote access software you will take control of that single session. By default, in Windows Server, Linux, or Unix you will not be remoting into the console session, but creating (or attaching to) a completely separate one.
Whether or not remote access to the console session is desirable depends on what you plan to do while you are remoted into that computer. Some applications are “terminal services aware,” and absolutely refuse to be accessed from anything other than a console session. (Typically, these are very expensive industry specific applications; this awareness is one method by which they attempt to prevent companies from simply buying one copy of their application and putting it on a system that multiple people could use remotely.)
In other cases console session access is desirable because you wish to leave documents or applications open that can later be accessed by someone physically sitting in front of that computer. The other bit of terminology that is important to bear in mind is the difference between “client” and “server”. Since you can remotely access operating systems (such as Windows 7) that are not typically considered “server” operating systems, it becomes critical to clarify that any computer you are remotely accessing is “the server”, and the computer you are accessing it from is “the client”. With that out of the way, let’s look at some of the technical details of three example of remote access software - namely RDP, VNC and Teamviewer.
RDP on Linux
As my canonical example of RDP working on Linux I chose xrdp on CentOS 5. From my understanding of how it works, xrdp is essentially an RDP wrapper around a VNC server. It “translates” RDP into something the VNC server can work with and vice versa.
Installation was a breeze; xrdp was available in the EPEL repository. A quick “yum install xrdp,” start the service and suddenly I could use the remote desktop client in Windows to access my Linux server. If you are looking for a lot of features, you won’t find them with xrdp. It is a speedy replacement for VNC, but isn’t close to as full featured as the RDP implementation in Windows.
Be prepared to have alternate ways of moving files and print jobs from your local computer to the target system, and you can forget about multimedia. That said, xrdp is very fast, much faster than using VNC to access the same system. Sadly, it should be mentioned that no amount of tinkering ever managed to convince it to give me access to the console session.
RDP on Windows
The implementation of RDP that ships with Windows isn’t one that offers much configurability or customization. You get what featuresets are given to you, and you can either enable them or disable them. My goal then was to get the maximum possible performance from RDP. I ended up with this list of things to consider:
1) Both receive window auto-tuning in Vista and higher as well as features in the Scalable Networking Pack in Server 2003 and higher can really turn RDP into soup. If this is something you are experiencing, there is hope. Disable all of these features, and turn them back on one at a time to find out which (if any) are slowing down your remote access.
In Server 2003 or higher, check out the hotfix here.
In Vista or higher, try:
netsh int ip set global taskoffload=disabled netsh int tcp set global rss=disabled netsh int tcp set global chimney=disabled netsh int tcp set global autotuninglevel=highlyrestricted (alternately netsh int tcp set global autotuninglevel=disabled)
2) Prior to Vista, increasing colour depth had a huge impact on the speed and bandwidth consumption of RDP. 15-bit to 16-bit colour was a noticeable difference. 24-bit colour required both processing and bandwidth that until recently home users didn’t even have. Post Vista, I think you’ll find that you can run it at 32-bit colour depth over a piece of wet string and it will run just as fast as 15-bit did under XP.
3) If you poke around in the “experience” tab in the windows RDP client, enabling just about anything in there will make your remote windows session prettier, but slower. The exception to this is bitmap caching. For performance reasons, never disable bitmap caching in your RDP client; it’s the one thing in there that can give you a huge performance boost.
4) Another oddity of Windows RDP is my good friend rdpclip. Clipboard pass-through in RDP can leave a lot to be desired, most especially if you are the kind of person to remote into multiple systems simultaneously. From time to time, rdpclip can become “corrupt,” and you need to stop and restart it. To do this, open up task manager, find rdpclip under processes and end it. Then go file, run and type in rdpclip. Suddenly you can copy and paste between your local and remote computer once more.
As a highly popular open source application that has existed for over a decade, VNC exists in many variants. To go truly in depth about how to tweak or configure every version of VNC would take far more than a single article. Instead I will address generalities that apply to most versions of VNC that you are likely to encounter.
The most important thing to consider about VNC is security. While VNC can be used to start a new session, far and away its most popular use is to share a GUI between the person sitting at the computer and someone remote accessing it. In many versions, the default configuration of VNC only asks for a simple password before sharing your desktop with whoever happens to be asking. There are no password complexity requirements and you don’t need to know a username.
In almost every incarnation, VNC comes preconfigured to allow someone to remote into the system without first asking permission of the user currently using it. There are plug-ins and extensions for most maintained variants of VNC that can and do address almost any security concern you could raise, but these are not default items.
When considering VNC as the remote access solution to your problems, take your bandwidth and CPU speed into consideration. Most VNC variants are designed to ensure that you get some form of connection, regardless of bandwidth. The trade-off is generally one of server-side cpu for bandwidth.
If you are using VNC over a LAN, I heartily recommend turning off any and all compression. Uncompressed or RAW VNC will provide the fastest and best experience, but at the cost of a fair amount of bandwidth. Make sure VNC hooks into the OS properly.
VNC can work in two ways: as a video driver on your system, or by “scraping” the existing video driver for display information. As you might suspect, “scraping the screen” is a very slow way to go about things. In Linux, most distributions can and do offer versions of VNC that integrate tightly with X11. These can provide near RDP speeds, though they are often a pain to configure. If you are looking at using VNC on Linux for more than just casual administration, I would seriously consider taking the time to configure a properly X11 integrated variant. The same holds true in Windows; most modern Windows VNC variants offer a “mirror driver” or “hook dll.” These install as video drivers in windows and are the only way to make VNC under windows anything other than frustratingly painful.
Another item that can apply to quite a few VNC implementations is that sometimes your mouse cursor can disappear. This often happens when you are using a VNC client version that doesn’t quite speak the same language as that on the server. In this case there will be an option in the client somewhere to let the server control the cursor. Once you tick that, the mouse will seem choppy and laggy, but you will at least be able to see it.
In general, Teamviewer does exactly what it says on the tin. There is obviously a lot of testing and development going into this product, and this polish is reflected in the stability and reliability of the application. That said, there are quite a few small design elements that have tripped me up over time.
Teamviewer has a “quick support” version, essentially a self-contained executable that users can download, give you the GUID and password and you then can remote into their systems. One of the issues with this, (especially if you are used to using Teamviewer in Host Mode) is that you can’t minimise it into the system tray. If you bring up the application from the taskbar when you are already connected, there is only one button: the one that shuts down the app and boots you out. If you happen to be slamming around the system trying to get things done quickly, a small bit of clickitis on your part easily leads to an embarrassing phone call to the user asking them to fire up the app again.
Another feature that “works as intended,” but upon which I have stumbled numerous times is that of remotely rebooting your host. The issues that surface are again ones of habit and clickitis. Teamviewer (even the “quick support” version) offers you the ability to reboot your target into either safe mode or normal mode. Teamviewer will start itself and be ready for you to connect when the system comes back up. This only works if you use the menu in the Teamviewer client on your side to reboot the target system, not the target operating system’s native restart button.
In addition, if you have more than one support individual connected to the target, Teamviewer will helpfully inform the other support member that you have requested a reboot. If they hit “no” then neither of you can initiate a reboot request until the Teamviewer server is closed and restarted.
As always with any product, I heartily recommend taking the time to do research and lab testing before full deployment. It is vital to get to know not only the bugs and incompatibilities, but the security risks and UI idiosyncrasies that are posed by a product simply “working as designed”. ®