Measure Windows Event Forwarding health—not just collector uptime

Bottom line: Windows Event Forwarding (WEF) reads selected events from Windows devices and sends them to a Windows Event Collector. Microsoft presents baseline and suspect subscriptions as a way to balance coverage and volume. Operational trust requires proof of enrollment, filtering, delivery latency, capacity, retention, and downstream ingestion.

Source fact: what Microsoft documents

Microsoft’s WEF intrusion-detection guidance describes forwarding selected operational and administrative events from organizational devices. The reference design uses a baseline subscription for broad enrollment and a suspect subscription for devices needing more context.

The document covers source-initiated subscription design, collector configuration, event-selection considerations, delivery settings, security, and collector sizing concepts. It explains that WEF forwards events already generated on sources; it does not itself enable every audit category or create missing telemetry. Subscription queries, source configuration, WinRM, permissions, network access, collector capacity, and downstream handling all affect what arrives.

What the source does not establish

WEF does not guarantee lossless delivery, normalize events into detections, protect the collector from compromise, or preserve logs for a required retention period by itself. A healthy Windows Event Collector service does not prove that every expected endpoint is enrolled. Event volume estimates from one environment do not establish capacity for another. Forwarded events also remain only as useful as source audit policy and clock quality.

Applicability questions

• Which security and operational questions must the forwarded events answer?
• Which workstations, servers, domain controllers, segmented networks, remote devices, and intermittent systems are expected sources?
• Are required audit policies and event channels enabled on each source class?
• What delivery latency, outage buffer, collector capacity, retention, and downstream SIEM availability are required?
• How will a device be promoted to and removed from a higher-volume suspect subscription?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Define the minimum event set from investigation and detection needs, then validate source audit policy generates it.
2. Separate broad baseline collection from time-bounded high-context collection for suspect systems.
3. Inventory expected sources and reconcile them with subscription runtime state. Alert on never-seen, stale, and persistently failing sources.
4. Generate controlled canary events on representative devices and measure source-to-collector and collector-to-SIEM delay.
5. Capacity-test collectors, protect administration and stored logs, and document failover, backlog, and recovery behavior.

Verification and evidence

• Preserve subscription XML, source targeting, collector configuration, query changes, and approvals.
• Record expected versus active sources, last event time, delivery failures, queue state, and canary latency.
• Demonstrate required events from every device class and confirm downstream parsing retains key fields.
• Exercise collector outage and restoration without assuming queued events will always cover the gap.

Official references

• Use Windows Event Forwarding to help with intrusion detection — Microsoft