As I’ve mentioned before, my primary role at my company is to develop form & web based applications. I prefer the speed of developing a form based application (i.e a windows application) over web apps, which I find can be slowed down by user interface issues. Debugging can also be harder in web apps and particularly so with the language I develop in; a java like, structured programming language but unfortunately not OO.
One place where web apps rule though is in trouble shooting and rolling out bug fixes. Because it’s a web site you can access it easily, to trouble shoot, and once a fix is made you simply roll it on the production system and Bob’s your uncle. This is from a hosted scenario (which is what we do).
But when it comes to form based applications, you just never know what a client is talking about when they call up for a support issue. Or perhaps you kind of know what they are saying but it makes no sense. It’s times like this that you need to be able to remote into your clients desktop and ‘see’ what it is they are talking about.
There are several tools for doing this and we use the majority of them: Microsoft Remote Desktop, Symantec pcAnywhere, VNC and even the odd Citrix client. The problem with these remote access apps is that they generally require a ‘host server’ application to be running on the end you wish to connect to, which needs to be configured and then their firewall might also need some configuration to forward certain ports etc. That’s fine for larger clients that have the necessary infrastructure in place, but some are just too small to do this or even know how to do this. Add to this the issue of dynamic IPs (so you never quite know what IP to connect to), software firewalls and general ‘user’ issues and it starts to get tricky and even annoying.
This is where TeamViewer, apparently developed by the same guys that made Tight VNC, comes into play. The host simply downloads an executable (TeamViewer Quick Support) that they run whenever a connection is to be made to them. No install, no wizards, no configuration, no nothing – just a single executable. The client, in this case me, then runs TeamViewer (which does need to be installed) and connects to the host. This is accomplished by entering in a ‘Partner ID’ code and then a ‘Session Password’ – both of these are supplied via the TeamViewer QS app. See this link for an example and the following screen shot (as seen by me):
Note: I’ve cleared certain information.
Ok, so far it’s pretty standard. But the beautiful part of it is this: no IPs, no firewall issues (it has it’s own ‘dyngate’ routing that bypasses firewall security somehow), file transfer ability, SSL security and a host interface so simple even my Gran would know how to use it. On top of this, it’s free! Yes, free… for the first 15 minutes (or 30 minutes if you register) of each connection and only for non-commerical usage. If you plan to use it commercially, you’ll have to giddy up some cash.
This little app really has been a time saver in helping us being able to ‘see’ our clients desktop without having to go through all the rigmarole of installing the above mentioned remoting tools.
So, if you have need for something similar – give TeamViewer a go, I think you’ll like it!
Update 24/07/2009: This post is over 3 years old and yet it still gets comments posted on it fairly regularly. It’s by far the most viewed post in this blog with an average of over 455 views a month for the past 3 years. Even though this blog is no longer active, I thought I should update it with regards to security concerns that have been raised in the comments. The update follows:
Teamviewer uses a “middle man” to enable it to bypass firewalls which saves the hassle of configuring your router/modem/firewall. Each side of a Teamviewer connection connects to this middle man, which is a Teamviewer server, and it handles the connection and routing of traffic between the two sides. The traffic is apparently encrypted, according to Teamviewers website, but any time you introduce a middle man, it raises potential security issues. If they are not encrypting the traffic, they could be snooping it etc. In the Trust No One world, this is not an ideal solution. So if security is a major concern for you, perhaps this is not the solution for you.
However, according to Teamviewer’s help manual, you can setup your own Teamviewer server. This means that everything is now routed through your own server (middle man) and you no longer need to worry about your traffic going through a third parties server. This is the best option if security is very important to you.
That said, I still feel that Teamviewer is one of the best free solutions for remote access and is fine for most instances. This post was originally posted from the view of offering support as thus this context needs to be taken into account.
People have also commented on Teamviewer taking over port 80 and not allowing Apache/IIS to use these ports. Stackoverflow has a post that apparently addresses this issue, check it here.