One of the things that impressed me when I went to my first Windows NT training class back in the early 1990s was the system's event logs. I thought it was great that so much detailed system information could be easily found within the logs; however, I wished that the Event Viewer was a little more robust. Unfortunately, the Event Log Viewer has changed little in the past decade, despite the fact that NT has gone through various upgrades.
Sure, you can save, clear, and even export the log data in Event Viewer, but Windows doesn’t really offer an easy way to search or print the Event Viewer information. This is where the Windows 2000 Event Log Query Tool (Elogdmp.exe) comes in.
The Windows 2000 Event Log Query Tool is a command line tool for extracting the contents of the event logs. This tool is included in the Windows 2000 Server Resource Kit. Once you have installed the Resource Kit, you can find the Event Log Query Tool in the \Program Files\Resource Kit folder under the file name Elogdmp.exe.
The Event Log Query Tool extracts all of the information contained within the specified event log. You can extract event log information from either the local computer or from a remote machine. The extracted information is presented in a comma-delimited file.
Why would you use the Event Log Query Tool?
Before I show you how to use the Event Log Query Tool, I want to answer an obvious question. If you go into the Event Log Viewer and right-click on a log, the resulting context menu provides you with an option to export the log files. After choosing this option, you are given the option of exporting the information to either a tab-delimited or a comma-delimited text file. The question is, why on earth should you go through the trouble of using a text-based tool from the resource kit to export log file information, when you can export the exact same information directly from the Event Log Viewer much more easily?
The reason for using the Event Log Query Tool is that because the tool is command line based, it means that you can call the tool from a batch file or other script. This means that you can easily create an automated script that extracts the event log information, then searches for a particular condition, and then acts on that condition.
For example, several years ago I worked as the CIO for a chain of hospitals. At that time, the corporate headquarters was running a database that had to be stopped prior to the nightly backup and then restarted after the backup completed. Any time that the backup was stopped or started, it wrote an event to the application log.
With the Event Log Query Tool, it would have been easy to write a batch file that tells the database to stop and then exports the application log to a file. You could then create another batch file that examines the extracted file to check for the presence of an event corresponding to the database shutdown. The query could be constructed in such a way that, if the event were found, it would run the backup job. On the other hand, you could also structure the script so that if the event is not found, you could issue the shutdown command one more time. The scripts could keep looping until the database shutdown is confirmed. Since backup jobs are usually scheduled, you could use the AT command to schedule the command to run the initial script at a predetermined time.
Once the backup was complete, you could export the event log one more time and use a script to check for a successful backup. If the backup was successful, you could issue the command to restart the database. You could then export the event logs one more time and check to make sure that the database had restarted. If the database didn’t restart successfully, you could have the script loop so that it reissues the database start command.
As you can see, this type of operation can make the Event Log Query Tool extremely useful. While you probably don’t have a database like the one that I described above, with a little imagination and some scripting knowledge, you can put this tool to all sorts of excellent uses.
Before you send me an e-mail about the complexities involved in creating such scripts, let me just say that there are a lot of applications out there that can examine the event logs for you and launch processes based on event log entries. My favorite of these applications is something called OpalisRobot (for more on this product, check out this article). The problem is that OpalisRobot costs about $1200 per server, while the Event Log Query Tool is included with the Windows 2000 Server Resource Kit. As you can see, if you take the initiative to develop the scripts yourself, you can save a fortune.
Using the Event Log Query Tool
Using The Event Log Query Tool is quite simple. The syntax is as follows:
elogdmp server_name log_name
The server name is the name assigned to the Windows 2000 server or workstation that you want to extract the logs from. Keep in mind that you must have administrative privileges to the server that you specify. When specifying the log name, you must type "application," "security," or "system." Therefore, if you wanted to dump the system log from a server named "BART," you would enter:
elogdmp bart system
When you run the Event Log Query Tool, the event logs are displayed on the screen in a comma-delimited format. However, viewing the logs on the screen is almost painful to the eyes. Everything appears jumbled together. A better solution is to create a CSV (Comma Separated Value) file from the data. To do this, enter the elogdmp command followed by the >filename.csv option. For example, if you wanted to create a CSV file called log.csv from the system log on BART, you’d enter the following command:
elogdmp bart system >log.csv
In case you are wondering, CSV files can be opened in Microsoft Excel. You can then use Excel to search or sort the data. It is also common to create scripts that read CSV files.
As you can see, there are times when it is advantageous to extract information from the Windows event logs and put the data into text files that can be searched and scripted. I have shown how the Event Log Query Tool can do these tasks, and I explained how to work with its basic command options.