The Mystery of the Event Logs
Knowing what’s in your Event Logs is a key to knowing what your servers are doing. Here’s how to make sense of them.
Have you taken a look in the Event Viewer lately? Are you afraid to? Does it just frustrate you too much to even spend one minute trying to decipher the descriptions involved with the events? I’m sure if I told you the Event Viewer and the event descriptions have gotten better, you’d scoff and continue with what you’re doing.
This article discusses some of the most common frustrations related to
the Event Viewer and the logs. Along the way, I’ll offer suggestions for
administration and reviewing of the logs that can help you not only use
Event Viewer, but solve problems generated from the cryptic details embedded
within the events.
Configuring the Security Log to Track Events
Windows 2000 Server and Windows Server 2003 contain three event logs by
default: Application, Security and System. The Application and System
logs are constantly archiving information as different activities are
performed on the computer, but the Security Log is empty by default on
Win2K. For Windows 2003, Microsoft has enabled some of the audit settings
that create security event tracking. The question is how to get events
to show up in the Security Log or change what’s being recorded in the
The Security Log is tied to the Windows Auditing feature. In order to
begin archiving security events, Auditing needs to be enabled on the computer.
There are two methods for enabling auditing: via the local computer or
by using Group Policy Objects (GPOs). Both methods achieve the same goal
for said computer, but the GPO method allows consistent setup on multiple
computers with a single configuration.
|Another way to get to the Auditing configuration
is to use the Local Security Policy. This built-in administrative
tool can be accessed through the Start Menu or Control
Panel, located with the other administrative tools.
Configure Auditing on the Local Computer
To configure Auditing locally, you’ll configure the Local Group Policy.
Open the Microsoft Management Console (MMC) and add in the Group Policy
Object Editor snap-in. This will give you the option to pick the Local
Computer, which gives access to the Local Group Policy.
After opening Local Group Policy, you’ll need to get down to the Audit
Policy portion of the GPO. This is under the Computer Configuration |
Windows Settings | Security Settings | Local Policies path in the GPO,
as shown in Figure 1.
|Figure 1. Location of the Audit Policy settings
in the Local Group Policy for a Windows Server 2003 computer and possible
configurations for each policy. (Click image to view larger version.)
As you can see, there are quite a few Audit Policy policies that can be set. The following is a list of each different policy, and what aspect of the computer it will track events for.
Audit account logon events. This tracks login requests to a domain
Audit account management. This tracks user or group modifications.
It includes creation, modification and deletion of an account, as well
as password changes and disabling or enabling a user account.
Audit directory service access. This tracks Active Directory
object access, including organizational units (OUs), user accounts, group
accounts, group policy objects and so on. This setting only works on DCs.
Audit logon events. This tracks logons and logoffs, either interactive
or via the network. These events are logged where the logon occurs.
Audit object access. This tracks user object access. Objects
can be files, folders, printers, Registry keys and AD objects. Turning
this on doesn’t immediately start the logging of events. To do that, you’ll
need to modify the Security Audit Control List (SACL) of the object for
which you want to track access.
Audit policy change. This tracks changes to the User Rights Policy
or Audit Policy. For security purposes, an entry’s created in the Security
Log if someone turns off Auditing.
Audit privilege use. This tracks when User Rights are invoked
on a computer. Examples of User Rights include logging on locally, accessing
the computer from the network, backing up files and folders, changing
the system time and so on.
Audit process tracking. This tracks processes, which can include
very granular details of a task. For example, just starting Notepad.exe
can generate 15 to 20 events, since each process of that application starting
will be tracked. This is used rarely and is typically only tapped by developers
to help troubleshoot an application they’re building.
Audit system events. This tracks events triggered by the computer
system itself. Typical events tracked include system startup, shutdown
and a full security log.
Once you’ve read though the descriptions and decided on exactly what you want to audit, you need to decide how to configure each policy setting. There are multiple configurations for each policy. These settings include:
Not configured. In essence, this makes the policy neutral. It
won’t alter the computer audits in any way. (This is only available when
you configure a GPO in AD; not in the Local Group Policy.)
No auditing. Configures the computer to not audit any events
related to this policy.
Success. Enables the tracking of successful events. For example,
if someone is able to log on locally to a computer console, an event will
be written to the Security Log if “Audit privilege use” is set to Success.
Failure. Enables the tracking of failed attempts to perform a
task or access an object. For example, if a user doesn’t have permission
to modify the members of a group, but attempts to anyway, that failed
attempt will be written to the Security Log if “Audit account management”
is enabled and set to Failure.
After configuring one or more Audit Policy policies for success and/or
failure, the Security Log begins to archive events.
Configure Auditing using GPOs in Active Directory
For configuring auditing using group policies in Active Directory, the
same policies and settings configured on the local computer will be available.
However, there can be a more widespread effect with just a single GPO
configured. This article isn’t meant to be a how-to for AD design, but
let’s look at an example of how you can leverage GPOs in AD to your advantage.
Assume you have 100 Windows 2003 file servers for all users in the company.
If you configure auditing locally, you’ll need to touch 100 computers
to complete the configurations. Using GPOs and AD, you’ll only need to
deal with one: Create an Organizational Unit (OU) and place all of the
file server computer accounts in the OU. Then create a new GPO and link
it to the OU. Configure the Audit Policy policies similar to the previous
example on the local computer and you’re done. When the replication interval
cycles (every 90 minutes by default), the Audit Policy on all 100 servers
will be correctly configured and start to generate events in the Security
Using GPOs to Configure the Event Log Settings
GPOs aren’t only used to configure the Audit Policy policy settings, but
also to configure the Event Log settings. These settings include how the
log behaves when it fills up and the log file size. Figure 2 shows the
Event Log settings dialog box.
|Figure 2. Log properties for the Security Log.
Each Event Log is configured independently, so you can tailor each for the amount of information you plan to archive. Ideally, you want to configure the log size to be large enough to capture all events between scheduled backups of log files. The default size of 512K (on Win2K) is usually not large enough, so a good starting size might be 5MB. Windows 2003 servers start the log size for all logs at about 16MB. Best practice is to configure the logs to “Overwrite events as needed.” This keeps the maximum number of events in the log file, overwriting the oldest events when the log is full.
In order to configure a GPO to modify each setting in the log properties
on every computer, follow the previous steps for creating an OU and linking
a GPO to the OU. Then, when editing the GPO, maneuver to the Computer
Configuration | Windows Settings | Security Settings | Event Log | Settings
for Event Logs, as shown in Figure 3.
|Figure 3. A group policy for configuring event
log settings. (Click image to view larger version.)
There are settings for the log file size and log retention for each type
of Event Log in Event Viewer. Once you set these in the GPO in the AD,
each computer account contained within the OU where the GPO is linked
will receive these settings at the next application interval.
The Problem With Event Logs
The concept of Event Logs and archiving security events is extremely important
and useful. Administrators use Event Viewer to track down problem hardware,
software, replication issues, DNS issues, AD problems and so on. However,
most admins don’t enter the profession with an intuitive grasp of Event
Logs, because they can be cryptic. Figure 4 shows an example of an event
generated on one of my DCs.
The information shown in the description isn’t helpful to the untrained IT pro. Granted, if you’re a WMI (Windows Management Instrumentation) guru, you might be able to decipher the description’s meaning, but it’s still a stretch.
Even if you’re a neophyte IT administrator, you shouldn’t give up on this event. The key to all events is to know how to track down its exact meaning and then pursue the settings within the computer to find the root of the problem. To track down the exact meaning of the event, you should be using TechNet. Yes, TechNet.
TechNet is one of the best tools for helping track down events and their
meanings. You can access TechNet online for free, but I find it’s easier
and faster to use the TechNet subscription CDs. [To learn the secrets
of TechNet, read this issue’s article, “TechNet Has More Than You Know,”
URL HERE—Ed.] The secret decoder ring for using TechNet is in knowing
how to search. Let’s use the event in Figure 4 as a platform for what
you’d search for in order to track down the root of the problem.
|Figure 4. This event shows how cryptic logs can
When you launch TechNet, you’ll need to go to the search menu option. Enter the following search strings (including all punctuation) in the text entry box:
"winmgmt" near "event"
"WMI" near "CLR" near "event" near "62"
Notice that you might get some hits from these queries and other times
you get nothing. Here, the first search should give you about 25 results.
The second search might not get you any. Each search is different, based
on the information you’re given in the log. You can see the rules I use
for searching, which includes the source and the fact that it’s an event.
Another tip is to pick out a unique word or phrase in the description
and use that as a search keyword. I always use quotes, to ensure I’m only
getting those words in the results. I also use the word “near,” as that
will only give me results on the other keywords within 50 words of one
another within the text.
To review log files to look for security or application issues, you use
the computer that houses the log file. If you have thousands, or tens
of thousands of servers, this can be an overwhelming task. There are some
tools that can organize all your server information for you, but these
tools can be costly.
Microsoft has come to the rescue, producing a free utility to help gather information from across all computers on the network and organize it into a single location. EventComb started off as a command-line tool, and was less than successful. But Redmond has added a GUI and made it very useful. Find it at www.microsoft.
com/downloads/; specify “Security Guide Scripts Download” in the keyword field.
After getting Secops.exe extracted and locating Eventcomb.exe tool down
in the folder structure, it’s simple to run. Figure 5 shows the interface.
|Figure 5. EventComb aggregates Event Log information
from network computers. (Click image to view larger version.)
Using EventComb is intuitive. You can search on the desired computer
or computers, event type, Event Log and specific Event IDs. It saves the
results in text files for each computer and stores them in a folder on
the local computer. The files can be imported into Excel for archiving
Harness the Power of Event Viewer
If the Event Viewer has had you frustrated in the past, look again. Administration
of the settings can be as simple as a single GPO. GPOs allow you to manage
the log size, retention and even details logged on specific computers.
Knowing that the cryptic logs can be translated through TechNet may give
you more impetus to track down all those issues that can leave you scratching
And if you’re in an enterprise environment and the thought of all those
events spread across all those servers petrifies you, Microsoft has come
to the rescue with EventComb. The hardest part of the tool is just deciding
what you want to gather, not viewing what you have gathered.
Derek Melber is a founding partner of BrainCore.Net and develops and trains custom courses for Windows Active Directory, Group Policy and Security. His latest work is a series of Windows Server 2003 videos through BrainCore.net. Reach him at email@example.com.