Recently in Event Log Category

Now that EventSentry v2.91 has been released, I'm happy to have the opportunity to blog about our monitoring solution again.

The most significant new feature in EventSentry is the Health Matrix, a new way to see your network status in a space-efficient way. In fact, you can see the overall health status of your entire network on a single screen, even if it consists of hundreds of hosts.

We also made numerous other changes throughout the web reports, and added some exciting new filtering capabilities with our event log filters, as well as improved speed with the event log engine and file checksum generations.

EventSentry v2.91 also includes many minor improvements throughout the application, including service monitoring, process tracking and more. We have also updated EventSentry Light, and a new version will be released in the coming days after we have completed testing.

But now to the new features in version 2.91:

Health Matrix
In the health matrix, each host is displayed as a colored square, circle or rectangle, with the color indicating the overall health of the monitored computer. When all of the monitored components of a host are in an OK status, the color of the square is green. The color will change to orange or red when a problem is detected, depending on the number or severity of the issue.

The health matrix is highly customizable, for example both the size and shape of the icons can be adjusted depending on the size of the network (and your monitor).

Event Log Monitoring
In 2.91, the event log filtering engine was improved, resulting in reduced CPU usage of the event log monitoring component. Since the CPU usage of the EventSentry agent is already quite low, you will most likely only notice this improvement on hosts that generate an extremely large number of events, such as domain controllers.

Also new is the ability to filter events based on insertion strings in addition to just filtering based on the event message text. This means that one can now match individual strings inside event messages against strings, numbers, file checksums and group memberships. If you are not familiar with the term "insertion string", then I highly recommend my previous post about event message files before you read on.

Consider the following hypothetical example: The environment-monitoring component of EventSentry logs event id 10908:

The temperature (78.21 degrees F) has fallen outside the configured range (60F to 76F).

which is defined as:

The temperature (%3 degrees %4) has fallen outside the configured range (%1%4 to %2%4).

This event obviously informs us, that the current temperature has exceeded a set limit. Now let's say that we wanted to get an email when the temperature exceeds the limit, but also send a page when the temperature exceeds 90 degrees.

The new filtering feature allows you to do just that, by using the numerical comparison functionality with insertion strings (of course you would also need to set the hour/day properties). Assuming that you already have a filter in place for regular email notifications, you would simply setup an additional include filter that would evaluate insertion string 3 (%3) and only match if the number is above 90. See the screen shot below for the example. The result is a filter that only matches when then the temperature exceeds 90 degrees.

2.91 also includes two more comparison options, file checksums and group membership. So, if an insertion string represents a filename (e.g. from a security event), then EventSentry can create a SHA checksum from the specified file and compare it with the value that you specified. Another example would be a security event that includes a username in an insertion string, in which case you could setup a filter that would only match if that user is a member of particular group you specify. Both examples are mostly applicable for security events, since those are most likely to contain either filenames or usernames.
Using file checksums, you can be notified whenever a user plays solitaire, even when the user renames the executable.

Simply create a checksum of the file first using shachecksum.exe (included in the free NTToolkit, make sure you account for different OS versions and platforms) and intercept the corresponding 4688 event.

Service Monitoring
Service Monitoring now collects the username as well as the executable of a service. These additional properties are available in the web reports and in events generated, for example when the username of a service changes.

Software Monitoring
Software monitoring has been overhauled in 2.91, and some limitations and bugs have been removed. On Vista, Win2k8 and later, Windows patches are now monitored and included in the software inventory. 64-bit software is now classified as such and searchable, and searching for installed Windows Updated patches has also been simplified.

SNMP Traps
EventSentry can now send version 2c and version 3 traps, previously only version 1 traps were sent by the agent. The SNMP trap daemon was originally set to be released as part of 2.91, but this feature has been pushed back to v2.92.

Web Reporting
We have made a number of improvements in the web reporting to make using our web-based interface easier:

•    Reports are now easily accessible from every page, in addition to the reports page.
•    The database usage page now shows the actual page name in addition to the table name.
•    The dashboard page has been overhauled
•    The network status page can be customized (performance counters & disks)

Miscellaneous Improvements

There have of course been other improvements across the board, such as:

•    Notes can now be applied to computers
•    AD-linked groups can be sorted, and authentication properties can be set globally
•    Hardware monitoring now includes the IP address of an interface
•    Process tracking can capture the command line of a process
•    Logon tracking includes group information
•    File checksum generation has been optimized and will now use fewer CPU resources (affects file monitoring and file access tracking)
•    The minimum database interval for environment monitoring has been reduced to 5 minutes from 15 minutes
•    Software uninstallation events now include the same information as software installation events

Route 66 was a US highway that connected Chicago with Los Angeles (or vice versa), with a total length of almost 2500 miles (for the rest of world using the metric system: almost 4000 km). It was established in 1926 and Nat King Cole first recorded the song "(Get Your Kicks On) Route 66" in 1946.

