NTToolkit Update with three more utilities: CheckDB, CheckURL and NTPClient

We decided to release a new version of our free NTToolkit to which we added three useful new utilities and fixed a few minor bugs. You will find that some of these utilities can already be used in conjunction with the Application Scheduler feature of EventSentry, extending its monitoring capabilities to verify database connections, web pages and more.

1. CheckDB
CheckDB, as the name implies, checks a database connection through ODBC. This lets you not only verify that a database server is up, but can also check that a database is online and you can optionally run a SQL statement of your choice.

2. CheckURL
CheckURL is the HTTP version of CheckDB, and allows you to detect changes in web pages (through checksums) and looks for text inside web pages. With CheckURL you’ll know when a web page changes or when a particular string is or is not included in a page.

Both CheckDB and CheckURL can log output either to the console or the event log, making it easy to receive alerts from both utilities through EventSentry or any other log monitoring software for that matter.

The application scheduler feature of EventSentry can already log output from command-line utilities to the event log, even when those applications are not “event log aware”. This feature is extremely convenient for SysAdmins that run a lot of scheduled scripts, since the output from a script can immediately be sent to you – for example via email.

But back to the NTToolkit. The third new utility is NTPClient.

3. NTPClient
NTPClient retrieves the time from a NTP server and optionally adjusts the local time to match that of the server. NTPClient supports the NTP up to version 3 and takes network latency into consideration when setting the local time. Please note that NTPClient does not run as a service, and as such will have to be called repeatedly if you wish to keep the time of a computer synchronized.

EventSentry v2.90 will actually include a new System Health feature based on this utility and allow you to keep the local time of a monitored computer in sync.

As always, we hope the three new utilities will help you get your job done more easily.

We have more software releases planned for this summer. EventSentry 2.90 will be released in early July and we will also be releasing a new version of AutoAdministrator (2.0), in June/July with a completely re-designed interface and several new features. I will report more on that in late June prior to the release.

Event 4964: Special Groups Feature for Vista + Windows 2008 Entrepreneurs

There is certainly a lot of talk about the benefits of using Vista, but a lot of administrators and users seem to be avoiding it and instead hold on to Windows XP – which now appears to have a better reputation than ever! Well, here is a small reason to upgrade to Vista or Windows Server 2008.

Microsoft introduced a new event, 4964, called the Special Groups Feature. The purpose of this feature is to log event 4964 to the security event log when a member of a group you specify logs on to a computer.

So let’s say you want to know when a member of a local Administrator group logs on to a computer (and with EventSentry you could get an email when that happens for example), then you can accomplish that with the special groups feature.

In order to use this feature you need to do three things:

  • Determine the SID of the group(s) you want to monitor
  • Specify the SID(s) of the groups you want to monitor in a registry key
  • Ensure that you are auditing the Special Logon Feature (enabled by default)

One way to obtain the SID of a group is to use the getsid.exe tool which is part of the Windows XP SP2 Support Tools and other Microsoft Resource Kits. Note that the primary purpose of this tool is to compare the SID of two user accounts (so it requires you to specify two user/group accounts), but you can just enter the same group name twice to get around this. Here is an example output of the tool:

getsid \\mydc “Domain Admins” \\mydc “Domain Admins”

The SID for account BUILTIN\
Domain Admins matches account BUILTIN\Domain Admins
The SID for account BUILTIN\Domain Admins is S-1-5-21-9817441204-4587651373-9817264971-512
The SID for account BUILTIN\Domain Admins is S-1-5-21-9817441204-4587651373-9817264971-512

As you can see you need to point to tool to computer where the group exists, in our case I used a domain controller since I want to monitor if somebody from the Domain Admins group logs on to the computer. If you monitor a built-in group (e.g. Administrators) then you will see that the SID is much shorter and the same across all your computers.

Now that we know the SID, we can specify it in the registry. Navigate to key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Audit and create a new String with the name SpecialGroups.

The value for this new string will be the SID of the group you want to monitor, and you can separate multiple SIDs with a semicolon. For example:


You do not have to reboot after making this change, it is effective immediately with the first subsequent login. The event that is being logged will look similar to this (screen shot from the EventSentry Web Reports):

Special Groups Logon 4964 ScreenshotThe relevant information is shown in the lower part of the event in the New Logon section. Security ID shows the user that logged on, and Special Groups Assigned shows the group the account is a member of (of course this group has to be specified in the registry).

Voila. This feature probably makes most sense on critical servers, though I would recommend enabling it on all workstations as well since you probably want to know if a member of the local Administrators group logs on. But of course this also means that you need to be running Vista on your network :-).

Since this feature needs to be activated using the registry, you can use AutoAdministrator to push this registry change to multiple computers. AutoAdministrator has actually been rewritten from scratch and we will be releasing a new version 2.0 very soon.