TeamViewer really doesn’t work too well if your connecting to a remote client and you need to test out their VPN connection…
Trust me…
As soon as that VPN connection is established, you lose your TeamViewer connection and have to wait for the client to re-establish it’s connection, before you can reconnect.
Heck, if you really want to get annoyed, reconnect, then disconnect the VPN connection…
Good luck, and happy frustrations!!!
p.s. you need to close TeamViewer completely and run it up again after disconnecting from a VPN, it doesn’t appear to recognise that the VPN has been disconnected, so doesn’t bother to try updating it’s session data with the TeamViewer servers…. BOOOOOOO.
p.p.s. I’m not 100% sure if this only occurs using PPTP style VPN connections, if I recall correctly, it also occurred with a Cisco VPN client IPSec connection…
Checking through my stats, I’ve seen alot of hits from Google related to TeamViewer. I’m going to attempt to answer a few questions that I have seen results for, purely for traffic purposes 
Authenticating with Windows Username/Password
I actually had to use this last week, cause for some odd reason, the password we configured for our custom TeamViewer app wouldn’t work for this particular client… Odd…
Firstly, this only appears to be available on Windows – I tried doing this on my Mac TeamViewer client but it wouldn’t work… Booooo. Might just be an old version, I couldn’t be stuffed checking right now…
That said, on your Windows TeamViewer client, after entering the Client ID and connecting, click the “Advanced” button on the Authorization screen to bring up a bunch more options. You should now have a “Authentication” drop down box, with TeamViewer and Windows as your options. Selecting Windows gives you a familiar, “Username, Password, Domain” style screen. Simple. Enter the details and click Log On. You’re done!
Blocking TeamViewer Access
This is probably something I’d not ever want to touch, purely because I have clients I NEED to connect to, but I understand that some systems administrators might feel the need to block their employees from setting up TeamViewer on their machines for remote access purposes, or just to stop outside parties from soliciting internal users into starting TeamViewer sessions…
The first way I can think of to block TeamViewer access, is by using Local Security Policies, or Group Policies. There is a nasty little policy option that enables you to block an application from running, if it matches a certain filename – obviously, use this with care!
The option you want to look for is located in User Configuration -> Administrative Templates -> System -> Don’t run specified Windows applications.
Enable this policy, and simply add the TeamViewer executables (TeamViewer.exe, TeamViewer_Setup.exe, etc etc) to the “List of disallowed applications”.
Obviously, renaming the files is going to circumvent this… So moving on…
A quick NetStat on my Vista machine with the full TeamViewer client installed yielded the following result:
TCP 192.168.1.10:53039 server904:5938 ESTABLISHED
[TeamViewer.exe]
The answer is quite simple – block outgoing connections to TCP port 5938… This will stop the TeamViewer client from connecting back to TeamViewer’s central servers, which is necessary to generate the client ID, and to punch a hole through the firewall to allow people to connect in the first place.
You could probably set this on the local firewall, using Windows Firewall or perhaps by using your chosen centrally managed endpoint security package (Trend/Sophos/Symantec etc all have firewall options with their antivirus clients).
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 asu01:5938 asu01.ASU.local:0 LISTENING 12464
[TeamViewer.exe]
TCP server:http server.domain.local:0 LISTENING 12464
[TeamViewer.exe]
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
