How to Configure IIS Web Server on Windows Server 2022

How to Configure Event Viewer and Windows Event Logs on Windows Server 2022

Windows event logging is the primary diagnostic and audit mechanism in Windows Server 2022. Every significant system event — a service crash, a failed logon, a new process starting, a user account being created — generates an event record that is stored in a structured binary log file. Understanding how to read, filter, export, and centralize those logs is a core skill for server administration, incident response, and compliance auditing. This guide covers the Event Viewer console, PowerShell-based log queries, audit policy configuration, Windows Event Forwarding, and the key security event IDs every administrator should recognize.

Opening Event Viewer

Launch Event Viewer by running eventvwr.msc from Run, PowerShell, or a Command Prompt. You can also open it from Server Manager under Tools → Event Viewer, or by right-clicking the Start button and selecting Event Viewer.

eventvwr.msc

The left pane of Event Viewer is a tree with several top-level nodes. “Windows Logs” contains the classic log channels that have existed since Windows Vista. “Applications and Services Logs” contains role-specific and application-specific logs organized in a deeper hierarchy. “Subscriptions” is used for Windows Event Forwarding (WEF).

The Classic Windows Log Channels

The five channels under Windows Logs are the most important for daily administration:

Application: Events logged by applications and services running on the system. IIS, SQL Server, scheduled tasks, and custom applications write here. Default maximum size is 20 MB.

Security: Audit events — logon successes and failures, privilege use, object access, account management changes, process creation. This log requires the SeSecurityPrivilege right to read, which means only Administrators and users explicitly granted that right can access it. Default maximum size is 128 MB on Server 2022.

Setup: Events related to Windows setup, servicing, and component installation. Useful for diagnosing update failures.

System: Events from Windows kernel components and system services — hardware failures, driver issues, service start/stop events, NTP synchronization results. Default maximum size is 20 MB.

Forwarded Events: Events received from remote computers via Windows Event Forwarding subscriptions. Empty by default.

Reading Logs with Get-EventLog

Get-EventLog is the older of the two PowerShell event log cmdlets and works only with the classic Windows Logs channels (Application, Security, System). It is simpler to use for quick queries.

# List available classic logs
Get-EventLog -List

# Get the last 20 errors from the System log
Get-EventLog -LogName System -EntryType Error -Newest 20

# Get all Critical and Error events from the last 48 hours
Get-EventLog -LogName System -EntryType Error,Warning -After (Get-Date).AddHours(-48)

# Search for a specific event ID
Get-EventLog -LogName Security -InstanceId 4625 -Newest 50

# Search by source application
Get-EventLog -LogName Application -Source "MSSQLSERVER" -Newest 30

Querying Logs with Get-WinEvent

Get-WinEvent is the modern cmdlet and works with all event channels — including the deep Applications and Services Logs tree — not just the classic five. It supports XPath queries and structured hash-table filters, making it far more powerful for complex queries.

# Get the last 10 events from the Security log
Get-WinEvent -LogName Security -MaxEvents 10

# Use a hash table filter for efficient queries (processed server-side)
Get-WinEvent -FilterHashtable @{
    LogName   = "Security"
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
}

# Query a specific channel in Applications and Services Logs
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 50

# Filter by multiple event IDs
Get-WinEvent -FilterHashtable @{
    LogName = "Security"
    Id      = 4624, 4625, 4634
    StartTime = (Get-Date).AddHours(-6)
} | Select-Object TimeCreated, Id, Message

For large logs, always use -FilterHashtable rather than piping to Where-Object. The hash table approach passes the filter to the Event Log service itself, which processes it in the binary log file. The Where-Object approach retrieves all events into PowerShell first and then filters, which is dramatically slower on logs with hundreds of thousands of events.

Using XPath Queries with Get-WinEvent

XPath queries give you the most granular control. Event Viewer generates XPath for you: filter events visually, then click the XML tab in the Filter Current Log dialog to see the generated XPath.

# Find logon events where the LogonType is 3 (network logon)
$xpath = "*[System[EventID=4624] and EventData[Data[@Name='LogonType']='3']]"
Get-WinEvent -LogName Security -FilterXPath $xpath -MaxEvents 100

# Find process creation events for a specific executable
$xpath = "*[System[EventID=4688] and EventData[Data[@Name='NewProcessName']='C:WindowsSystem32cmd.exe']]"
Get-WinEvent -LogName Security -FilterXPath $xpath -MaxEvents 50

Creating Custom Views in Event Viewer

Custom Views let you create saved filters that appear in the left pane of Event Viewer for quick access. Right-click Custom Views → Create Custom View. The dialog lets you specify time range, event level, event sources, event IDs, and keyword text. After creating the view, it saves as an XML file in %SystemRoot%System32winevt and persists across reboots.

You can also create a custom view programmatically by placing an XML file with the view definition in the correct location. The XML format uses the same XPath structure that Get-WinEvent accepts:

  
    
      
    
    
      Security Failures Last 24h
      
        
          
            *[System[(Level=2 or Level=3) and TimeCreated[timediff(@SystemTime) <= 86400000]]]
          
        
      
    
  

Configuring Audit Policies with auditpol

By default, many audit categories on Windows Server 2022 are not enabled. The Security log only records events for categories that are actively audited. Configure audit policy with the auditpol command-line tool or through Group Policy.

# View the current audit policy for all categories
auditpol /get /category:*

# Enable auditing of Logon/Logoff events (success and failure)
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Logoff" /success:enable

# Enable process creation auditing (required for Event ID 4688)
auditpol /set /subcategory:"Process Creation" /success:enable /failure:enable

# Enable object access auditing
auditpol /set /subcategory:"File System" /success:enable /failure:enable
auditpol /set /subcategory:"Registry" /success:enable /failure:enable

# Enable account management auditing
auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable /failure:enable

# Export the current policy to a file for backup
auditpol /backup /file:C:Backupauditpol-backup.csv

# Restore from backup
auditpol /restore /file:C:Backupauditpol-backup.csv

In a domain environment, configure audit policy through Group Policy: Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies. The subcategory settings in Group Policy override the legacy category settings.

Key Security Event IDs to Monitor

These are the event IDs most critical for security monitoring on Windows Server 2022:

4624 — Successful Logon: Records every successful authentication. The LogonType field distinguishes interactive (2), network (3), batch (4), service (5), network cleartext (8), and remote interactive (10). Type 3 logons from unexpected sources are a common lateral movement indicator.

4625 — Failed Logon: Records every failed authentication attempt. A sudden spike in 4625 events from a single source IP is a brute-force indicator. The FailureReason and SubStatus fields clarify whether the failure was due to a wrong password, a disabled account, or an expired account.

4688 — New Process Created: Records every new process start, including the full command line if that audit subcategory is also enabled. Essential for detecting living-off-the-land attacks that use built-in tools like powershell.exe -EncodedCommand, wmic, or certutil for malicious purposes.

4720 — User Account Created: Records whenever a new local or domain account is created. Attackers often create persistence accounts; unexpected 4720 events are a critical alert.

4732 — Member Added to Security-Enabled Local Group: Triggers when a user is added to a local group such as Administrators. Monitor for additions to the Administrators and Remote Desktop Users groups.

4776 — NTLM Authentication Attempt: Records NTLM credential validation on domain controllers. Useful for detecting NTLM relay attacks and identifying systems still using NTLM where Kerberos should be used.

# Query for all failed logon attempts in the last hour
Get-WinEvent -FilterHashtable @{
    LogName   = "Security"
    Id        = 4625
    StartTime = (Get-Date).AddHours(-1)
} | ForEach-Object {
    $xml = [xml]$_.ToXml()
    [pscustomobject]@{
        Time        = $_.TimeCreated
        AccountName = $xml.Event.EventData.Data | Where-Object {$_.Name -eq "TargetUserName"} | Select-Object -Expand '#text'
        SourceIP    = $xml.Event.EventData.Data | Where-Object {$_.Name -eq "IpAddress"} | Select-Object -Expand '#text'
        LogonType   = $xml.Event.EventData.Data | Where-Object {$_.Name -eq "LogonType"} | Select-Object -Expand '#text'
    }
}

Exporting and Clearing Event Logs

Export event logs to .evtx format for archiving or sharing with support:

# Export the Security log to an .evtx file
wevtutil epl Security C:LogsSecurity-$(Get-Date -Format yyyyMMdd).evtx

# Export using the Event Viewer GUI: right-click any log → Save All Events As...

# Clear a log (requires appropriate permissions)
wevtutil cl Application

# Clear a log and save it first
wevtutil cl Security /bu:C:LogsSecurity-backup-before-clear.evtx

Windows Event Forwarding (WEF)

Windows Event Forwarding allows a central collector server to pull or receive events from many source machines without deploying additional agent software. All transport uses WinRM. There are two subscription types: source-initiated (sources push events to the collector) and collector-initiated (the collector pulls from specified sources).

# On the COLLECTOR server: start and configure the Windows Event Collector service
wecutil qc /q

# On the SOURCE server: configure WinRM and add the collector's computer account
winrm quickconfig -q
# In a domain: use Group Policy to add the Collector computer account to the
# BUILTINEvent Log Readers group on all source computers

# Create a subscription on the collector (source-initiated)
wecutil cs subscription.xml

# List all subscriptions
wecutil es

# Show details of a specific subscription
wecutil gs "Forwarded Security Events"

# View runtime status of a subscription
wecutil gr "Forwarded Security Events"

The subscription XML file defines which events to collect, the source computers or computer groups, the transport protocol, and the destination log. Events arrive in the Forwarded Events log on the collector. For large environments, consider using a dedicated collector server and configuring a custom event channel with a larger maximum log size.

Configuring Log Size and Retention

# Set the Security log maximum size to 512 MB and overwrite oldest when full
wevtutil sl Security /ms:536870912 /rt:false

# Set the System log to 128 MB
wevtutil sl System /ms:134217728

# View current log configuration
wevtutil gl Security | findstr "maxSize logFileName"

For compliance environments (PCI-DSS, HIPAA, SOX), size the Security log to hold at least 90 days of events locally, and configure forwarding to a SIEM. Event log size requirements depend on your logon volume — a busy domain controller generating 10,000 events per hour needs a much larger log than a file server with 100 events per hour.