Updated: January 21, 2009
Applies To: Windows Server 2008
The event logs record events that happen on the computer. Examining the events in these logs can help you trace activity, respond to events, and keep your systems secure. Configuring these logs properly can help you manage the logs more efficiently and use the information that they provide more effectively.
Windows Vista® and Windows Server® 2008 have a new event system that saves event log files as XML files that can be reported on and managed as part of a collective reporting schema. There are several additional log providers and categories that you can monitor.
Event Viewer in Windows Vistaand Windows Server 2008 tracks information in a number of logs, including:
Windows Logs. This provider contains the following events logs from the operating system:
Application. Events in this Windows log are classified as error, warning, or information, depending on the severity of the event. An error is a significant problem, such as loss of data. A warning is an event that is not necessarily significant but might indicate a possible future problem. An information event describes the successful operation of a program, driver, or service.
Security. This Windows log contains security-related events, which are called "audit events," and are described as successful or failed, depending on the event, such as whether a user's attempt to log on to Windows® was successful.
Setup. This Windows log records events related to installing programs and services on the computer. Computers that are configured as domain controllers have additional logs displayed in this category.
System. This Windows log records system events that are sent by Windows and Windows system services, and are classified as error, warning, or information.
Forwarded Events. This Windows log records events are forwarded to this log by other computers.
Applications and Services Logs. Applications and Services Logs is a new category of event log provider. Each application or service installed on the computer will have an individual log. These logs store events from a single application or service rather than events that might have systemwide impact. This category of logs includes four subtypes for which the application or service can provide events: Admin, Operational, Analytic, and Debug logs.
Admin. Events that are found in the Admin channels indicate a problem and a well-defined solution that an administrator can act on. An example of an admin event is an event that occurs when an application fails to connect to a printer. These events are either well documented or have a message associated with them that gives the reader direct instructions of what must be done to rectify the problem.
Operational. Events that are found in the Operational channels are used for analyzing and diagnosing a problem or occurrence. They can be used to trigger tools or tasks based on the problem or occurrence. An example of an operational event is an event that occurs when a printer is added or removed from a system.
Analytic. Events that are found in the Analytic channels aid in performance evaluations and troubleshooting. These events are published in high volume, so they should only be enabled and logged for limited amounts of time as part of a diagnostic process. They describe program operation and may indicate problems that cannot be handled by user intervention.
Debug. Events that are found in the Debug channels can be used by developers when troubleshooting issues with their programs.
Both Analytic and Debug logs are hidden and disabled by default. To use these logs, first start Event Viewer, click the View menu, and then select Show Analytic and Debug Logs to make these logs visible. Then select the Analytic or Debug log that you want to enable and on the Action menu, click Properties. On the properties dialog box, select Enable logging and click OK.
Each of these logs has attributes, such as maximum log size, access rights for each log, and retention settings and methods, each of which can be defined in the appropriate Event Log section in Group Policy.
Event Log Settings
The Event Log Group Policy settings have been moved to a separate administrative template file in Windows Vista and Windows Server 2008. You can configure the event log settings in the following locations within the Group Policy Management Console:
Computer Configuration\Administrative Templates\Windows Components\Event Log Service\
Subordinate folders exist for the following event logs by default:
The same set of policy settings is available for each event log. The Setup folder has an additional policy setting that allows logging to be turned on. The following sections describe the options and issues for configuring event log settings for better system management and security.
The event log Group Policy settings in Windows Server® 2003 are still supported on Vista. However, if the new Group Policy settings for the Event Log Service are also specified, they take precedence.
Maximum log size (KB)
This policy setting specifies the maximum sizes of the log files. An individual setting may be specified for each of the Application, Security, Setup, and System event log channels. The user interfaces (UIs) of both the Local Group Policy Editor and the Microsoft Management Console (MMC) Event Viewer snap-in allow you to enter values as large as 2 terabytes. If this setting is not configured, event logs have a default maximum size of 20 megabytes.
Although there is no simple equation to determine the best log size for a particular server, you can calculate a reasonable size by multiplying the average event size by the average number of events per month, assuming that you back your logs up on a monthly schedule. The average event takes up about 500 bytes within each log, and the log file sizes must be a multiple of 64 KB. If you can estimate the average number of events that are generated each day for each type of log in your organization, you can determine a good size for each type of log file.
For example, if your file server generates 5,000 events per day in its Security log and you want to ensure that you have at least four weeks of data available at all times, you should configure the size of that log to about 70 MB (calculated as 500 bytes * 5000 events per day * 28 days = 70,000,000 bytes). Then check the servers occasionally over the following four weeks to verify that your calculations are correct and that the logs retain enough events for your needs. Event log size and log wrapping should be defined to match the business and security requirements that you determined when you designed your organization's security plan.
When enabled, specify a user-defined value in KBs between 1024 and 2147483647, which must be a multiple of 64.
Disabled or Not Configured
The maximum size of the log file maximum size is set to the local configuration value. This value can be changed by the local administrator using the log properties dialog box, and it defaults to 20 megabytes.
If you significantly increase the number of objects to audit in your organization and if you enabled the Audit: Shut down system immediately if unable to log security audits setting, there is a risk that the Security log will reach its capacity and force the computer to shut down. If such a shutdown occurs, the computer is unusable until an administrator clears the Security log. To prevent such a shutdown, you can disable the Audit: Shut down system immediately if unable to log security audits setting that is described in Security Options and increase the Security log size.
Enable sensible log-size policies for all computers in your organization so that legitimate users can be held accountable for their actions, unauthorized activity can be detected and tracked, and computer problems can be detected and diagnosed. Article 957662 "Recommended settings for event log sizes in Windows Server 2003 and in Windows Server 2008" (http://go.microsoft.com/fwlink/?LinkId=131753) provides guidance for the maximum size of event logs that you should configure on your server.
By default when event logs fill to capacity, the computer overwrites the oldest entries with the most recent ones. To mitigate the risk of loss of older data, you can configure the computer to automatically back up the log when it becomes full.
Ideally, all specifically monitored events should be sent to a server that uses System Center Operations Manager 2007 or other automated monitoring tool. Such a configuration is particularly important because an attacker who successfully compromises a server could clear the Security log. If all events are sent to a monitoring server, you can gather forensic information about the attacker's activities.
This policy setting determines which user accounts have access to log files and what usage rights are granted. Individual setting may be specified for each of the Application, Security, Setup, and System event log channels.
Enabling this setting allows you to enter a security descriptor for the log file. The security descriptor controls who can read, write, or clear the event log. You enter the security descriptor using Security Definition Description Language (SDDL). The following example shows the default SDDL string for the Application log:
O:BAG:SYD:(D;; 0xf0007;;;AN)(D;; 0xf0007;;;BG)(A;; 0xf0007;;;SY)(A;; 0x5;;;BA)(A;; 0x7;;;SO)(A;; 0x3;;;IU)(A;; 0x2;;;BA)(A;; 0x2;;;LS)(A;; 0x2;;;NS) In this example, the first ACE denies Anonymous Users read, write, and clear access to the log. The sixth ACE permits Interactive Users to read and write to the log. For more information about SDDL syntax and about how to construct an SDDL string, see the MSDN topic Security Descriptor String Format (http://go.microsoft.com/fwlink/?LinkID=96260).
If this setting is disabled or not configured for the application or setup logs, all authentication users can write, read, and clear the log. If this policy setting is disabled or not configured for the security log, only system software and administrators can read or clear the log.
Attackers who successfully log on to a computer can learn important information about the computer if they are able to view the event logs. They could then use this information to implement additional exploits.
Enable the Log access setting for the policies of all event logs.
None. This is the default configuration.
Retain old events
This policy setting controls Event Log behavior when the log file reaches its maximum size. When this policy setting is enabled and a log file reaches its maximum size, new events are not written to the log and are lost. When this policy setting is disabled and a log file reaches its maximum size, new events overwrite old events.
Old events may or may not be retained according to the Backup log automatically when full policy setting. You should only configure this setting if you archive the log at scheduled intervals and you ensure that the maximum log size is large enough to accommodate the interval.
Retaining old events introduces a greater risk of both a DoS attack by filling up the event log and an evidence obfuscation method by preventing critical information about an attack from being logged due to lack of space.
Configure the Retain old events setting for the policies of all four event logs to Not Defined. If you decide that you must retain old events logs, configure the Backup log automatically when full policy setting to mitigate the risk associated with this setting.
None. This is the default configuration.
Backup log automatically when full
This policy setting controls Event Log behavior when the log file reaches its maximum size and takes effect only if the Retain old events policy setting is enabled. If you enable this policy setting and the Retain old events policy setting is enabled, the Event Log file is automatically closed and renamed when it is full. A new file is then started. If you disable this policy setting and the Retain old events policy setting is enabled, new events are discarded and the old events are retained. When this policy setting is not configured and the Retain old events policy setting is enabled, new events are discarded and the old events are retained.
If you significantly increase the number of objects to audit in your organization, there is a risk that the Security log will reach its capacity and force the computer to shut down. If such a shutdown occurs, the computer is unusable until an administrator clears the Security log. To prevent such a shutdown, you can disable the Audit: Shut down system immediately if unable to log security audits setting that is described in Security Options and then increase the Security log size.
If you enable the Retain old events policy setting and enable and specify a Maximum log size policy setting, you should also enable the Backup log automatically when full policy setting to ensure that all valued events are recorded and retained and that there is no loss of service due to lack of storage for event logs.
Ideally, all significant events are sent to a monitoring server that uses Operations Manager 2007 or other automated monitoring tool.
Computers must have enough local storage to create a backup file or access to a network storage location to create the backup file. If the events cannot be logged because the disk is full or unavailable, the events are lost. Security events are the exception to this rule if you have enabled the Audit: Shut down system immediately if unable to log security audits policy setting, in which case the impacted computer shuts down.
In Windows Vista, and Windows Server® 2008, it is possible to customize the permissions on each event log on a computer. Some organizations may want to grant read-only access to one or more of the System event logs and to some members of the IT team, such as auditors. The access control list (ACL) is stored as a Security Descriptor Definition Language (SDDL) string. If this policy setting is enabled, only those users matching the security descriptor can access the log.
You cannot use this setting to configure write permissions for the log.
If this policy is disabled or not configured, the following default log access rights are enforced:
Application and Setup logs
All authenticated users can write/read/clear the log.
Only system software and administrators can write or clear the log. Any authenticated user can read events from it.
Only system software and administrators can read or clear the log.
Users, both legitimate and illegitimate, who are attempting to hide evidence of prohibited activities could clear the event logs that could be used against them.
Identify which log files are valued in your organization. The security event log has the most restrictive default settings, but events in the application log or setup log may also be useful for forensic investigation. Configure the SID to match the user account that is trusted to manage and monitor those logs.
Users may not be able to access event log data for troubleshooting information.
The following links provide additional information about event logging in Windows Server 2008 and Windows Vista: