In Windows environments, the sentence “we collect logs” usually translates to: a SIEM agent was deployed and something is flowing. Then an incident hits, and the first question becomes: Is data really flowing, is the right data flowing, is anything missing?
Windows Event Forwarding (WEF), especially in domain-joined enterprise setups, gives you a very practical foundation to centralize critical events without piling on more agent complexity. But WEF’s real value lies less in setup and more in the health and triage discipline around it.
1) Architecture: Collector + Forwarder
The core building blocks of WEF:
- Event Collector: the server (or servers) where the ForwardedEvents log is gathered
- Source Computers (Forwarder): domain members (servers/workstations)
- Subscription: which events, under which conditions, go where?
What you want at enterprise scale:
- avoid being tied to a single collector (HA)
- collect events in tiers rather than “just take everything”
2) Subscription model: Target what’s normal
The most common WEF mistake: drowning the collector by saying “let’s grab as many events as we can.” A more sensible approach:
- Start: authentication, privilege, process, policy change
- Then: expand only as the need shows up
Field rule: forwarding events through WEF that you don’t actually use in your SIEM only generates cost.
3) Health signals: Is WEF actually working?
To operate WEF properly, watch at least these:
- Collector CPU/disk/IO and ForwardedEvents write rate
- “Last forward time” on the forwarder side (heartbeat logic)
- Per-subscription event rate (sudden drop to zero = something broke)
- WinRM service health and TLS/HTTP error rates
Practical check commands (on the collector):
wecutil es(subscription list)wecutil gs <subscription>(subscription details)
On the forwarder (PowerShell):
Get-Service WinRMwinrm quickconfig(basic validation)
4) Triage runbook: The “logs aren’t coming in” complaint
4.1 First 10 minutes
- Is the collector reachable? (network/DNS)
- Is the collector disk full? (the most classic failure mode)
- Is the per-subscription event rate at zero?
- Is WinRM running on the forwarder?
- Did GPO/Policy change recently? (especially firewall/WinRM)
4.2 Most common real cause: silent policy breakage
WEF tends to break “quietly”:
- a firewall rule changed
- WinRM policy got tightened
- a half-finished switch to certificate/HTTPS
- collector capacity filled up and events stopped writing
That’s why you don’t “set and forget” WEF; treat it like a service with a heartbeat and watch it.
5) Operational tips (the ones that matter in production)
- Log the collector itself into your log platform (the collector’s own events are critical)
- Layer your subscriptions:
baseline,security-high,domain-controllers - Build an “expected event” sentinel for critical machines (at least X events per day)
- Test: once a month, generate a controlled test event and validate the chain
Centralized logging via Windows Event Forwarding doesn’t have to replace your SIEM agent; in most organizations the best outcome is hybrid. When you use WEF correctly, the “Windows side is a black box” feeling disappears and incident triage time drops sharply.