Magic Quadrant for Enterprise Backup/Recovery
VNC
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.
Teamviewer
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”. ®
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
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
Cloud based data management
Enabling efficient data center monitoring
