We’ve been using TeamViewer here to remotely connect to clients for about 2 months now. To say we have been impressed is an understatement. The ease that we we can connect to a client’s machine and take over their session has enabled us to provide support services to clients we would otherwise had to have gone on site to help out.
As part of the TeamViewer package, we have a logon account which lists our “partner connections”, i.e. a list of our clients computers, aliasing their respective “partner ID’s”. The partner ID is a “permanent” ID number which is assigned to your computer by TeamViewer’s servers, (which I believe it is only permanent in the sense it creates a registry entry to remember your ID number). This allows us to connect to the same machine over and over again without messing about trying to find out the client’s IP address and getting their username and password to otherwise connect via Remote Desktop or something similar.
In addition to being able to service individual clients, we have been able to roll out the TeamViewer app via group policy to entire workgroups. It also enables us to have “one click” access to our client’s servers via the TeamViewer host application.
This is where the fun starts. We had an interesting call this morning from a client who had advised that their iPhone was no longer syncing with their Exchange server. I connected up to their server, and low and behold, the Default Website had been stopped. I thought this was a bit odd, but have seen similar cases recently as a result of Windows Updates.
Upon closer inspection, this was a little more sinister. Trying to start the service resulted in IIS telling me to find something better to do. I ran a “quick” `netstat -a -b`, which overwhelmed the command line buffer… Changing this to something more suitable, I noticed something, peculiar…
TCP server:http server.domain.local:0 LISTENING 12464
Why was TeamViewer listening for HTTP requests??? How could we stop it, without stopping TeamViewer?
It turns out this was a problem for more then just a few people, but I gave up searching Google and looked instead in the Windows Registry.
I ended up making the following change, killing the TeamViewer host, and starting it again:
HKEY_LOCAL_MACHINE\Software\TeamViewer\Version4\ListenHTTP = 0
This seemed to fix everything, and I was able to start up IIS again. Hooray. Crisis averted 🙂