Completely unrelated to Route 66 of course is KiXtart, a free, free-format scripting language for Windows.

I first ran across KiXtart back in '99, when I was looking for a scripting language that I could use to write login scripts in a NT4 network. My goals back then were simple, and included the ability to map printers and shares depending on the user and/or group membership.

I was already familiar with Perl back then, and would have preferred to use that, if it wouldn't have been for the requirement to install Perl on every workstation. Things have changed since then of course, and installing Perl today on every workstation in your domain would be rather simple with GroupPolicy (ActivePerl provides a MSI).

Still, KiXtart is a surprisingly simple and flexible scripting language that will allow you to accomplish most anything (not only in regards to login scripts) with extremely little effort. KiXtart also supports Windows 9x clients, if you are in the unfortunate position to take advantage of that functionality.

So what can you do with KiXtart? Here is an overview:

• Read and/or write to the registry
  
  
• Manage the event log
  
  
• Add printer or network share connections
  
  
• Create shortcuts, program groups etc.
  
  
• Read and/or write from/to files
  
  
• Retrieve system information (memory, hostname, IP address, ...)
  
  
• Get group information
  
  
• And much more ...
  

There really is little you cannot do, and most tasks can be accomplished with as little as one or two lines of code. How about some practical examples of what you can do with KiXtart:

• Map the color laser printer to all members of the "Marketing" group at logon.

• Map a network share depending on the network location (e.g. IP address) of a user.

• Query registry values or log information to the event log.

• Add a shortcut or program group

• Change the wallpaper :-)

The KiXtart web site has the complete documentation for all commands and functions that are at your disposal, and you can download them in a variety of formats (I recommend the CHM format) from http://www.kixtart.org/?p=manual.

But that's all nothing but dry theory, so I will show you how to create a KiXtart script that accomplishes the following:

1. Creates a printer connection depending on the group membership of the user
2. Maps network shares depending on the group membership
3. Displays a warning message if the latest service pack is not installed
4. Maps another network share only if the user is in a certain IP network
5. Display a warning if the password is older than 180 days
   
   

1. Creating a printer connection

IF INGROUP("MARKETING")
        ? "Connecting to color laser ..."
        ADDPRINTERCONNECTION("\\PRINTSERVER\COLOR_LASER_1")
ENDIF

In this example we are taking advantage of two functions, INGROUP and ADDPRINTERCONNECTION. I think they are fairly self-explanatory. If the currently logged on user is in the MARKETING group, then a printer connection to \\PRINTSERVER\COLOR_LASER_1 will be established.

2. Mapping network shares

The same INGROUP feature can be used to add network connections as well, so here is how you can control connections to network shares based on group membership

;Map Home Directory
USE G: "\\FILESERVER\@USERID"

IF INGROUP("Marketing")
        USE I: "\\FILESERVER\Marketing"
ENDIF

IF INGROUP("SALES")
        USE J: "\\FILESERVER\Sales"
ENDIF

In this example I introduced macros (@USERID), another powerful feature of KiXtart. By default, pretty much any system property is available as a macro (macros always start with the @ symbol). @USERID contains the user name of the currently logged on user, but there are others, such as:

