Writing Command Shell Script Status to the Application Event Log - 06 Nov 2000

Centralize management of your administrative scripts

Windows 2000 and Windows NT command shell scripts are great tools for automating repetitive administrative tasks. Scripts are easy to write and reliable, and you can use the AT scheduler or the Win2K Task Scheduler to schedule and run the scripts unattended. However, scripts are limited in the kinds of tasks they can perform. For instance, scripts have no built-in support for accessing the Registry or the event log. The inability to write to the event log can be particularly annoying for unattended scripts, which must record their run status information in standalone text files, which you need to manage separately from the event log.

You can get around this limitation by using the Logevent utility to tell your command shell scripts to record run status and error information in the Application event log. The Application log is a common repository for applications' status information. If you tell your scripts to write their status information to the Application log, you can have all your script and program status information in one place.

Logevent is in both the Microsoft Windows NT Server 4.0 Resource Kit and the Microsoft Windows 2000 Server Resource Kit. You can call Logevent from a batch file, and because the utility is a standalone executable binary file, it's convenient to use. You don't need to do anything special to install it—it doesn't need any Registry entries or DLLs. Just make sure that the command shell script can find the logevent.exe file.

Logevent's syntax is straightforward:

logevent [-m ] [-s ] [-c ][-r ""] [-e ] [-t ] ""

You use the —m option to specify the computer that will log the events. If you omit this switch, Logevent uses the local system. The —s option specifies the severity level of the events you want to record: You can choose S (success), I (information, the default value), W (warning), E (error), or F (failure). Use the —c option to specify the category number, which you can use to filter events in the NT Event Viewer. If you don't specify a value, Logevent assigns the category 0 (None). The —r option lets you supply a string (e.g., the application or script name) that identifies the source of the logged event. Logevent uses User Event if you omit this option. The —e option lets you assign an event ID, which is useful for filtering entries in the event log. You can use the —t option to set a timeout value for trying to write a log entry. By default, Logevent waits 60,000 seconds before giving up and exiting. The last parameter is a required string that Logevent will write as the event log's description. If you type only "logevent" to invoke the utility, Logevent displays a usage prompt.

Let's look at how to use Logevent. If I want to build a command shell script that needs to log its success or failure in the Application log, I would construct a script like this:

@ECHO OFF:: The first parameter must be GO@IF NOT "%1"=="GO" GOTO :LOGERROR:: Write the success eventlogevent -s S -r "Script Event" "Script completed."GOTO :EOF:LOGERROR:: Log the errorlogevent -s E -c 3 -r "Script Event" -e 99 "Script Failed! Invalid parameter"::EOF

This sample script tests its first parameter for the word GO. When the script finds a match, Logevent writes a success entry to the Application log that records the source as Script Event and the description as Script completed. Otherwise, the script executes the lines that follow the :LOGERROR tag and writes an error entry with a source of Script Event, an event ID of 99, and the description Script Failed! Invalid parameter.

Although Windows Script Host (WSH) and VBScript are Microsoft's preferred scripting technologies, nothing works quite like a batch file for doing things quickly and reliably. Logevent.exe is a useful utility for administrators to have in their tool belt. For more information about using the Logevent utility, see the Microsoft article "How to Use Logevent.exe to Log Events from a Batch File" (http://support.microsoft.com/support/kb/articles/q131/0/08.asp) or Chapter 14 of the Win2K resource kit.