How to Set Up Windows Server 2016 Event Viewer

Event Viewer is the central logging and audit console in Windows Server 2016. It collects and displays events from the operating system, applications, and services in a structured, searchable interface. Every significant action on a Windows server — from a service failing to start, to a user logging in, to a disk error — generates an event that appears in Event Viewer. Knowing how to navigate, filter, and act on event data is a fundamental Windows Server administration skill.

This tutorial covers the Event Viewer interface, the standard event logs, creating custom views, configuring subscriptions to collect events from remote machines, and using PowerShell to work with event data programmatically.

Opening Event Viewer

Open Event Viewer from Server Manager by selecting Tools and then Event Viewer. Alternatively, run it from the command line or PowerShell:

eventvwr.msc

The console tree on the left shows the log categories. The center pane shows a list of events when a log is selected. The Actions pane on the right provides options for filtering, saving, and managing the selected log.

Understanding the Standard Logs

Windows Logs contains the core system logs. The Application log records events from user-mode applications and services. The System log records events from Windows system components, drivers, and the kernel. The Security log records audit events such as logon attempts, object access, and privilege use — this log is the primary source for security investigations. The Setup log records events related to role and feature installation. The Forwarded Events log receives events from remote computers when subscriptions are configured.

Applications and Services Logs contains component-specific logs. Expanding Microsoft, then Windows reveals logs for hundreds of individual Windows components such as Hyper-V, DHCP, DNS, PowerShell, Task Scheduler, and Windows Update. These component logs often contain much more detailed diagnostic information than the general System log.

Event Severity Levels

Events are classified by severity. Critical events indicate a serious failure that caused a service or the system to stop functioning. Error events indicate a problem that may affect functionality but did not cause an immediate stop. Warning events indicate a potential problem that is not yet causing failures but may lead to one. Information events record successful operations and general status updates. Audit Success and Audit Failure events appear in the Security log and record the outcome of audited actions.

Step 1: Filter Events

Event logs can contain thousands of entries. Use filtering to focus on relevant events. Right-click a log and select Filter Current Log. In the filter dialog, specify a time range, event levels (Critical, Error, Warning, etc.), event source, event ID, or keywords. For example, to find all failed logon attempts, filter the Security log for Event ID 4625.

Save a filter as a Custom View from the Actions pane to reuse it without re-entering the filter criteria each time. Custom Views appear under the Custom Views node in the console tree.

Step 2: Create a Custom View

Click Create Custom View in the Actions pane. Define the filter criteria and give the view a name and optional description. The view will appear permanently in the Custom Views section and will update in real time as new matching events arrive.

To create a custom view that catches errors across multiple logs simultaneously, use the XML filter tab and write a custom query:


  
    *[System[(Level=1 or Level=2) and TimeCreated[timediff(@SystemTime) <= 86400000]]]
    *[System[(Level=1 or Level=2) and TimeCreated[timediff(@SystemTime) <= 86400000]]]

This XML query retrieves Critical and Error events from both the System and Application logs from the past 24 hours in a single view.

Step 3: Attach a Task to an Event

Event Viewer can trigger an automated response when a specific event occurs. Right-click any event and select Attach Task To This Event. The Task Scheduler wizard opens, allowing you to run a program, send an email notification, or display a message when that event ID fires again.

This feature is ideal for setting up lightweight alerting without a third-party monitoring product. For example, attach a task to Event ID 6008 (unexpected shutdown) in the System log to trigger a notification script whenever the server crashes.

Step 4: Configure Event Subscriptions

Event subscriptions allow a central collector server to gather events from multiple remote machines into its Forwarded Events log. On the collector, run:

wecutil qc

On each source server, enable the Windows Remote Management service and add the collector’s computer account to the local Event Log Readers group:

winrm quickconfig
net localgroup "Event Log Readers" DOMAINCollectorServer$ /add

In Event Viewer on the collector, right-click Subscriptions and select Create Subscription. Specify the source computers, the event query to collect, and the delivery mode (collector-initiated or source-initiated).

Step 5: Query Events with PowerShell

Use Get-WinEvent to query events from the command line. Get the last 20 System log errors:

Get-WinEvent -LogName System -MaxEvents 20 | Where-Object { $_.LevelDisplayName -eq 'Error' }

Search for a specific event ID across a time range:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddHours(-24)
} | Select-Object TimeCreated, Message | Format-List

Query events from a remote computer:

Get-WinEvent -ComputerName Server02 -LogName System -MaxEvents 50 | Where-Object LevelDisplayName -eq 'Critical'

Step 6: Export and Archive Logs

Right-click any log and select Save All Events As to export it to an EVTX file for archiving or offline analysis. To export from the command line:

wevtutil epl System C:LogsSystem_Archive.evtx

Clear a log after archiving to free space:

wevtutil cl System

Event Viewer on Windows Server 2016 is an indispensable tool for understanding server behavior and investigating incidents. Combining it with custom views, task attachments, and PowerShell scripting makes it a powerful component of any proactive monitoring and incident response strategy.