The more precise the conditions in your Free Form query, the fewer unwanted
records your output will contain. And the more you use this utility, the better
you'll get at writing your Free Form queries. You might consider saving your
more complicated queries to a text file or Microsoft OneNote so that you don't
have to rekey them. You could even expand this HTA's capabilities to include
another drop-down list or text box that contains your most commonly used Free
Form queries.
At the bottom of the application screen, you'll find the RunScript button,
the Exit button, and a hyperlink to the Win32_NTLogEvent Class reference. This
link takes you to the Web page that features the Win32_NTLog-Event property
definitions. You might want to review this page to familiarize yourself with
the Win32_NTLogEvent Class's various properties and definitions.
Inside the Script
I can't walk through the lengthy Event-LogQuery.hta script line for line (you
can download the complete application at InstantDoc ID 93973), but let's look
at the key code sections. To use the Event Log Query Utility, you supply a list
of computer names whose event logs you want to check, specify the events you
want to look for, select the number of days to look back at, and press RunScript.
When you press RunScript, the script's main subroutine, getevents, moves the
HTA application window out of sight, in effect minimizing the application window.
HTA windows can be distracting and rather ugly if your main process takes a
while to complete. You can't move them, you can't see anything behind them,
and they don't refresh until the main process is complete. Because you might
be querying large numbers of computers, you don't want to deal with this annoyance
during processing. When processing completes, the application window is immediately
moved back on screen.
After hiding the application, the script sets up a couple of initialization
variables and stores the user-supplied computer list input in a variable called
srvrlist. The code uses the initialization variables, evnts_exist and do_once,
as flags or toggles throughout the script to determine whether to launch Excel.
If there were no events or errors to report, I didn't want an empty spreadsheet
staring at me. So if the program encounters an error connecting to a computer
or a query returns a collection of events, the code sets the evnts_exist flag
to true. The script uses the do_once flag or toggle to determine whether an
instance of Excel has been created either because there's an error to report
or because there are events to report.
The script then creates a reference to a starting point in time. You will query
event logs for events that have a timegenerated date greater than a given number
of days back from this reference point. If you want to look back three days,
the reference point will be 72 hours before the time you press the RunScript
button. Note that the script uses a fair amount of string manipulation to convert
this simple number entry into a format equivalent to the Win32_NTLogEvent timegenerated
property's format. A timegenerated property value looks like 20060915182038.703000-240,
which maps to yyyymmddhhmmss.milisec timezonebias.
The script creates a starting-point datetime stamp by querying the local-datetime
property from the Win32 _OperatingSystem class and storing the value in a variable
called vdate. This timestamp value is in the same format as a timegenerated
value, making the coding a little easier. To produce a value that represents
the numbers of days back you want to look at, the code begins by subtracting
the number of days back from the current year and storing that value in a variable
(vyear). Next, the code subtracts the number of days back from the current month,
storing the value in another variable (vmonth), then subtracts the number of
days back from the current day and stores that value in yet another variable
(vday). The script concatenates these three variables (vyear, vmonth, and vday)
into a string variable and replaces the first eight characters of the starting
datetime stamp variable vdate with the concatenated string, leaving the rest
of the datetime stamp string untouched. So if you want to look back three days
and the original vdate value is 20070101183038.000000-240, the conversion changes
the vdate value to 20061229183038.000000-240. By querying the event logs for
a timegenerated date greater than vdate, you can report on just the events generated
within the last 72 hours.
The script then determines which computers to query. As I mentioned earlier,
you have several ways to indicate which computers' event logs you want to query.
The code beginning at Section 1 first checks to see if the input contains a
period, which would indicate that the entry is a filename, an IP address, or
a nonexistent file. To determine whether the entry is a file, the script uses
the FileExists property of the Scripting.FileSystemObject class. If the file
exists, the script opens it, reads the entire file into an array called Servers,
and exits the main conditional checking section. If the file doesn't exist,
the script checks to see whether the input is an IP address. The code turns
the input into an array by using the Split function with a period (.) as the
designated delimiter. Then, using the Ubound function, the script checks the
array to determine whether it contains just three elements. If the array does
contain three elements, the script checks to see if all the elements are numeric;
if so, the script assumes the input is an IP address and inserts the value into
the Servers array. If the input contains a period but doesn't meet either of
these conditional checks, the script delivers a "File Not Found" message, returns
to the application screen, and awaits user input.
If the entry doesn't contain a period and the input box is blank, the script
fills the Servers array with a single element containing the name of the local
computer. If the entry isn't blank and doesn't contain a period, the script
considers the entry a computer name and inserts the computer name into the Servers
array.
Next, the script moves into its main loop, which Listing
1 shows, and cycles through the array of computer names. (Note that the
script checks for blank entries and discards any it finds.) At callout A in
Listing 1, the script attempts
to connect to WMI on the remote computer by using the security-level moniker
discussed in the Web-exclusive sidebar "Creating a WMI Moniker: Including the
Security Parameter." If this line of code raises an error, the computer probably
doesn't exist or is inaccessible. At this point, the script creates an instance
of Excel if it hasn't already been created and writes the error to the spreadsheet,
indicating which computer was inaccessible. The script cycles back to the beginning
of the For Next loop and retrieves the next computer name in the array (if there
are more) and goes through the cycle again.
If there are no errors, at callout B the script checks whether any additional
event codes have been specified. If there are additional codes, the script inserts
them into an array (weeding out anything non-numeric) and builds a variable
called mcodes, which contains a piece of the query's WHERE clause that's used
later to query the event logs. For example, if a user enters 26,34 in the multipurpose
input box to search for those event codes, the script constructs the mcode variable
that contains the string EventCode=26 or EventCode=34. Note that the only time
the script won't execute this section of code is when the user selects the Free
Form radio button, which indicates that the user used the multipurpose input
box for a user-supplied query and not additional event codes.
Register
