ashleyknowles.net

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

[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

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.