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.
Illustration 1: All Dressed Up with Nowhere to Go ...
Limited Export Features in Event 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.
» 