More TeamViewer

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     server904:5938         ESTABLISHED

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).

Netgear GA311 driver install weirdness?

Today’s weird tech problem, I had to replace a network card in a client’s machine today. Simple, right? The card was a Netgear GA311, running a Realtek 8169 chipset. The chipset probably wouldn’t matter much, if I didn’t have so many bloody problems.

So I installed the hardware, and booted up into Windows XP. The card detected, I whacked in the CD, and let the Found New Hardware Wizard do it’s thing… Or die trying!

No matter what I tried, I continuously received the “Cannot find the specified file” error message. I did a search around and found numerous people having similar issues.

One such user on the Netgear forums posted that he manually copied the required driver files into the Windows\INF and Windows\System32\Drivers folders, but this had no effect on our install. Another user mentioned the Realtek drivers, which unfortunately, again, resulted in the same error.

I was quite annoyed at this time, ready to put my fist through the client’s touch screen LCD…

Then I found a tiny little registry hack courtesy of someone who had the patience to actually call Microsoft about it.

  1. Backup HKLM\System\CurrentControlSet\Control\Network
  2. Delete the “Config” key
  3. Reboot
  4. Reinstall drivers.

Hurrah! This worked a treat. Well sort of… I still had to install the Realtek drivers, the Netgear ones continued to error out… The Netgear drivers supplied on both the CD and on their website, both have a zero byte security catalogue file, which I suspect has something to do with it… Either way, I think I’ve seen similar issues with Netgear cards – from now on, I’ll be using Realtek drivers where there is one available, I simply don’t trust Netgear’s drivers anymore, especially considering they can’t bundle a working driver with hardware, or make one available on their website.

October 22nd!

Windows 7!!!!!!

I’ve been using Windows 7 for a few months now, albeit virtualised, on my Mac, but I’ve been quite impressed with it. Running on a mere 1GB of memory, virtualised, it’s “nice”.

Today I upgraded one of our client’s machines to 7, using a fresh clean install of Windows 7 Pro, from REAL media. It was quite something. 7 seemed to install in around 20 minutes or so, and I had to comment “WTF, this just isn’t Windows like at all”.

I’m yet to run Windows 7 as an all day everyday platform, I can’t wait to be honest, but don’t think my work machine will be getting an upgrade anytime soon 🙁 Given I use my Mac every other waking moment of the day, Windows 7 probably won’t see much life in my life besides what I’m subjected to by what my clients are using. I feel a little left out there…

I’ve also been looking in to the Windows Preinstallation Environment for Windows 7 (aka WinPE3.0), as I want to produce a “tech bench” disk we can use on our customer’s computers when they drop them in. Simple things like running Acronis TrueImage, and just being able to browse files on a drive, and edit the registry and run system restore tasks. We can get most of this functionality from the Ultimate Boot CD for Windows (UBCD4WIN) but I find it a little “clunky”, even though you can strip a lot out of it during the build stage.

Just another thing for my to do list 🙂

Mousey mousey!

I’m a Mac convert. I have been working with Windows since 2003, and was always the Windows guy blah blah blah. Until I started using Linux more and more for my previous job and reluctantly signing up for an iPhone, that is. So I bought a MacBook Pro about 3 months ago, and now I’m all about the Mac. They are the bomb diggidy. I love it. It rocks my socks.

Except for this one little problem… I love the MacBook’s trackpad, I really do, it’s bloody amazing… But occassionally I have the urge to use a REAL mouse (such as those epic moments where I want to run CounterStrike virtually using VMWare Fusion)…

Here’s the kicker. I love Microsoft mice. Therein lies a rather odd combination of hardware, a MacBook with a Microsoft mouse… One would think, that it’s just a regular mouse, and you can plug it in and away you go. Sure. You can do that… But… Not without a world of pain. Seriously, I totally turned off the idea of plugging in a mouse and using it, when I realised that I have to literally push the mouse from one side of the dinner table to the other, just to move across half the screen!!! The response to moving the mouse and what happens on screen is just ridiculous!!!

