The Event Log Query Utility

Have you ever started a script that you thought would be a piece of cake to write only to find it a hard nut to crack? When I started writing the Event Log Query Utility, I simply wanted to pull from computer event logs a list of errors and warnings occurring within a given number of days, insert those events in a Microsoft Excel spreadsheet, and send the spreadsheet to management.

Sounds pretty simple, right? Just create a list of computer names in a text file, read that file into an array, and using the Windows Management Instrumentation (WMI) Win32_NT LogEvent class, query each computer in the array for errors and warnings. Creating the script was pretty simple, and the automated event-log query tool sure beat the manual method I'd been using. Then, management realized it also needed a list of Audit Failure events from the Security log. "No problem," I thought. "I'll just add another OR condition to my query to include Audit Failure types."

However, there was a problem. Security events that I could clearly see in an event log weren't showing up in my Excel output. After some digging, I found that querying the Security event log is a Privileged Operation that requires a Security parameter when connecting to WMI. To include the Security parameter in your WMI moniker, you construct the moniker a little differently than you normally would. The Web-exclusive sidebar "Creating a WMI Moniker: Including the Security Parameter" (http://www.windowsitpro.com/windowsscripting, InstantDoc ID 93972) describes how to include the Security parameter.

With the Security moniker created, my script now worked as expected, returning the required Security Audit Failures and greatly reducing the amount of time it took to get server error-event information to management and auditors. I even found myself using the utility more in my daily work, particularly when trying to resolve server problems or tackling support calls. But for everyday work, I realized I needed something more flexible. I didn't want to modify a text file whenever I needed events from a different machine. I also wanted to be able to query for a wider range of event types, not just errors, warnings, and Security Audit Failures. The HTML Application (HTA) I describe here is the culmination of several months of fine-tuning and enhancements resulting from real-world troubleshooting experiences, support calls, and other problem-solving efforts. The grand finale is the added free-form query functionality, which lets me query virtually any condition I want to.

The Application
If you've ever provided user support, you know you might need to check for any number of event codes or event types when troubleshooting different problems. So I needed to make my event log query script more versatile. As I considered how to improve the utility, I found that even information-type events can be essential in exploring problems. Take a machine connecting at half duplex—an event that's generated as an information-type event on some systems. If you know all your machines are supposed to connect at full duplex and one isn't doing so, you've hit on a possibly significant piece of information. Some Application Popup events are also logged as informational events, even though when you look at the event description, the popup might indicate an application failure.

Figure 1, shows the Event Log Query Utility application screen. The upper section of the screen describes how to use the utility. Note that you can press F1 to get more detailed Help information. Under the information section is the first input box with a Browse button beside it. Here, you have three options for giving the application the list of computers you want to query: You can leave the input box blank to query the local machine, you can enter a computer name or an IP address to query just one machine, or you can browse to a text file that contains any number of computer names and/or IP addresses. The text file must have one entry per line consisting of either a computer name or a computer IP address. Keep in mind that this application uses Excel as its reporting mechanism, and Excel has a limit of a little more than 65,000 rows. So depending on what you're querying and how many days back you want to look, you might need to use a few computer lists and process each one separately.

The section in the middle of the application screen features seven radio buttons that let you specify the types of events you want to gather. Appropriately enough, Type is the name of the Win32_NTLogEvent property the script uses to query the various types of events. You can find five types of events within event logs: Error, Warning, Information, Security Audit Success, and Security Audit Failure. The application's radio buttons offer various combinations of these event types to gather, with the exception of the Security Audit Success event type. I hardly ever need to sift through those events, so I didn't include them in the categories. But don't worry; you can query for those events if you need to, as you'll see in a moment. All but the fifth and seventh radio button options are self-explanatory; I'll get back to these two exceptions shortly.

The input box just below the radio button section—Within the Last x Day(s)—lets you indicate how many days back you want to look into the event logs. For example, entering 1 day specifies that you want to look at the last 24 hours of events. The script converts the Day(s) value for comparison with the Win32_NTLogEvent timegenerated property, which records the date and time an event was generated. The script creates a query condition that looks for events that have a time-generated date-stamp greater than the number of Day(s) back you specify.

Now, let's go back to the fifth and seventh radio button options, which work in conjunction with the last large input box near the bottom of the application screen. The name for this Textbox is EventCodesAndFreeForm, and this multipurpose input box takes on different functionality depending on which radio button you select.

Selecting the fifth radio button, List Just Codes Below, lets you enter Event ID numbers into the multipurpose input area so that you can query the event logs for just those event codes. Event IDs are typically listed as event numbers when you look at an event through the Event Viewer GUI. System Event ID 6005, for instance, is the Event ID associated with the event log service starting. Note, however, that what you see as an Event ID in the GUI is actually called an EventCode in the Win32_NTLogEvent class properties. If you choose to enter Event IDs in the multipurpose input box, they must be numeric and you must separate multiple Event IDs with commas.

Selecting the seventh radio button, Free Form, lets you provide the conditional syntax for the Win32_ NTLogEvent WMI query's WHERE clause in the multipurpose input box. You can specify the simplest of conditions to very complicated ones, as the following examples show.

• For a simple Free Form query to list only Security Audit Successes, you would enter Eventtype=4.
• To use wildcards to look for events with a SourceName starting with MS, you would enter sourcename like 'Ms%'.
• To use wildcards to return any event that has an s as the second character of the Sourcename, you would enter sourcename like '_s%'.
• For a more complicated condition that looks for Application Popup events, you would enter Sourcename='Application Popup' AND eventcode=26.
• To query for events that contain the word fail, you would enter a query such as message like '%fail%'.

   Previous  [1]  2  3  Next