Tools for Exchange administrators

Among the dozens of helpful Exchange Server 5.5 utilities in the Microsoft BackOffice Resource Kit (BORK) are the Event Log tools: Event Log Filter (elf.exe) and Event Scan (evtscan.exe). According to the tools' documentation, you can use these utilities to monitor events on more than one server; filter events based on service, type, and ID; alert a computer or user through email when specified events occur; and restart or stop a service.

Event Log Filter is a useful tracking tool that lets you, through a short series of commands, see the status of as many servers as you want to see. However, I found Event Scan somewhat less useful because it looks for specific events rather than services, and it monitors only the Application log. Also, the BORK's Exchange 5.5 version of evtscan.exe might not function properly on Windows 2000 servers. (When I tried out the tool on my Win2K Advanced Server machine with Service Pack 1—SP1, the executable ran but never found the event that I told it to look for.)

You can install the Event Log tools in one of two ways. The tools install automatically when you install the BORK. Or you can copy only the necessary files (i.e., elf.exe, elf.mdb, evt.cfg, and evtscan.exe) from the BORK CD-ROM's platform\exchange\admin directory to a directory on a computer that's running the services you want to monitor. Because Event Scan uses email to alert you about the events you're monitoring, you must install the tool on a computer that supports Messaging API (MAPI)—either an Exchange 5.5 server or an Exchange client system.

Using Event Log Filter
Suppose you have an Exchange organization with 15 servers spread across three countries. Event Log Filter can give you, within 15 minutes, either a Microsoft Excel spreadsheet or a Microsoft Access database that shows you which servers are receiving errors and the errors' descriptions. This utility picks up errors from Win2K, Windows NT, applications—anything that touches the NT Event Viewer. If you have more than three or four servers, the tool will save you time and save your company money.

Event Log Filter isn't a command-prompt tool—it has a GUI interface, which Figure 1 shows. First, select a configuration. Start with the Default configuration (after you configure a filter, you can click Add under the Select configuration drop-down list to save that filter for future use). You can run the tool against multiple live servers and events or against .evt files that you've saved from Event Viewer. Use the Add and Remove buttons under the "Live" servers to process and Backup event logs to process fields to select the servers you want to monitor or the .evt files you want to read, respectively.

The tool renders output in a tab-delimited .txt file; use the Output file name box to specify a name for the output file. To append new data to an existing file, enter the existing filename and select the Append check box in the GUI's upper right corner. Specify How far back in the event log you want the tool to read, then use the Select services and Entry types sections to specify the services and events you want to look for. To exclude events from your scan, click Advanced to open the Advanced Options dialog box. In this dialog box, you can select services and specify event IDs that you want the tool to ignore.

Make sure you select the Unattended check box on the main GUI so that Event Log Filter doesn't need your input about any errors it encounters (e.g., if it attempts to process data from a server that's offline). When you click Go!, the application scans the event logs of the servers and .evt files you selected, then dumps the results into the text file you specified. Depending on how many servers and events you choose to monitor, that text file can get mighty big. You have two options for sorting through all the output.

The first way to parse the Event Log Filter output is to import it into an Excel spreadsheet. Import the text file in tab-delimited format. You end up with a spreadsheet that you can organize according to server name, event type, event ID, and so forth. Using this method lets you easily sort the information without needing to hunt through each server's Event Viewer information. For example, you can create a spreadsheet that places all the Error entries at the top, as Figure 2, page 14, shows.

The second way to parse the output is to pull it into an Access database. You can use the elf.mdb file that comes with Event Log Filter; if you use Access 2000 or later, you first need to convert elf.mdb to an updated format. (For example, open Access 2000 and select Tools, Database Utilities, Convert Database, To Current Access Database Version. Select elf.mdb and save it under a new filename.) Then, simply open the database (i.e., elf.mdb or the new version you created in Access 2000), choose Open Event Log from the menu bar, specify the path to your output text file, then click View Details. The database lists every event recorded in your output text file, complete with columns for Count, ID, Source, Category, Type, and Message.

Using Event Scan
Event Scan monitors the Event Viewer for log events that occur when services crash. You can configure the tool to restart or stop a problematic service, send a Net Send message to a computer, send an email message to a person or distribution list (DL), run an executable, or relay a comment—or a combination of these options.

First, you need to write a configuration (.cfg) file, as Figure 3 shows. The .cfg file is a semicolon-delimited file with the following syntax:


Event_ID and source are the relevant entry's event fields. Action is the action you want the tool to take (i.e., Restart or Stop). Alert_list is a comma-separated list of computers to which you want Event Scan to send Net Send messages when it detects the specified event. Mail_list is a comma-separated list of email aliases you want the tool to notify when the event is detected. Command is a command string of as many as 256 characters, including parameters. Comment is the comment you want to include in the Net Send and email messages. After you create the .cfg file, open a command prompt and type

evtscan ­f <config_file>
-u <profile_name>
\[-p <password>\]
\[-t <delay_in_seconds>\] <server_list>

on one line where config_file is the name of the .cfg file, profile_name is the name of the Exchange profile you want the tool to use, password is the profile's password (if needed), delay_in_seconds is the interval at which the tool scans the server, and server_list is a comma-separated list of the servers you want the tool to scan. For example, the following command will use the scan profile and will scan the fullspheredc server, according to the information in the test.cfg file, every 15 seconds:

evtscan ­f test.cfg ­u scan ­t 15 fullspheredc

As I mentioned earlier, Event Scan has some shortcomings. First, the tool has apparent problems working on Win2K servers (see the Web-exclusive sidebar "Sending Email Notifications,", InstantDoc ID 23744, for a workaround.) Second, the tool monitors only the Application log. As the Microsoft article "XADM: Event Scan Tool Only Reports Application Log Events" (;en-us;q185007) explains, this limitation is by design, but it limits the tool's usefulness. Third, you must leave the tool running on a system. This requirement leaves the application vulnerable: If the computer crashes, your account is locked out, or your network connection drops, you lose your monitoring ability.

A Mixed Bag
The BORK provides nearly everything you need to monitor your servers and get readable and useful reports. I highly recommend Event Log Filter as a useful, concise utility that lends itself to ease of use and reporting. Although Event Scan isn't as helpful—it's another point of failure, and it doesn't work on Win2K servers—you might find certain uses for the tool in an NT environment. See the Microsoft article "How to Use EVTSCAN with Netmon Tracing to Capture Event 23s" (;en-us;q188892) for an example.