Until now… So I got fed up with it and decided to Google the issue. Low and behold, I’m not the only one. Turns out it’s a problem with Microsoft mice, and it can be fixed.

So I went off to Microsoft’s website, and headed to the mouse and keyboard section, and proceeded to download IntelliPoint for MacOSX 10.4-10.6 ( Installation was simple, just your normal next next next next… The restart.

After restarting, it didn’t seem to do anything. So I headed to System Preferences and noticed the Microsoft Mouse icon at the bottom. Under the Pointer Options tab, I ticked “IntelliPoint pointer speed” and wound it allllll the way up. Low and behold, my mouse is working like a REAL mouse again. Thank you Microsoft, I guess…

Exchange 2003 SMTP DATA command bug

This is an extract from a log file I’m looking at right now for an Exchange 2003 SMTP service… I sure as hell hope there’s just a patch missing, otherwise, this could be one NASTY bug. It appears as if the DATA section of the SMTP session has been escaped, possibly by inclusion of the escape sequence used by SMTP to exit the DATA block, thus tacking the rest of the email straight to the SMTP service for processing… Anyone who knows anything about SMTP should be able to see the implications of this… And hopefully, I’m not just making an ass of myself 😛

13:13:30 EHLO – 250
13:13:30 MAIL – 250
13:13:30 RCPT – 250
13:13:32 DATA – 250
13:13:32 so – 500
13:13:32 ——=_nextpart_000_0007_01ca4ccf.fc799c50 – 500
13:13:32 content-type: – 500
13:13:32 charset=”iso-8859-1″ – 500
13:13:32 content-transfer-encoding: – 500
13:13:32 <!doctype – 500
13:13:32 <html><head> – 500
13:13:32 <meta – 500
13:13:32 > – 500
13:13:32 <meta – 500
13:13:32 <style></style> – 500
13:13:32 </head> – 500
13:13:32 <body> – 500
13:13:32 <html> – 500
13:13:32 <head> – 500
13:13:32 <title></title> – 500
13:13:32 </head> – 500
13:13:32 <body – 500
13:13:32 “> – 500
13:13:32 <table – 500
13:13:32 <tr> – 500
13:13:32 <td> – 500
13:13:32 <center><a – 500
13:13:32 QUIT – 240

TeamViewer for Remote Support

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

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 🙂

Windows 2003 / 2008 event logging to Syslog

I stumbled on a seemingly unique requirement this week to log file access for a Windows network share. Of importance, was the logging of object deletions, and writes. For most Windows admins, this probably sounds like a simple task of setting up group policies or local security policies to audit object access, and the required auditing policies on the objects requiring this level of logging.

Okay, so you’ve setup your auditing, and it’s been logging for yay long. An SMB (say 50 users) I set this up for, managed to generate 1GB of logs in 24 hours, purely from setting object Write and Delete auditing on a network share. This leads to the reason for this article.

1GB of logs is a hell of a lot of data, and we all know the Windows Event Viewer is hardly capable of searching these logs quickly and easily. Furthermore, your security log is going to fill up really quick, and, depending on your policy, events will be over written, or the security log will be full, resulting in non-admin users effectively being locked out of their systems.

Further again, one month down the track, you are faced with the inability to trace who deleted that important management report…

I suspect there are probably numerous commercial packages available for analysis of event logs, and effective archiving of event logs. However, for the Windows admin with limited budget, and time constraints, we’re going to discuss my preferred method, using Syslog to centrally log events.

Syslog is a daemon which runs on Linux and UNIX machines. It is essentially the Windows equivalent of the Event Log service. Under CentOS5 (and most derivatives of Red Hat I would suspect), these logs are stored in `/var/log/`. These logs are archived, or ‘rotated’, by a Cron scheduled task which runs `logrotate`. Syslog also has the ability to receive log messages from other hosts, making it extremely nifty for centralisation of log data, and even more so, the ability to analyse the data contained within.

Continue reading “Windows 2003 / 2008 event logging to Syslog”