Windows Event Log Forwarding (WEF) is one of those things that sounds simple until you actually try to set it up reliably at scale. Here’s what I’ve learned from deploying it in a real environment.
Table of contents
Open Table of contents
What WEF Is
WEF is the Windows-native mechanism for centralising event logs from multiple machines to a single collector without installing a third-party agent. It uses WS-Management (WinRM) under the hood.
The two main components:
- Windows Event Collector (WEC): the machine that receives logs. Runs the
wecsvcservice. - Source computers: any Windows machine you want to collect logs from. They push events to the collector.
There are two subscription models:
- Source-initiated: source computers push to the collector. Better for scale — you configure it via Group Policy and machines find the collector themselves.
- Collector-initiated: the collector pulls from source machines. Easier to set up for small environments.
Most enterprise deployments use source-initiated. That’s what I’ll focus on here.
Basic Setup
1. Configure the collector
Run on the WEC server:
wecutil qc /qThis enables the Windows Event Collector service and sets it to start automatically.
Ensure WinRM is running:
winrm quickconfig2. Configure sources via Group Policy
Create a GPO applied to the machines you want to forward from. Under:
Computer Configuration > Administrative Templates > Windows Components > Event Forwarding
Set Configure target Subscription Manager to:
Server=http://your-collector.domain.com:5985/wsman/SubscriptionManager/WEC,Refresh=60The Refresh value is in seconds — how often sources check in.
Also enable WinRM on source machines:
Computer Configuration > Windows Settings > Security Settings > System Services
Set Windows Remote Management (WS-Management) to Automatic.
3. Create a subscription
On the WEC server, open Event Viewer > Subscriptions > Create Subscription.
For source-initiated subscriptions, the machines will show up here once they’ve checked in via GPO.
Configure your XPath query to select the events you care about. Don’t forward everything — you’ll drown in noise. Focus on:
- Security events: 4624, 4625, 4648, 4688 (with process tracking), 4698–4702 (scheduled tasks)
- System events: 7045 (new service), 104 (log cleared)
- PowerShell: 4103, 4104 (script block logging)
Common Problems
Sources not showing up on the collector
Check:
- GPO applied? Run
gpresult /ron the source - WinRM running on source?
Get-Service winrm - Firewall allowing port 5985 (HTTP) or 5986 (HTTPS)?
- The collector’s computer account needs to be in the Event Log Readers group on source machines — or use a dedicated service account
Events dropping under load
The default WEF configuration has small batch sizes. For high-volume environments, tune the subscription:
<BatchSizeItems>50</BatchSizeItems>
<MaxLatencyTime>30000</MaxLatencyTime>Also watch the WEC server’s disk I/O — the Security log on a busy collector grows fast.
Clock skew causing missed events
WEF uses timestamps from source machines. If clocks drift, you’ll get events out of order or gaps. Ensure NTP is consistent across your environment. In AD environments this is usually handled automatically; in workgroup environments it often isn’t.
Getting Logs into Sentinel
Once you have a WEC collecting events, get them into Microsoft Sentinel via the Windows Security Events data connector with the Azure Monitor Agent (AMA). Point AMA at the WEC rather than installing it on every source machine.
This is significantly cheaper than deploying MMA/AMA to every endpoint if you already have WEF set up.
What to Monitor
The subscription is only useful if someone’s actually looking at the logs. Useful Sentinel analytic rules to layer on top of a WEF deployment:
- Multiple failed logons followed by success (brute force indicator)
- New scheduled task creation
- PowerShell script block logging with encoded commands
- New service installation (
7045) from non-standard paths
WEF gives you the raw material. The detection logic is where the real work is.