Remote access in real life
Lessons from the front line
SaaS data loss: The problem you didn’t know you had
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.
Next page: VNC
COMMENTS
Um ...
Not if the problem is configuring things like Active Directory, Exchange, Group policy etc on a windows server it's not ... it's unclear to me when a gui has ever made a tricky job "harder"
Remote Xserver
If your purpose for remote access is to use the power and storage of a server somewhere, and you need to do things that make vnc shudder, e.g. video, 3D cad, there is something to be said for using a remote X server.
When you start the gui in linux, e.g. startx, the X server program starts, and grabs control of your screen. Other programs, such as your desktop, connect to the X server as clients, and tell it what to draw.
You can get an X server for MS windows, such as Xming[1]. Just run this program on your computer, and connect to the remote server through SSH (nice and secure...).
Now, client programs running on your remote server can dial into the Xserver on your local laptop and show thier displays just like they were running localy.
But, they use the resources of the remote server - they are truly thin client. Rendering, file storage, processor usage when you compile, all stay on the remote box.
This can be really cool if you want to run a nice GUI like eclipse on a spare blade, with all the toolchains set up, storage on the SAN, and a nice big proccessor, while still getting advanced features like decent dual monitor support, that you don't get using VNC for the job.
It also can play videos and display 3D renderings as long as they are using X for output...
[1]http://www.straightrunning.com/XmingNotes/
@Arkasha
The slowness issues are related to Vista and later. They do not occur all the time, only under some very specific circumstances. (Usually older routers, older copies of ISA server, etc.)
As to the RDPClip issue, here is the skinny:
In my usage scenario, I RDP from my home into a virtual machine at home. That work virtual machine is RDPed into, at any given time, about 30 different systems. Each of those systems may be RDPed into 5 or 6 of their own.
If I were to copy something large, (say a screenshot @1920x1200,) or a large quantity of text, then I could not copy anything else, (say another screenshot) until that clipboard information had propagated through the “web” of inter-connected RDP sessions. (Which in my case can be over 200 sessions spanning 30 WAN links.) If you do so, (say by hitting “print screen twice in rapid succession,) you risk “corrupting” the rdpclip service on an edge session. That “corruption” can spread to neighbours until you have to restart rdpclip on the whole array.
Most often however, it is simply a single corrupt RDPCLIP on an edge system that you must restart. If you are RDPed into a system with a “corrupt” RDP clip, then clipboard services may not work for all computers in the RDP chain. (Or they may work for some segments or “arms” of the RDP chain, but not others.)
I hope that information helps!

IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring