How to Use Event Viewer on Windows Server 2012 R2

How to Use Event Viewer on Windows Server 2012 R2

Event Viewer is the central log management console on Windows Server 2012 R2, providing access to the Windows event log system that records security events, system activities, application errors, and audit trail information. Every significant action on a Windows Server — user logins, service starts and stops, policy changes, hardware errors, and application crashes — generates an event log entry. Understanding how to efficiently navigate, filter, and analyze these logs is a fundamental skill for Windows Server administration.

Windows Server 2012 R2 uses the Eventing 6.0 infrastructure, which supports structured XML-based event records, analytic and debug log channels, and significantly more event types than earlier Windows versions. This guide covers the complete Event Viewer interface, creating custom views and filters, using PowerShell’s Get-WinEvent cmdlet for scriptable log analysis, configuring log sizes, enabling additional diagnostic log channels, and setting up event subscriptions for centralized collection.

Prerequisites

– Windows Server 2012 R2 with administrative access
– PowerShell 4.0 for command-line log analysis
– Understanding of event IDs for the services you are monitoring
– Sufficient disk space for expanded event log sizes

Step 1: Open Event Viewer

Access Event Viewer through Server Manager (Tools menu) or directly:

eventvwr.msc

The Event Viewer navigation pane has four main sections:

– Custom Views: Pre-defined filtered views including Administrative Events
– Windows Logs: The classic logs — Application, Security, Setup, System, Forwarded Events
– Applications and Services Logs: Thousands of application-specific and diagnostic logs
– Subscriptions: Centralized event collection from remote computers

Step 2: Navigate the Windows Logs

The five Windows Logs are the most frequently reviewed:

Application Log: Events from applications and services (IIS, SQL Server, .NET runtime, antivirus, etc.). Error entries here typically indicate application crashes or configuration problems.

Security Log: Audit events — successful and failed logins, account management, object access, privilege use, and policy changes. Requires audit policy configuration to populate fully.

System Log: Events from Windows system components, drivers, and services. Driver failures, service crashes, and hardware errors appear here.

Setup Log: Windows installation and update-related events.

Forwarded Events: Events collected from remote computers via Windows Event Forwarding subscriptions.

Step 3: Filter Events Using PowerShell

PowerShell’s Get-WinEvent cmdlet provides powerful, scriptable access to all event logs. It is significantly faster than the older Get-EventLog cmdlet:

# Get the last 20 System log errors and critical events
Get-WinEvent -LogName System -MaxEvents 100 | 
    Where-Object { $_.Level -le 2 } | 
    Select-Object -First 20 TimeCreated, Id, LevelDisplayName, ProviderName, Message |
    Format-List

# Search the Security log for failed logon attempts (Event ID 4625)
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4625]]" -MaxEvents 50 |
    Select-Object TimeCreated, Id, Message | Format-List

# Search for successful logons (Event ID 4624) with specific account
$filter = @{
    LogName   = 'Security'
    Id        = 4624
    StartTime = (Get-Date).AddDays(-1)
}
Get-WinEvent -FilterHashtable $filter -MaxEvents 100

Step 4: Use FilterHashtable for Efficient Queries

The -FilterHashtable parameter performs server-side filtering, which is far faster than piping through Where-Object for large logs:

# Find Application log errors in the last 24 hours
Get-WinEvent -FilterHashtable @{
    LogName   = 'Application'
    Level     = 2  # Error
    StartTime = (Get-Date).AddHours(-24)
} | Select-Object TimeCreated, ProviderName, Id, Message | Sort-Object TimeCreated -Descending

# Find system events from a specific source
Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Service Control Manager'
    Level        = 2
    StartTime    = (Get-Date).AddDays(-7)
} | Select-Object TimeCreated, Id, Message

# Find all critical events across multiple logs
Get-WinEvent -FilterHashtable @{
    LogName = 'Application','System'
    Level   = 1  # Critical
} -MaxEvents 50 | Select-Object TimeCreated, LogName, Id, ProviderName, Message

Step 5: Create Custom Views in Event Viewer

Custom Views are saved filters that appear in the Event Viewer navigation pane for quick access. Creating custom views for common administrative scenarios dramatically speeds up daily log review.

To create a Custom View via the GUI: Right-click Custom Views, select Create Custom View. In the dialog, configure:

– Logged: Time range (Last hour, Last 24 hours, Last 7 days, custom)
– Event level: Critical, Error, Warning, Information, Verbose
– By log or source: Select specific logs or event sources
– Event IDs: Specific IDs (comma-separated) or ranges (<100)

Create a Custom View via XML for reproducible deployment:

# Export the XML of an existing custom view for documentation
# Right-click custom view > Filter Current Custom View > XML tab

# Example Custom View XML for Service failures
$xml = @'

  
    
      *[System[Provider[@Name='Service Control Manager'] and (Level=1 or Level=2) and TimeCreated[timediff(@SystemTime) <= 604800000]]]
    
  

'@

Step 6: Configure Event Log Properties

By default, Windows event logs are sized too small for production servers. Increase log sizes to retain sufficient history:

