MS Access for the Business Environment: Analyze and Report from the Windows Event Log, Part I - Page 2

Preparing to Create a Database for Event Analysis and Reporting

Event Logs compose a highly valuable weapon in the arsenal of Windows 2000 administrators. By default, a computer running a Windows Server 2000 family operating system records events in three kinds of logs:

•   Application log: The Application log contains events logged by applications or programs. For example, a database program might record a file error in the application log. Application developers decide which events to log.
•   Security log: The Security log records events such as valid and invalid logon attempts, as well as events related to resource use such as creating, opening, or deleting files or other objects. For example, if logon auditing is enabled, attempts to log on to the system are recorded in the Security log.
•   System log: The System log contains events logged by Windows system components. For example, the failure of a driver or other system component to load during startup is recorded in the System log. The event types logged by system components are predetermined by the server.

Other logs can appear on a computer, depending upon the services that are hosted. Domain controllers carry two additional logs, the Directory Service and File Replication logs, and Domain Naming System (DNS) servers host an additional DNS Server log.

We will focus primarily on the Application, Security log in this article, as it resides on virtually any Windows 2000 Server family machine. From the perspective of this article, however, the procedures we undertake to export the Application log would be the same for additional logs, should they exist and be populated.

Most would agree that recurring scans of the logs, at a bare minimum, are another "cost of doing business," in maintaining a well-tuned, trouble-free computing and network environment. But the Event Viewer's interface, the Microsoft Management Console, makes cursory browsing somewhat tedious, which often causes administrators to focus on the serious "error" items, whose "red-circle-and-x" icons cannot help but demand attention. At best, a few of the yellow "warning" class might also be reviewed, given the time to drill down on each to read the data presented. Informational events might be overlooked, or deferred, particularly in the hectic climates of today, and where other serious conditions might well be in progress

In addition to its importance in alerting us to existing or potential problems, the Event Log often provides essential guidance in troubleshooting servers, clients, networks, applications, and a host of other areas within which we might experience difficulties in operations. The logs, when examined and analyzed as a whole, enable us to see, and investigate, security issues such as system attack attempts, audit results and many others vital statistics. However, when it comes time to perform serious analysis of the data in the log, practitioners are often frustrated with the unwieldy approach of the Event Viewer in the Management Console.

The Event Viewer provides a reasonable interface from which to view, filter and search event logs. However, it does not provide the capability to automate the export of a complete event log to another application, such as a database. We can export the different log types individually in a manual process, but this presents a time consuming effort. Illustration 1 depicts the Event Viewer interface on a combined domain controller / DNS Server, with the Properties page for an example event assuming the focus after the event is double-clicked in the Viewer.

The menu clicks necessary to export the contents of a log are straightforward enough: We simply highlight the (single) log we wish to export, and then select Action --> Export List, whereupon we are prompted for the location to which we wish to export the file. (The clipboard icon on the Properties window saves the associated event's details to the clipboard, for an even more manual process of pasting elsewhere). This is simple, but requires manual intervention at any time we require export to take place.

The capability to fully export log files might be particularly useful when we need to explore the logs in detail for troubleshooting. Support teams for many applications request that you send them the user.dmp and drwtsn32.log files, in addition to parts or all of the Event Log, often filtered for a certain window of time before a crash, etc. or when tracking down a potential security breach. It is also useful for generating reports. Automation of log export would truly be a luxury, but, somewhat surprisingly, the Event Viewer offers no way to schedule the export process.

Fortunately, Microsoft has seen fit to address this need with various tools in the past and today. For Windows 2000, the tool specifically designed for this purpose is the Event Log Query tool.