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 …
GUIs on servers
A solution waiting to find a problem.
How to make a tricky job harder.
How to spunk memory and CPU up the wall for no practical reason.
I hate GUIs on servers. I much prefer a nice lean system with just SSH access and maybe an X server running on my laptop if I need to use the odd X application.
Not sure why Trevor was having problems with RDP on Windows being slow though. I regularly used to RDP in to both WinXP and Win2k3 machines from several thousand miles away in a previous job and never had a problem. I'd turn off the theme option because that *would* slow down the connection (but then it slowed down XP on the console too :)
I also never had a problem with rdclip getting corrupted with multiple RDP sessions open. Even when I RDP'd from my laptop to a server, then RDP'd from there to another server, then from there to yet another one. Always worked flawlessly.
In fact, I've always found RDP to be much faster than VNC or remote X applications, especially over low bandwidth links. VNC I find to be like running through treacle. Plus my router at home doesn't play nice with VNC and disconnects you randomly.
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"
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!
Does Crossloop or Logmein etc not get a mention ?
Sorry, RSW. Teamviewer was used as my canonical example of "paid-for remote access software." When I tested them out, (and there are many!) they all seemed to be more or less the same. Minor variations on features, but speed, stability, etc. were about the same.
As you would notice in my first article, I chose Teamviewer only because the CTO of my day job bought us four licences at work. As such, I have been using it for months, and felt I was better qualified to comment on it’s features than the other commercial offerings.
At the suggestion of several commenters, however, I have started tinkering with other commercial remote access applications if for no other reason than to become more familiar with them.
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. 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...