Windows event log size and retention is one of those settings nobody thinks about until an incident hits and the events that would have closed the investigation rolled off the channel three days ago. The defaults — 20 MB for most channels, circular overwrite — are sized for a desktop running Word, not for a Domain Controller hosting fifty Kerberos events per second. This post is the configuration we apply to every Windows server we build before it sees production traffic.

Key Takeaways

• The default 20 MB Security log on a busy Domain Controller can roll over in hours. Plan for 1–4 GB on DCs and at least 256 MB on workstations.
• Three retention modes matter: Circular (default, overwrites oldest), AutoBackup (rolls into an archive file), and Retain (refuses new events when full).
• Configure size and retention with wevtutil sl for any channel, or Limit-EventLog for the classic logs only. Manage at scale with Group Policy under Computer Configuration → Administrative Templates → Windows Components → Event Log Service.
• Disk space is cheap relative to forensic value. Size the log to hold at least the audit window your incident response process requires — 30 days is a sensible floor.
• Forward critical logs to a central collector with Windows Event Forwarding or a SIEM. Local sizing is a fallback, not the strategy.

Environment

• Windows Server 2019/2022 (Domain Controllers, member servers) and Windows 10/11 workstations.
• Windows PowerShell 5.1 or PowerShell 7.4.
• Local administrator rights — every command below modifies a system-scope setting.
• Group Policy editing rights if rolling out across the estate.

The Problem

The Windows event log defaults were last sensibly sized when servers had 4 GB of RAM and a 36 GB SCSI disk. A modern DC writes thousands of 4624 and 4634 events per minute. A 20 MB log holds a few hours of that volume before circular overwrite kicks in and the events you needed last Tuesday are gone. The audit trail Microsoft and your compliance framework assume exists, simply does not.

The fix is two settings, applied per channel: maximum size and retention mode. Get both right once, deploy via GPO, and stop worrying.

The Solution

Step 1 — Inspect the current state

Before changing anything, see what each channel is sized to and how full it is. Get-WinEvent -ListLog returns the same metadata Event Viewer shows under "Properties":

Get-WinEvent -ListLog * |
    Where-Object RecordCount -gt 0 |
    Select-Object LogName,
                  @{Name='SizeMB';    Expression={ [math]::Round($_.FileSize/1MB,1) }},
                  @{Name='MaxMB';     Expression={ [math]::Round($_.MaximumSizeInBytes/1MB,1) }},
                  @{Name='PercentFull';Expression={ [math]::Round(($_.FileSize/$_.MaximumSizeInBytes)*100,1) }},
                  LogMode,
                  IsEnabled |
    Sort-Object PercentFull -Descending |
    Format-Table -AutoSize

Any channel above 80% on a workload you care about is a candidate for resizing. Anything above 95% is already losing events.

Step 2 — Decide the right size per channel

Sizes are a function of event volume and how long you want to retain. As a starting point we use:

• Domain Controller — Security: 4 GB (auth events dominate, very high volume).
• Domain Controller — System / Application: 256 MB each.
• Domain Controller — Directory Service: 1 GB.
• Member server — Security: 1 GB.
• Workstation — Security: 256 MB.
• PowerShell/Operational (everywhere, if script block logging is on): 1 GB.
• Sysmon/Operational (if Sysmon is deployed): 4 GB.

These are starting points, not gospel. Measure rollover frequency on a representative box for one week and adjust.

Step 3 — Resize and change retention with wevtutil

wevtutil works against any channel, classic or modern, and is the only option for the Microsoft-Windows-* channels:

# Set Security log to 4 GB, circular overwrite (the default mode)
wevtutil sl Security /ms:4294967296

# Switch retention to AutoBackup (rolls full log into archive, starts a fresh one)
wevtutil sl Security /ms:4294967296 /rt:false /ab:true

# Set Sysmon to 4 GB
wevtutil sl 'Microsoft-Windows-Sysmon/Operational' /ms:4294967296

# Inspect a single channel
wevtutil gl Security

The /rt:false flag means "do not retain when full" — combined with /ab:true, that produces the AutoBackup mode in Event Viewer. /rt:true on its own produces the Retain mode and is rarely what you want, because it makes Windows refuse new events when the log fills.

Step 4 — Roll out via Group Policy

For more than a handful of machines, configure the settings under Computer Configuration → Administrative Templates → Windows Components → Event Log Service. Each log type (Application, Security, Setup, System) has its own subkey with two settings:

• Specify the maximum log file size (KB) — value in kilobytes; multiply your target MB by 1024.
• Retain old events — set to Disabled for circular, Enabled with Back up log automatically when full for AutoBackup.

Microsoft-Windows-* channels are not directly covered by Administrative Templates. For those, use Group Policy Preferences to push wevtutil commands at boot, or run them from a Desired State Configuration / Ansible / Intune script.

Step 5 — Watch for the channel filling up anyway

Even with generous sizing, runaway logging (chatty third-party drivers, broken auditing policy) can fill a log in minutes. Run a scheduled check that alerts when any channel passes a threshold:

$threshold = 80

Get-WinEvent -ListLog * |
    Where-Object { $_.RecordCount -gt 0 -and $_.MaximumSizeInBytes -gt 0 } |
    ForEach-Object {
        $percent = ($_.FileSize / $_.MaximumSizeInBytes) * 100
        if ($percent -ge $threshold) {
            [PSCustomObject]@{
                Host        = $env:COMPUTERNAME
                LogName     = $_.LogName
                PercentFull = [math]::Round($percent,1)
                SizeMB      = [math]::Round($_.FileSize/1MB,1)
                MaxMB       = [math]::Round($_.MaximumSizeInBytes/1MB,1)
            }
        }
    }

Schedule the script every 15 minutes and pipe the output into your existing alerting channel. If a log is over the threshold consistently, either bump the size or fix the upstream noise source.

Step 6 — Export important channels before destructive changes

Any size change keeps existing events, but log clearing does not. Always export first if there is any chance you will need the historical data:

$dir = 'C:\LogArchive'
New-Item -ItemType Directory -Path $dir -Force | Out-Null

wevtutil epl Security "$dir\Security_$(Get-Date -Format 'yyyyMMdd_HHmm').evtx"
wevtutil epl 'Microsoft-Windows-PowerShell/Operational' "$dir\PSOperational_$(Get-Date -Format 'yyyyMMdd_HHmm').evtx"

The exported .evtx opens directly in Event Viewer and is queryable with Get-WinEvent -Path.

Frequently Asked Questions

What is the default size of the Windows Security log?

20 MB on modern Windows. On a Domain Controller that holds a few hours of authentication events. The setting has not been revisited in many Windows generations.

Should I use Circular, AutoBackup, or Retain mode?

Circular for workstations and member servers — old events disappear, no human intervention required. AutoBackup on Domain Controllers and audited servers — full logs roll into archive files for later analysis. Retain only when a compliance requirement explicitly forbids overwrite; expect operational pain when logs fill.

Will increasing the log size affect performance?

No measurable impact during normal operation; the log file is memory-mapped and writes are append-only. The cost is disk space and a slightly slower startup for the Event Log service on very large files.

Where does Windows store the actual log files?

%SystemRoot%\System32\winevt\Logs\. Each channel is a .evtx file named after the channel. Both space planning and backup design should account for that path.

Is forwarding logs better than local retention?

For incident response and long-term audit, yes. Windows Event Forwarding (free, built-in) or a SIEM agent ships events to a central collector you can query and back up independently. Local retention remains useful for the gap between event generation and forwarding, and for offline analysis.

Conclusion

Sizing event logs is a one-time setup task that pays off the first time you actually need the data. The defaults are wrong for any server doing real work, the GUI is fine for a single host, and Group Policy plus wevtutil covers the rest of the estate. Pair this with central forwarding, schedule a fullness check, and move on. The events will be there when you need them.

Related Posts

• PowerShell Quick Guide: Working with Event Logs Like a Pro — the query side of the same problem, once the events are actually preserved.
• Essential Windows Event IDs for Security Monitoring — which events you should be retaining in the first place.
• Windows Security: Best Practices for Securing Windows Services — broader Windows hardening guidance.

Reference for the underlying utility: wevtutil on Microsoft Learn.

Editorial note: posts on this blog are drafted with AI assistance and then reviewed, edited, and tested against a real environment before publishing. Commands, output, and screenshots come from systems I actually ran the work on.