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%'.
Prev. page
[1]
2
3
next page 
