Chapter 6: Event Logging, Tracking, and Automated Monitoring | MicrosoftВ® WindowsВ® Command-Line Administrators Pocket Consultant

< Day Day Up >

Up to this point, we have focused on tools and techniques used to manage local and remote systems from the command line. Now let’s look at how the event logs can be used for monitoring and optimization. Monitoring is the process by which systems are regularly checked for problems. Optimization is the process of fine-tuning system performance to maintain or achieve its optimal capacity.

This chapter examines logging tools available for Windows systems that can help you to identify and track system problems, monitor applications and services, and maintain system security. When systems slow down, behave erratically, or experience other problems, you may want to look to the event logs to identify the potential source of the problem. Once problem sources or issues are identified, you can perform maintenance or preventative tasks to resolve or eliminate them. Using event triggers, which watch for events to occur and take appropriate action to resolve them, you can even automate the monitoring and maintenance processes.

Windows Event Logging

In Microsoft Windows, an event is any significant occurrence in the operating system that requires users or administrators to be notified. Events are recorded in the Windows event logs and provide important historical information to help you monitor systems, maintain system security, solve problems, and perform diagnostics. It is important to sift regularly through the information collected in these logs, it is essential. Administrators should closely monitor the event logs of every business server and ensure that workstations are configured to track important system events. On servers, you want to ensure that systems are secure, that applications and services are operating normally, and that the server isn’t experiencing errors that could hamper performance. On workstations, you want to ensure that the events you need to maintain systems and resolve problems are being logged, and that the logs are accessible to you as necessary.

The Windows service that manages event logging is called the Event Log service. When this service is started, Windows logs important information. The logs available on a system depend on the system’s role and the services installed. Logs you may see include the following:

Application This log records significant incidents associated with specific applications. For example, Exchange Server logs events related to mail exchange, including events for the information store, mailboxes, and service states. By default, this log is stored in %SystemRoot%\System32\Config\Appevent.evt.
Directory Service On domain controllers, this log records incidents from Active Directory, including events related to directory startup, global catalogs, and integrity checking. By default, this log is stored in %SystemRoot%\System32\Config\Ntds.evt.
DNS Server On DNS servers, this log records DNS queries, responses, and other DNS activities. By default, this log is stored in %SystemRoot%\System32\Config\Dnsevent.evt.
File Replication Service On domain controllers and other servers using replication, this log records file replication activities on the system, including events for service status and control, scanning data in system volumes, and managing replication sets. By default, this log is stored in %SystemRoot%\System32\Config\Ntfrs.evt.

Security This logs records events related to security such as logon/logoff, privilege use and resource access. By default, this log is stored in %SystemRoot%\System32\Config\Secevent.evt.

Security Alert

To gain access to security logs, users must be granted the user right Manage Auditing And Security Log. By default, members of the administrators group have this user right. You will learn more about assigning user rights in the section titled, “Configuring User Rights Policies” of Chapter 9 in the Microsoft Windows Server 2003 Administrator’s Pocket Consultant.

System This log records events from the operating system or its components, such as the failure of a service to start, driver initialization, systemwide messages, and other messages that relate to the system in general. By default, this log is stored in %SystemRoot%\System32\Config\Sysevent.evt.

Events range in severity from informational messages to general warnings to serious incidents such as critical errors and failures. The category of an event is indicated by its event type. Event types include

Information Indicates an informational event has occurred, which is generally related to a successful action.
Warning Indicates a general warning. Warnings are often useful in preventing future system problems.
Error Indicates a critical error, such as the failure of a service to start.
Success Audit Indicates the successful execution of an action that you are tracking through auditing, such as privilege use.

Failure Audit Indicates the failed execution of an action that you are tracking through auditing, such as failure to log on.

Note

Of the many event types, the two you’ll want to monitor closely are warnings and errors. Whenever these types of events occur and you’re unsure of the reason, you should take a closer look to determine if you need to take further action.

In addition to type, each event has the following common properties associated with it:

Date Time Specifies the date and time the event occurred.
Event Details the specific event that occurred with a numeric identifier called an event ID. Event IDs are generated by the event source and used to uniquely identify the event.
Source Identifies the source of the event, such as an application, service, or system component. The event source is useful for pinpointing the cause of an event.
Computer Identifies the computer that caused the event to occur.
Category Specifies the category of the event, which is sometimes used to further describe the related action. Each event source has its own event categories. For example, with the security source, categories include logon/ logoff, privilege use, policy change, and account management.
User Identifies the user account that caused the event to be generated. Users can include special identities, such as Local Service, Network Service, and Anonymous Logon, as well as actual user accounts. The user account can also be listed as N/A to indicate that a user account is not applicable in this situation.
Description Provides a detailed description of the event and may also include details about where to find more information to resolve or handle an issue. This field is available when you double-click a log entry in Event Viewer.

The GUI tool you use to manage events is Event Viewer. You can start this tool by typing eventvwr at the command –line for the local computer, or eventvwr/computer=ComputerName, where ComputerName is the name of the remote computer whose events you wish to examine. As with most GUI tools, Event Viewer is easy to use and you will want to continue to use it for certain management tasks. For example, you must use Event Viewer to control the size of the event logs, to specify how logging is handled and to archive event logs. These tasks cannot be performed at the command line.

Event Viewer falls short, however, in its ability to filter events and work with event logs on remote computers. Sure, you can use Event Viewer to handle these tasks, but there are other utilities better suited to these tasks, including the following:

Eventquery Searches event logs and collects event entries that match specific criteria. In a script, you could use Eventquery to examine events on multiple systems and then store the results in a file, making it easier to track information as well as warnings and errors on the network as a whole.
Eventcreate Creates custom events in the event logs. Whenever you run custom scripts on a schedule or as part of routine maintenance, you may want to record the action in the event logs and Eventcreate provides a way to do this.
Eventtriggers Monitors event logs for specific events and then acts on those events by running tasks or commands. Using triggered events, you can configure systems to be self-monitoring. Triggered events are similar to scheduled tasks, except they run based on the occurrence of system events rather than on a recurring or one-time basis.

Real World

Monitoring system events isn’t something you should do haphazardly. Rather, it is something you should do routinely and thoroughly. With servers, you will want to examine event logs at least once a day and configure event triggers that alert you of any critical issues immediately. With workstations, you will want to examine logs on specific workstations as necessary, such as when a user reports a problem.

< Day Day Up >