Using Event Viewer to Safeguard Your Systems

When any significant event occurs on a computer, the OS writes that event to a log. Event Viewer (eventvwr.exe) is the repository of these event logs. Most administrators open Event Viewer only to try to solve a serious problem, and many administrators tell me they use this tool only on servers. Both practices are administrative mistakes because checking event logs periodically can frequently catch problems before they become serious. Knowing how to use Event Viewer is an important skill, so let me provide an overview of the subject and pass along the ways in which I use Event Viewer.

Event Viewer Basics
You open Event Viewer from the Administrative Tools menu (if you've added that menu to your Programs menu) or from the Control Panel Administrative Tools applet. Event Viewer's console lists the available logs. Windows computers have the following default logs:

On Windows Server 2003 and Windows 2000 Server systems, depending on the server's role, you might have any of the following logs:

Event Viewer displays a variety of event types, each of which has its own level of significance and its own icon type in the event logs. For example

The information that Event Viewer displays includes the event type, the date and time that the event occurred, the event's source (e.g., the service, device driver, or application that wrote the event to the log), the event category, the event ID, the user who was logged on when the event occurred (if applicable), and the computer on which the event occurred. Note: You must have administrative rights to view the Security log.

Configuring Event Viewer
The event logs start automatically when you start the OS. The log files have a finite size, and the system overwrites events according to the log's configuration options. To see or change the configuration options, right-click a log's listing in Event Viewer and select Properties from the drop-down menu. You should see the corresponding Properties dialog box, as Figure 1, page 62, shows.

Changes you make to the configuration settings depend on your situation. If you're not making major configuration changes or you haven't felt the need to audit events, the default settings should work fine. The default setting for maximum log-file size is 512KB, and the system automatically overwrites events after 7 days when the log is filled. However, if you make a major change in the system or you configure an aggressive auditing plan, your event logs will likely begin recording many events. If the log becomes filled but contains no events older than 7 days, Event Viewer has nothing to discard to make room for more events and the system stops logging events. In that situation, enlarge the log file or configure the log to overwrite events as needed.

Filtering the View
When you examine a log to resolve a problem or check a computer's reaction to a major configuration change, you can speed your investigation by eliminating irrelevant events from the Details pane. Each log's Properties dialog box has a Filter tab that you use to configure the types of events that you want to view. For example, you might not care about seeing information events for certain computers, or you might want to see certain events only for a week or so after a major system change. Simply select and deselect filters as needed. Remember, the filters affect only the view; the system continues to write to the event log those event types that you filter out. For example, if you think your system might be in danger of a security breach, you could filter for event types that would provide a quick look at logon abnormalities, such as event IDs 675 and 681, which represent authentication attempts that failed, or event ID 644, which means an account was locked out because of multiple incorrrect password entries.

Sorting a Log
When I'm on a problem-solving mission, I like to sort the logs so that I can head directly for the event type or number I need or for the source I think is reporting the problem. For example, I might look for a Userenv event if the problem involves a user who is having access problems across the network.

One common Userenv event is event ID 1000 in the Application event log, which states that Windows couldn't determine the user or computer name. This event means that the TCP/IP configuration on the computer isn't set correctly for the DNS server. (Administrators commonly use the wrong address for DNS configuration on client computers; I frequently find the IP address of a gateway entered as the DNS address.) Checking the offending computer's Event Viewer from your workstation is usually quicker than going to the client computer and opening the TCP/IP settings.

To zero in on specific types of events, select the appropriate log in the console to display its contents in the Details pane, then click the column heading of the category on which you want to sort. The default sort is Date, subsorted by Time.

Clearing a Log
You can clear any log to make room for additional entries. If you configured the log with the Do not overwrite events (clear log manually) option selected, you must periodically clear the log.

To clear a log, right-click its listing in the Event Viewer console and select Clear all Events. Windows asks whether you want to save the log before clearing it. If the log has entries you think you might need to examine later (perhaps because you're tracking a persistent problem), you can archive the log's contents.

Archiving a Log
You can archive a log as a discrete file, which is useful if you notice peculiar entries and you want to track the log over a period of time. Sometimes you see events that appear to be ominous but neither the user nor the computer associated with the events is experiencing any problems. If problems develop later, you or a Microsoft support person might find the event history helpful.

To archive a log, right-click the log in the console and select Save Log File As. By default, Windows saves the file in the Administrative Tools folder, which is in C:documentssettingsusernamestart menuprograms. You can choose another folder or create a folder to hold archived logs. I typically name the file with the format logname-date (e.g., apps-dec012003). Windows adds the .evt extension.

Event-log archives are discrete files on your hard disk, but you can open them only from within Event Viewer. To do so, choose Open Log File from the Action menu (or right-click an object in the console pane and choose Open Log File). In the Open dialog box, select the desired archive, select the log type (e.g., Application, Security) from the Log Type dropdown menu, then click Open.

To remove an archive from the console, right-click its listing and select Delete. This action doesn't delete the file from your hard disk; it just removes the file from the console. You delete the file from your hard disk the same way you delete any file.

Accessing Event Viewer on a Remote Computer
To make your work as an administrator easier, you can view from your workstation the logs of remote computers on which you have administrative privileges. The remote computer must be running Windows 2003, Windows XP, Win2K Professional, Win2K Server, Windows NT Server, or NT Workstation.

In your local Event Viewer console, right-click Event Viewer (Local), and select Connect to another computer. Type the name of the remote computer you want to work on, or click Browse to open the screen that Figure 2 shows, then select the desired computer. Incidentally, if you know the name of the remote computer, you don't have to enter it as a Universal Naming Convention (UNC) name. Event Viewer's console changes to reflect the remote computer's UNC name. You can perform on the remote computer all actions that are available on your local Event Viewer. To return to the local computer, right-click Event Viewer (ComputerName), choose Connect to another computer, then select Local computer.

What to Look for in Event Viewer
Most real or potential problems make themselves apparent by writing an event to a log. When you see an Error or Warning event, pay attention; search for information about the event in the Microsoft Knowledge Base or on the Windows & .NET Magazine Web site. If you wait until after a problem occurs to view the event logs, you lose the opportunity to prevent the problem. For example, during my periodic peek into Event Viewer on all my network computers, I found in the System log the event that Figure 3 shows. The computer hadn't shown any symptoms of a problem.

I quickly backed up the data on the computer and ran Chkdsk, which moved files (they were system files) from bad blocks and marked the blocks as bad to prevent further writes to that part of the disk. I checked the System log daily for a few weeks, and when no additional Error events appeared, I returned to weekly Event Viewer checks. If I'd seen more Error events, I would have replaced the disk. If I hadn't been checking the computer's Event Viewer periodically, the disk probably would have continued to fall apart and data backups would have been useless because of file corruption.

Incidentally, when I examine Event Viewer, I sort by Type and check the Error events first, then the Warning events. In this case, I also found a Warning event dated 1 day before the Error event appeared that said an error on the disk was detected when Windows was writing to the paging file. If I'd checked the Event Viewer a day earlier, I probably would have had fewer bad blocks for Chkdsk to fix.

You should also look for any event in the Security log. Unless you've established security audits, that log should remain empty. If you do establish security audits, look for significant events related to the audit settings. (The Security log is the only log in Event Viewer that requires administrative rights for viewing.) For more information about auditing security events, see

"Monitoring Important Security Events," October 2003, http://www.winnetmag.com, InstantDoc ID 40046. For a list of security event IDs, visit http://www.secadministrator.com/articles/index.cfm?articleid=15361.

Stop Logging Unimportant Events
By default, Windows configures computers that act as print servers to log all events related to printing. In addition, the computer's System log records an informational event every time a document is sent to a printer and again when the spool file is deleted after the print job finishes.

Personally, I don't care about any printing events, but some administrators want to know if and when printing fails; they also want notification if someone adds or deletes a printer. I doubt whether any administrator finds it necessary to log an informational event every time a print job is sent to the spooler and is later deleted.

You can change the print events that the System log records by opening the computer's Printers folder (called Printers and Faxes in Windows 2003 and XP). Choose File, Server Properties, and move to the Advanced tab, which Figure 4 shows. Simply deselect the events you don't want to log.

Get into the Routine
Put Event Viewer on your list of maintenance tasks and check your network computers periodically. If you're responsible for many computers, make sure you check servers (especially DCs) at least weekly and rotate workstation checks so that you get to each workstation every few weeks. Although this task might sound time-consuming, it's actually an investment in saving time because fixing a problem that's become severe is much more difficult and time-consuming than checking Event Viewer to gain advanced information about problems in the making.