# Set Security log to 512 MB and retain oldest events when full (OverwriteAsNeeded)
Limit-EventLog -LogName Security -MaximumSize 512MB -OverflowAction OverwriteAsNeeded

# Set System and Application logs to 256 MB
Limit-EventLog -LogName System -MaximumSize 256MB -OverflowAction OverwriteAsNeeded
Limit-EventLog -LogName Application -MaximumSize 256MB -OverflowAction OverwriteAsNeeded

# Using wevtutil for channels not accessible via Limit-EventLog
wevtutil sl "Microsoft-Windows-TaskScheduler/Operational" /ms:104857600 /rt:true

# Check current log size and retention settings
Get-EventLog -List | Select-Object Log, MaximumKilobytes, OverflowAction, Entries

For the Security log in high-audit environments, consider setting OverflowAction to DoNotOverwrite and implementing a log archiving solution that rotates the log before it fills.

Step 7: Enable Analytical and Debug Channels

Many Windows components have analytic and debug log channels that are disabled by default. These provide extremely detailed diagnostic information:

# List all hidden logs (analytic and debug are hidden by default)
wevtutil el | Where-Object { $_ -like "*Analytic*" -or $_ -like "*Debug*" } | Select-Object -First 20

# Enable a specific analytic log (example: NTLM operational log)
wevtutil sl "Microsoft-Windows-NTLM/Operational" /e:true

# Enable DNS client debug log for troubleshooting
wevtutil sl "Microsoft-Windows-DNS-Client/Operational" /e:true /ms:20971520

# List all currently enabled logs with their sizes
wevtutil el | ForEach-Object {
    $info = wevtutil gl $_ 2>$null
    if ($info -match "enabled: true") {
        [PSCustomObject]@{ Log = $_; Info = ($info | Where-Object { $_ -match "maxSize" }) }
    }
} | Where-Object { $_ } | Select-Object -First 20

Step 8: Key Security Event IDs to Monitor

For security monitoring on Windows Server 2012 R2, the following event IDs are most critical to monitor and alert on:

# Script to check for critical security events
$securityEvents = @{
    4625 = "Failed logon"
    4740 = "Account lockout"
    4728 = "User added to security group"
    4732 = "User added to local group"
    4756 = "User added to universal group"
    1102 = "Audit log cleared"
    4719 = "System audit policy changed"
    4946 = "Firewall rule added"
    4948 = "Firewall rule changed"
    7045 = "New service installed"
}

foreach ($id in $securityEvents.Keys) {
    $count = (Get-WinEvent -FilterHashtable @{
        LogName   = 'Security'
        Id        = $id
        StartTime = (Get-Date).AddHours(-24)
    } -ErrorAction SilentlyContinue).Count

    if ($count -gt 0) {
        Write-Host "$count occurrence(s) of Event $id ($($securityEvents[$id])) in last 24 hours" -ForegroundColor Yellow
    }
}

Step 9: Export and Archive Events

Export events for long-term retention, compliance, or analysis in external tools:

# Export Security log to EVTX file
wevtutil epl Security "C:LogArchiveSecurity_$(Get-Date -Format 'yyyyMMdd').evtx"

# Export filtered events to CSV
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-7) } |
    Select-Object TimeCreated, Id, Message |
    Export-Csv "C:ReportsFailedLogons_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation

# Clear and archive a log (backup before clearing)
wevtutil cl System /bu:"C:LogArchiveSystem_$(Get-Date -Format 'yyyyMMdd').evtx"

Step 10: Connect Event Viewer to Remote Computers

Event Viewer can connect to remote computers to review their event logs without logging in to each server individually:

# In the GUI: Right-click "Event Viewer (Local)" > Connect to Another Computer

# Via PowerShell - query remote event log
Get-WinEvent -ComputerName "Server01" -LogName System -MaxEvents 50 |
    Where-Object Level -le 2 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

# Check multiple servers for recent errors
$servers = @("Server01","Server02","Server03")
foreach ($server in $servers) {
    $errors = Get-WinEvent -ComputerName $server -FilterHashtable @{
        LogName   = 'System','Application'
        Level     = 1,2
        StartTime = (Get-Date).AddHours(-4)
    } -ErrorAction SilentlyContinue
    
    if ($errors.Count -gt 0) {
        Write-Host "$server — $($errors.Count) errors/criticals in last 4 hours" -ForegroundColor Red
        $errors | Select-Object TimeCreated, LogName, Id, Message | Format-List
    }
}

Summary

Event Viewer on Windows Server 2012 R2 provides the primary audit and diagnostic record of everything that occurs on the server. By properly configuring log sizes to avoid premature overwrite, creating Custom Views for commonly reviewed event patterns, and using PowerShell’s Get-WinEvent with FilterHashtable for fast programmatic log analysis, administrators can quickly identify security incidents, service failures, and system errors. Establishing a habit of daily log review using scripted summaries — checking for critical events, failed logins, account lockouts, and service failures — dramatically reduces mean time to detection for security incidents and operational problems alike.