--- title: "Stop Silent Event Loss at Scale with Windows Event Collector" description: "Enterprise Windows Event Collector architecture: subscription types, XPath optimization, capacity planning, and SIEM integration at scale." canonical: "https://adamtheautomator.com/windows-event-collector-architecture/" --- # Stop Silent Event Loss at Scale with Windows Event Collector > Enterprise Windows Event Collector architecture: subscription types, XPath optimization, capacity planning, and SIEM integration at scale. Source: https://adamtheautomator.com/windows-event-collector-architecture/ --- ATA Learning Tap to hide [ ATA Learning ](/) * [Home](/) * [Tutorials](/tutorials/) * [Instructors](/author/) * [Advertising](/advertising/) * [Recommended Resources](/resources/) * [About Adam](/about-adam/) Search for: * [](https://twitter.com/adbertram) * [](https://github.com/Adam-the-Automator) * [](https://www.linkedin.com/company/adam-the-automator-llc) * [](/feed/) ![Stop Silent Event Loss at Scale with Windows Event Collector](https://adamtheautomator.com/wp-content/uploads/2026/04/featured_image-18.webp) # Stop Silent Event Loss at Scale with Windows Event Collector [![](https://secure.gravatar.com/avatar/d0b9d42e21e5622713f8b693aa5c0f9244d5f7dd200ed29b8398f52dee5de337?s=192&d=mm&r=g)Adam Bertram](https://adamtheautomator.com/author/adam-bertram/)22 April 20269 min. read Categories: [Information Security](/category/infosec/) Tags:[Active Directory](/tag/active-directory/)[Group Policy](/tag/group-policy/)[Security](/tag/security/)[Windows Events](/tag/windows-events/) Table of Contents * [How Windows Event Forwarding Works](#how-windows-event-forwarding-works) * [Collector-Initiated vs. Source-Initiated Subscriptions](#collector-initiated-vs-source-initiated-subscriptions) * [Event Delivery Optimization](#event-delivery-optimization) * [Capacity Planning: The Math You Can’t Ignore](#capacity-planning-the-math-you-cant-ignore) * [EPS Thresholds and Hardware Sizing](#eps-thresholds-and-hardware-sizing) * [Scaling Beyond 4,000 Endpoints](#scaling-beyond-4000-endpoints) * [XPath Query Optimization](#xpath-query-optimization) * [A Practical XPath Example](#a-practical-xpath-example) * [XPath Gotchas Worth Knowing](#xpath-gotchas-worth-knowing) * [SIEM Integration Architecture](#siem-integration-architecture) * [Operational Gotchas at Scale](#operational-gotchas-at-scale) * [The WinRM SDDL Bug (Windows Server 2016/2019)](#the-winrm-sddl-bug-windows-server-20162019) * [NETWORK SERVICE Can’t Read Security Logs](#network-service-cant-read-security-logs) * [Registry Bloat from WEF Bookmarks](#registry-bloat-from-wef-bookmarks) * [What a Complete Enterprise Architecture Looks Like](#what-a-complete-enterprise-architecture-looks-like) Your SIEM is only as good as what reaches it. And if you’re running Windows Event Forwarding (WEF) without a properly sized Windows Event Collector (WEC) architecture, a significant portion of your security telemetry is silently disappearing before it ever hits a log. No alerts. No forensic trail. Just gaps where attackers love to hide. You’ve probably treated WEC like a toggle—flip it on, point a GPO at a server, call it done. That works until you hit scale. At 500 endpoints, that “good enough” architecture starts to crack under the weight of concurrent WinRM connections, XPath queries that forward everything, and a `ForwardedEvents` log capped at its default 20 MB. At 2,000 endpoints, it’s actively losing events. At 5,000, you’re operating blind and don’t know it yet. This post covers what an enterprise WEC architecture actually looks like: the subscription model decision you get wrong once, the math behind capacity limits, XPath optimization patterns that cut event volume by half without sacrificing visibility, and how to connect WEC to your SIEM without deploying agents to every endpoint. ## How Windows Event Forwarding Works [Windows Event Forwarding (WEF)](https://learn.microsoft.com/en-us/windows/win32/wec/windows-event-collector) is a native Windows feature that centralizes event logs from endpoints to a dedicated collection server. No third-party agents required. WEF has two roles. The endpoint runs the `Eventlog-ForwardingPlugin` service, which packages and ships matching events as a forwarder. The Windows Server runs the `WecSvc` service, acting as subscription manager and writing incoming events to the `ForwardedEvents` channel. Communication between forwarder and collector runs over [WinRM](https://learn.microsoft.com/en-us/windows/win32/winrm/portal)—specifically HTTP on TCP port 5985 or HTTPS on port 5986. For domain-joined endpoints, Kerberos handles mutual authentication and encrypts the payload at the application layer, even over plain HTTP. For non-domain endpoints ([Entra-joined devices](https://learn.microsoft.com/en-us/entra/identity/devices/overview), remote systems), you need HTTPS with TLS client certificates. A **subscription** is the configuration object that defines which events to collect, how often to deliver them, and which endpoints are authorized forwarders. That subscription decision is where most enterprise deployments go wrong. ### Collector-Initiated vs. Source-Initiated Subscriptions There are two subscription modes. One scales. One doesn’t. **Collector-initiated (pull):** The WEC server holds a static list of endpoints and actively polls each one for events. This requires inbound WinRM firewall rules on every endpoint and explicit read permissions for the WEC’s computer account on every endpoint’s event logs. At 50 endpoints it’s annoying. At 500 it’s unmanageable. At scale, the polling overhead consumes enough CPU and connection state on the WEC server to meaningfully degrade performance. **Source-initiated (push):** The subscription is defined on the WEC server, but endpoints initiate the connection themselves. A [Group Policy Object (GPO)](https://learn.microsoft.com/en-us/windows/win32/wec/setting-up-a-source-initiated-subscription) pushes the WEC server’s URI into the `SubscriptionManager` registry key on each endpoint. Endpoints connect on their own schedule, authenticate via Kerberos, pull their subscription parameters, and push matching events. For environments with 500 or more endpoints, source-initiated subscriptions are the only viable architecture. The WEC server operates passively—it doesn’t maintain a target list, doesn’t poll, doesn’t need firewall rules to push connections outward. Access control happens through Active Directory groups listed as “Allowed Forwarders” in the subscription configuration. Adding 1,000 endpoints to forwarding is a matter of adding computers to an AD security group, not editing a subscription file. ### Event Delivery Optimization Subscriptions have three delivery modes that trade latency against resource consumption: | Mode | Batch Timeout | Use Case | | --- | --- | --- | | Normal | 15 minutes | General operational logging | | Minimize Bandwidth | 6 hours | Branch offices with limited WAN | | Minimize Latency | 30 seconds | SOC / SIEM real-time detection | Security operations centers should use **Minimize Latency**. Waiting 15 minutes to see a lateral movement event isn’t detection—it’s documentation. The tradeoff is that 30-second heartbeats multiply the number of concurrent WinRM connections, which directly drives memory consumption on the WEC server. That’s a hardware planning input, not a reason to tolerate latency. ## Capacity Planning: The Math You Can’t Ignore A single WEC server has hard limits that [Microsoft documents](https://learn.microsoft.com/en-us/windows/win32/wec/windows-event-collector) and most administrators discover the wrong way. ### EPS Thresholds and Hardware Sizing The foundational metric is **events per second (EPS)**. In practice, a standard Windows workstation with a reasonable audit policy generates roughly 10-50 EPS. Domain controllers and IIS servers generate significantly more. A WEC server should be sized to handle no more than [**3,000-5,000 EPS sustained**](https://learn.microsoft.com/en-us/windows/security/threat-protection/use-windows-event-forwarding-to-assist-in-intrusion-detection), with disk I/O as the most frequent bottleneck. Microsoft’s [baseline recommendation](https://learn.microsoft.com/en-us/windows/security/threat-protection/use-windows-event-forwarding-to-assist-in-intrusion-detection) is **2,000-4,000 endpoints per WEC server** under normal conditions. With heavily optimized XPath filtering, some integrators report scaling a single collector to 10,000 endpoints—but that assumes excellent filter coverage and leaves no fault tolerance headroom. Plan for 4,000 as your ceiling before adding another WEC node. Hardware minimums for a WEC server managing 2,000-4,000 endpoints: | Resource | Minimum | Notes | | --- | --- | --- | | CPU | 4 cores | WecSvc and WinRM are multi-threaded | | RAM | 16 GB | Each concurrent WinRM session holds connection state; 4,000 clients across 5-7 subscriptions can push WecSvc above 4 GB alone | | Storage | Dedicated high-speed disk | 3,000+ IOPS write throughput; never share with the OS volume | The storage point is worth emphasis. The `ForwardedEvents` log [default size is approximately 20 MB](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wevtutil). Twenty megabytes. At 3,000 EPS that’s full in seconds. Relocate `ForwardedEvents.evtx` to a dedicated disk immediately, set the log to several gigabytes, and configure it to **archive when full** rather than overwrite. Archiving creates dated `.evtx` snapshots (`Archive-ForwardedEvents-2025-10-25.evtx`) rather than silently discarding older events. ### Scaling Beyond 4,000 Endpoints WinRM’s Kerberos authentication breaks standard network load balancers. If a Service Principal Name (SPN) doesn’t match the actual hostname terminating the connection, authentication fails. This eliminates F5 and HAProxy as straightforward options. The practical solution is AD-level distribution: partition your endpoint fleet across Active Directory security groups, each pointing to a distinct WEC server via GPO. An environment with 10,000 workstations and three WEC servers might look like this: * `WEF-Group-A` (3,334 computers) → GPO references `WEC-Server-01` * `WEF-Group-B` (3,333 computers) → GPO references `WEC-Server-02` * `WEF-Group-C` (3,333 computers) → GPO references `WEC-Server-03` If a WEC server goes offline, only its subset of endpoints loses real-time forwarding. The endpoints buffer locally (up to your local event log size limit) and resume from their bookmark position when the server returns—no duplicate events, no permanent gaps. * * * **_Key Insight: WEF clients use a bookmarking mechanism to track the last successfully forwarded event. If a WEC server goes offline, clients buffer locally and resume exactly where they left off on reconnect. This means local event log size directly determines your recovery window. Size accordingly._** * * * For true redundancy, you can publish multiple WEC server URIs in a single GPO. Clients forward to all of them simultaneously. This doubles EPS load on your SIEM and requires deduplication logic—a real tradeoff that’s worth knowing before you reach for it reflexively. ## XPath Query Optimization Windows endpoints are noisy. A domain controller running a standard audit policy generates process creation events (Event ID 4688), account logon events (Event ID 4624), and network connection events at rates that will exhaust an unoptimized WEC server within hours. Forwarding everything is not a strategy. WEF uses a subset of the [W3C XPath 1.0 standard](https://learn.microsoft.com/en-us/windows/win32/wes/consuming-events) for filtering. Subscriptions support two XPath operators: * **`` clause If an event matches both Select and Suppress, Suppress wins. This is the basis of noise reduction. ### A Practical XPath Example Collecting successful interactive logons while suppressing machine account and service account noise: ``` *[EventData[Data[@Name='TargetUserName']='SYSTEM']] or *[EventData[Data[@Name='TargetUserName']='LOCAL SERVICE']] ``` ### XPath Gotchas Worth Knowing The WEF XPath engine has constraints that don’t apply in other XPath contexts: **No regex, no wildcards.** You can’t use `*` for partial string matching or regular expressions for pattern matching. Exact string matches only. **The** **`!=`** **operator is deceptive.** Because Windows events are XML documents with multiple `` nodes, `Data != 'SYSTEM'` evaluates to true if _any_ data node in the event doesn’t equal ‘SYSTEM’—which is almost always true. Use `` to exclude unwanted events rather than negation logic in `