Querying Event Logs

Microsoft® Windows® 2000 Scripting Guide

Although events are automatically recorded on a computer (except for security events, which must be enabled by using Group Policy), few administrators routinely analyze their event logs. This is due in part to the limitations inherent within Event Viewer and in part to the nature of how events are recorded throughout the enterprise. The impediments to routinely analyzing event logs include:

• The large number of events typically stored in an event log. Many of the events that take place on a computer are recorded to the event logs. The thousands of events recorded in the event logs on a domain controller make analysis extremely difficult.

• Inability to save filtered records to a separate file. Event Viewer allows you to filter a desired set of records but does not allow you to save just those records to a separate file. To analyze, graph, or otherwise work with a filtered set of records, you must export all the events from Event Viewer to a text file, open the file in another application, and then filter and save the events of interest.

• Lack of printing capabilities. Event Viewer provides no printing capabilities; records must be imported into another application before they can be printed.

• Inability to record events on remote computers or on multiple computers. Because events are recorded only on the computer where they occur, the only way to obtain enterprise-wide data has been to manually examine the event logs on every computer.

The WMI class Win32_NTLogEvent class can be used to extract records from an event log and either display the results of those queries or save them to a file. This enables you to automate the process of analyzing event logs by creating scripts that do such things as:

• Periodically return any instances of a particular event (for example, a failed logon or failed service).

• Run each morning and retrieve all the events that occurred on the previous day. These event records can then be copied into a database, where they can be easily sorted, filtered, analyzed, and printed.

Several key event properties that can be returned using WMI are shown in Table 12.4.

Table 12.4 Event Properties in WMI

Designing Event Log Queries

The way an event log query is constructed can have a huge impact on how long it takes WMI to process the query and return the requested information. This is not necessarily true of other managed objects. For example, a query that returns all the properties for all the installed services on a typical Windows 2000-based computer takes about 2 seconds to complete. A filtered query that returns the properties of a single service takes about 1 second to complete, a difference of only 1 second.

However, query times for different types of event log queries can vary widely. The relative query times for several different types of event log queries run on a Windows 2000 Server-based test computer are listed in Table 12.5. The test computer had a total of 13,743 events recorded in its event logs, with 669 of these in the System event log. Retrieving all the events from all the event logs required over 2 hours to complete. When the query was modified so that it retrieved events from only the System event log, the process took just 4 minutes.

Table 12.5 Relative Event Log Query Times

Event log queries can also return a very large amount of information compared with queries for other WMI classes, such as Win32_Service. Retrieving the properties for all the services on the test computer and saving them to a text file resulted in a file that was less than 13 KB. Performing the same task with the event logs resulted in a text file of nearly 1 MB. Attempting to retrieve events from large event logs over the network could cause a script to take hours to run and might generate a huge amount of network traffic.

Because of the length of time it can take an event log query to run and the large amount of information that can be returned, it is important that you carefully design your queries for retrieving data from the event logs. Unless you need to return all the events from all the event logs on a computer, write your queries so that they do one or more of the following:

• Specify a single event log. If events are recorded in only one event log, there is no need to search the other logs for these records. For example, computer startup and shutdown events are recorded only in the System event log. If you are querying for these records, there is no reason to search the Application or DNS event logs.

• Return only a subset of events. When analyzing event logs, you rarely need to examine every event. The vast majority of records in a typical event log report the success of a particular operation. If you are interested only in operations that failed, there is no reason to examine hundreds of records that report operations that succeeded. Instead, you can focus on a subset of events: those records reporting an operation that failed.

• Return only events that occurred on a particular day. For most computers, this kind of query returns only a few hundred records, compared with thousands of records stored in a large event log. If you need to view only the event records for last Tuesday, construct your query so that only the records from that day are returned.

• Asynchronouly return event records. If a dataset is large, asynchronous queries will usually run faster than semi-synchronous queries.

• Copy events to a database. Unlike databases, event logs are not optimized for data retrieval and analysis. If you need to perform a number of queries on your event logs, or if you need to combine events from multiple event logs, you should copy those events to a database and then use the database and its tools to analyze the records. In addition to the speed differential, databases typically provide more sophisticated tools for analyzing data and calculating statistics than do event logs.