AzureFeeds

What is the Event Log?

Each event log records events that happen on the Windows Server 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 Server 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 is the tool most people use to interact with their event logs. Event viewer tracks information in a number of logs termed the “Windows Logs”, which include the application, security, setup, system, and forwarded event logs.

• Application. The application log records events logged by applications and services running on the system. 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. Event log forwarding is a built in technology that allows you to centralize your event logs on a single computer. It’s pretty basic compared to dedicated telemetry tools like System Center Operations manager or your favorite third party alternative.

Applications and Services Logs. 

Each application or service installed on the computer probably has 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.

You should Note that Both Analytic and Debug logs are hidden and disabled by default. To use these logs:

1. Start Event Viewer


2. Click the View menu, and then select Show Analytic and Debug Logs to make these logs visible.


3. Then select the Analytic or Debug log that you want to enable and on the Action menu, click Properties.


4. 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
You can configure the event log settings in the following locations within the Group Policy Management Console:
Computer ConfigurationAdministrative TemplatesWindows ComponentsEvent Log Service

Subordinate folders exist for the following event logs by default:

• Application


• Security


• Setup


• System

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.

Maximum log size (KB)
The maximum log size 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 of both the Local Group Policy Editor and the Microsoft Management Console 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.

You can set a maximum log size value of between 1024 and 2,147,483,647 kilobytes in multiples of 64 kilobytes. That’s an approximate maximum log file size of 2 TB if you’re feeling relaxed about the amount of storage you have. Microsoft’s current recommendation for how to configure this setting is 4GB. 

The approximate maximum events per second that can be recorded is over 300,000. From a practical perspective if you’re thinking about log files that big, you should be using a tool like Azure Monitor or Systems Center Operations Manager to query and analyze your event data. If you were mucking around with log files that size in event viewer, you’re probably going to run into some issues.

Log File Location
The Control the location of the log file policy allows you to configure where event logs are written.

By default event log files are located in the %WinDir%System32WinevtLogs folder.
You can move these logs manually or by using policy. 

To move the event log files to a specified folder, follow these steps:

1. Open Event Viewer.


2. Right-click the log that you want to configure, and then select Properties.


3. In the Log path box, type the desired location for the event log, and then select OK.

This change takes effect immediately. However, the events that were already logged are still saved in the previous location.

If you relocate the event log files to an unavailable disk, the events will be lost.

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.

Log Access Policies

The following default log access rights are enforced:

The Log Access 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. This policy requires you use Security Descriptor Definition Language (SDDL) to identify security principals rather than just selecting a user or group. This makes it a lot more cumbersome to use than it should be. 

Enabling this policy allows you to enter a security descriptor for the log file. The security descriptor controls who can read, write, or clear the event log.

Control Event Log Behavior

The Control Event Log behavior when the log file reaches its maximum size policy setting controls Event Log behavior when the log file reaches its maximum size. 

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.

When this policy setting is disabled and a log file reaches its maximum size, new events overwrite old events in the same log file.

If this policy setting is enabled and a log file reaches its maximum size and the Retain Old Events policy is not enabled, new events are not written to the log and are lost. 

Backup log automatically when full

The “backup log automatically when full” 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.

You should archive logs to an external location at scheduled intervals and you ensure that the maximum log size is large enough to accommodate the interval. Alternatively use a monitoring solution that ingests and archives logs in an external location.

Summary

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.

Ensure that you configure log file policies so that log file size is appropriate and that important event log data is not overwritten or goes unlogged.