• @ProductType (OS type, e.g. "Windows Vista Ultimate"
• @Wksta (computer name)
• @LDomain (logon domain)
• @CSD (service pack information)
• @CPU (CPU information)
• @Address (MAC address of network adapter)
• @IPaddress0, @IPaddress1, ... @IPaddress3 (IP address of xth network adapter)
• @PWAge (password age)

Lines that contain comments in KiXtart start with a semi-colon.

3. Display a warning based on the service pack number

KiXtart also includes a variety of functions for handling strings. We can use the @CSD variable to get the service pack information:

? "Service Pack: " + @CSD

which will yield something similar to

Service Pack: Service Pack 1

In order to display a dynamic message, we can get the last character and evaluate it. So let's display a warning message if a user is running Vista with a service pack smaller than SP 2:

IF INSTR(@ProductType, "Vista") > 0
  IF RIGHT(@CSD, 1) < 2
    MESSAGEBOX("Important Message from your IT Department" + @CRLF + @CRLF + "Your computer is not running the latest service pack, and will be upgraded tomorrow automatically at 10am. The upgrade will take approximately 30 minutes, and you will not be able to use your computer at that time." + @CRLF + @CRLF + "Thank you for your understanding.", "Service Pack Installation", 48)
  ENDIF
ENDIF

The INSTR() function checks whether a string appears inside another string, and the LEFT() function retrieves the specified number of characters from the beginning of a string.

4. Map a network share depending on the IP address

Let's imagine that we have a network share with lots of really large files (e.g. corporate training videos and more) and that we only want to map this share if a user is in the headquarter, opposed to a satellite location which has a slow access speed.

IF LEFT(@IPADDRESS0, 11) = " 10. 10.  0"
         USE Z: "\\FILESERVER\TrainingVideos"
ENDIF

Now the network share is only mapped if the user is in the 10.10.0.0/24 subnet. You can also use the EnumIPInfo() if you need to get more information from the network adapter.

5. Display a warning if a password is old

Most networks require users to change their passwords on a regular basis, but wouldn't it be nice if we could give our users a one-time warning before they are faced with the inevitable prompt that requires them to change their password?

$PasswordWarningThreshold = 170

IF @PWAge = $PasswordWarningThreshold
   MESSAGEBOX("Your password is " + $PasswordWarningThreshold + " days old and will have to be changed in 10 days. Please think of a really good password in the meantime.", "Password Expiration", 64)
ENDIF

In this example I also introduced variables, which are specified with the dollar sign. These are simplified examples, and there is a lot more you can do. For example, using the registry functions, you can save user responses and previous alerts in the registry, and later read them again.


So, forget multiple logon scripts or batch scripts using "NET USE" commands. With KiXtart, you can have one central login script that can adjust dynamically to the user, location, operating system or even the computer itself.

Database servers store massive amounts of data, often including sensitive information. It is not uncommon for there to be databases holding millions of rows of data, where a small subset of rows are considered critical or sensitive. This could be anything from a Social Security number to an EventSentry entry of a security event. Being notified when existing data in your database changes is crucial for log data, and can be accomplished by using triggers with Microsoft SQL Server.

For those of you not familiar with triggers, a database trigger executes code in response to events on a table or database. Triggers are essentially hooks into a table, and they usually execute SQL statements as a response to another SQL statement.

Since we love the windows event log, we'll take advantage of SQL Server's ability for triggers to log an event to the event log when a row in a table is modified. This allows us to not only log that activity, but also get notified immediately when suspicious or important activity occurs in the EventSentry database.

In EventSentry, we have a table named ESEventlogMain that stores Windows event information. This table constantly gets new data inserted into it, and it often gets purged as well to manage the size of the database. However, there is no reason this data should ever be modified. If it is, then we know that something is amiss and we want to trigger an event in the event log. It is also useful to know what account made that change.

The first step is to create the message in SQL. You can use this SQL statement to create it:

     sp_addmessage 80000, 10, 'Data Integrity Alert: %s', @with_log = TRUE

The first argument is a unique SQL server message ID that should be 50001 or higher, you can delete it again using sp_dropmessage. The number 10 is the severity level, but you can read more about the different options for sp_addmessage here.

Now we create the trigger that will use this message:

CREATE TRIGGER Trigger_ESEventlogMain_Modified ON
ESEventlogMain
FOR UPDATE
AS

IF UPDATE(eventmessage) OR UPDATE(eventid) OR UPDATE(eventtime) OR UPDATE(eventcomputer)
BEGIN

     DECLARE @Msg VARCHAR(8000)
     DECLARE @EventNumber INT
     DECLARE @EventID INT
     DECLARE @Computer VARCHAR(255)
     DECLARE @EventMessageOld VARCHAR(8000)
     DECLARE @EventMessageNew VARCHAR(8000)

     SET @EventNumber = (SELECT eventnumber from deleted)
     SET @EventID = (SELECT eventid from deleted)
     SET @Computer = (SELECT A.eventcomputer from ESEventlogComputer as A, deleted as B WHERE A.id = B.eventcomputer)
     SET @EventMessageOld = (SELECT eventmessage from deleted)
     SET @EventMessageNew = (SELECT eventmessage from inserted)

     SET @Msg = 'ESEventlogMain modified by ' + CONVERT(VARCHAR(20), USER_NAME(USER_ID())) + ' at ' + CONVERT(VARCHAR(20), GETDATE()) + '. Computer: ' + @Computer + ', Event ID: ' + CONVERT(VARCHAR(8), @EventID) + ', Event Number: ' + CONVERT(VARCHAR(16), @EventNumber) + ', EventMessage (old) =' + @EventMessageOld + ', EventMessage (new) = ' + @EventMessageNew

     RAISERROR( 80000, 10, 1, @Msg)
END

This creates a trigger which will generate an event when the eventmessage column in the ESEventlogMain table is modified. You can remove the "IF UPDATE(eventmessage) ..." clause (as well as the BEGIN & END statements) if you want to be notified of any changes to that table, this might however create some noise since acknowledging events will also perform an UPDATE on this table.

FYI: "deleted" and "inserted" are keywords that refer to either the old record that was updated (=deleted) or the new data (=inserted).

As you can see from the screen shot above, the message text from a logoff event was renamed to "Trigger Test". So now that the event is in the event log, we can set up a filter in EventSentry to alert us: