In-Depth

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.

• By Derek Melber
• 04/01/2004

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 log.

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.

Tip 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 controller.

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 Log.

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 be.

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"

or

"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.

Using EventComb
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 and searching.

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 your head.

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 protected].