Windows Event Forwarding Setup for Centralised Logs

0 Comments 10 min read

Knowing which event IDs to watch is half the job; getting them off every endpoint before the local Security log wraps is the other half. Windows Event Forwarding setup is the native, no-agent, no-cost way to do it — and it is what feeds nearly every SIEM-native Windows pipeline, including Microsoft Sentinel. This post is the build we use internally: source-initiated subscriptions, a Windows Server 2022 collector, and the Group Policy that wires the endpoints in.

Key Takeaways

  • Source-initiated subscriptions scale better than collector-initiated for anything past a small lab — endpoints push to the collector instead of the collector pulling from each one.
  • The Group Policy SubscriptionManager URL is what tells endpoints where to send events.
  • The collector reads remote logs as NETWORK SERVICE, which means the collector's computer account has to be a member of Event Log Readers on every source.
  • Custom event channels prevent the default ForwardedEvents log from overflowing on a busy collector — split by source type once you pass a few hundred endpoints.
  • Forwarded events keep the original computer name in Event/System/Computer; write queries against that field, not the collector hostname.

Environment

  • Windows Server 2022 acting as the Windows Event Collector (WEC).
  • Windows 10/11 and Windows Server 2019/2022 source machines, joined to the same Active Directory domain.
  • WinRM available on TCP 5985 (HTTP) inside the management network. TCP 5986 (HTTPS) for sources crossing a less-trusted boundary.
  • Group Policy management rights to push the subscription URL, the WinRM service state, and the restricted-groups membership to source machines.
  • PowerShell 5.1 or 7.4 on the collector for verification and ad-hoc queries.

The Problem

A busy domain controller will overwrite its Security log in hours, not days, regardless of the size you give it. 4624 and 4634 alone can generate thousands of events per minute. Trying to retain a week of DC security history on the DC itself is wishful thinking. Third-party log shippers solve this, but they bring agents, licensing, and a software supply chain that has to be vetted before it touches every server in the estate.

Windows Event Forwarding is built in, free, and rides on WinRM — which is already present on every supported Windows release. The trade-off is that the setup is fiddly, the documentation is scattered across several Microsoft Learn pages, and the failure modes are quiet. There are two modes: collector-initiated, where the collector pulls from a hand-listed set of sources, and source-initiated, where sources push to the collector based on Group Policy. Collector-initiated is fine for a handful of servers. Source-initiated is what scales, because new machines start forwarding the moment they apply the GPO and the collector does not have to know they exist beforehand.

The Solution

Step 1 — Prepare the Windows Event Collector

On the collector host, enable the Windows Event Collector service and configure WinRM. Two elevated commands handle both: 

# Run elevated on the collector
wecutil qc /quiet
winrm quickconfig -quiet

wecutil qc sets the Wecsvc service to delayed auto-start, opens the firewall for WinRM, and registers the default WS-Management endpoint. After it completes, the Event Viewer → Subscriptions node becomes usable, and the ForwardedEvents log is ready to receive data.

Resize ForwardedEvents before any traffic arrives. The default 20 MB overflows within minutes once a few dozen domain controllers start pushing 4624s: 

wevtutil sl ForwardedEvents /ms:8589934592   # 8 GB

Step 2 — Grant the collector permission to read remote logs

Source-initiated subscriptions run as NETWORK SERVICE on the collector. NETWORK SERVICE on a remote host authenticates as the collector's domain computer account, so adding that computer object to Event Log Readers on every source is what unlocks read access. The cleanest way is a restricted-groups Group Policy targeting source machines: 

Computer Configuration
 → Preferences
   → Control Panel Settings
     → Local Users and Groups
       → New → Local Group
         Group: Event Log Readers (built-in)
         Action: Update
         Members: DOMAIN\WEC01$

Replace WEC01$ with your collector's computer account. The trailing dollar sign is required — without it, Group Policy will silently match nothing and you will spend an afternoon wondering why subscriptions are reporting "access denied".

Step 3 — Push the subscription URL via Group Policy

The single setting that activates source-initiated forwarding is the subscription manager URL. Under Computer Configuration → Administrative Templates → Windows Components → Event Forwarding → Configure target Subscription Manager, enable the policy and add the entry: 

Server=http://wec01.example.local:5985/wsman/SubscriptionManager/WEC,Refresh=60

A few details that bite first-time deployments:

  • The FQDN must resolve from every source. IP addresses technically work but break the Kerberos authentication WinRM expects by default.
  • Refresh=60 tells the source to re-pull the subscription configuration every 60 seconds. Useful during rollout; raise it to 600 or higher once the fleet is stable.
  • WinRM also has to be running on the source. Set the Windows Remote Management (WS-Management) service startup to Automatic via a service GPO if it is not already.

After a gpupdate /force and a minute or two of patience, each source registers with the collector and appears under Event Viewer → Subscriptions → Source Computers. Microsoft's authoritative reference is on Microsoft Learn: Setting up a Source Initiated Subscription.

Step 4 — Author the Windows Event Forwarding subscription

Subscriptions can be created in the GUI, but XML is the only sane way to manage them at scale. Save the following as baseline.xml on the collector. It pulls the high-signal IDs from our Windows Event IDs reference and drops everything else: 

<Subscription xmlns="http://schemas.microsoft.com/2006/03/windows/events/subscription">
  <SubscriptionId>Baseline-Security</SubscriptionId>
  <SubscriptionType>SourceInitiated</SubscriptionType>
  <Description>Baseline forwarding: auth, account mgmt, process, PowerShell</Description>
  <Enabled>true</Enabled>
  <Uri>http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog</Uri>
  <ConfigurationMode>Custom</ConfigurationMode>
  <Delivery Mode="Push">
    <Batching>
      <MaxItems>20</MaxItems>
      <MaxLatencyTime>30000</MaxLatencyTime>
    </Batching>
    <PushSettings>
      <Heartbeat Interval="60000"/>
    </PushSettings>
  </Delivery>
  <Query>
    <![CDATA[
      <QueryList>
        <Query Id="0">
          <Select Path="Security">
            *[System[(EventID=1102 or EventID=4624 or EventID=4625 or EventID=4648 or
                      EventID=4672 or EventID=4688 or EventID=4720 or EventID=4724 or
                      EventID=4728 or EventID=4732 or EventID=4756 or EventID=4738 or
                      EventID=4698 or EventID=4699 or EventID=4702 or EventID=4719)]]
          </Select>
          <Select Path="Microsoft-Windows-PowerShell/Operational">
            *[System[(EventID=4104)]]
          </Select>
        </Query>
      </QueryList>
    ]]>
  </Query>
  <ReadExistingEvents>false</ReadExistingEvents>
  <TransportName>http</TransportName>
  <ContentFormat>RenderedText</ContentFormat>
  <Locale Language="en-US"/>
  <LogFile>ForwardedEvents</LogFile>
  <AllowedSourceNonDomainComputers></AllowedSourceNonDomainComputers>
  <AllowedSourceDomainComputers>O:NSG:NSD:(A;;GA;;;DC)(A;;GA;;;NS)</AllowedSourceDomainComputers>
</Subscription>

Register it with wecutil cs baseline.xml and confirm with wecutil es. The AllowedSourceDomainComputers SDDL above permits any domain controller (DC) plus NETWORK SERVICE (NS) — narrow it to a specific computer group SID for production. The XPath query is the same shape you would write in Event Viewer's filter dialog; copying a working filter and pasting it inside the Select element is a reliable starting point.

Step 5 — Verify and tune

Events should start landing in ForwardedEvents within a minute. The source computer is in Event/System/Computer, not the collector's name — write queries against that field: 

# Top forwarders in the last hour
Get-WinEvent -FilterHashtable @{
    LogName   = 'ForwardedEvents'
    StartTime = (Get-Date).AddHours(-1)
} |
    Group-Object MachineName |
    Sort-Object Count -Descending |
    Select-Object -First 20 Name, Count

On the source, check the runtime status of the forwarding plugin: 

# Inspect the subscription state from a source machine
wevtutil gl Microsoft-Windows-Forwarding/Operational
Get-WinEvent -LogName 'Microsoft-Windows-Forwarding/Operational' -MaxEvents 20

The two most common failures: WinRM not running on the source (event ID 102 in Microsoft-Windows-Forwarding/Operational), and the collector computer object missing from Event Log Readers on the source (event ID 105, access denied). Both are GPO fixes.

Step 6 — Split high-volume sources into custom event channels

Once you cross a few hundred endpoints, the default ForwardedEvents log churns fast enough that even an 8 GB log only holds a few hours of history. The fix is custom event channels: write a provider manifest, compile it with ecmangen, register it on the collector, and target separate subscriptions at separate logs — for example WEC-Auth, WEC-Process, and WEC-PowerShell. Each log gets its own size budget, retention policy, and query surface. Palantir's windows-event-forwarding repository on GitHub has production-grade manifests and subscription XMLs worth borrowing as a starting point.

Frequently Asked Questions

Should I use HTTP or HTTPS for Windows Event Forwarding?

Inside an Active Directory domain, HTTP on TCP 5985 is already encrypted end-to-end by Kerberos and authenticated by the machine accounts on both sides. HTTPS on 5986 only adds value when sources are non-domain or cross an untrusted boundary, and that path also requires client certificates provisioned on every source. For a domain-joined fleet, HTTP is the documented default and the simpler operational choice.

Do I need a SIEM if I have Windows Event Forwarding?

Not strictly. A WEC collector with adequate log sizing and a few PowerShell queries handles ad-hoc incident response and small environments fine. A SIEM adds correlation across sources, longer retention, alerting, and search beyond just Windows logs. WEF is what feeds the SIEM in most native deployments — Microsoft Sentinel's Azure Monitor Agent, for example, can ingest forwarded events directly from a WEC.

Why are some events missing from forwarded logs even though they appear locally?

Three usual suspects: the event ID is not in the subscription's XPath query; the source has not yet refreshed the subscription configuration (wait for the Refresh interval to elapse); or the source denies read access to Event Log Readers. Run wecutil gr SUBSCRIPTION_NAME on the collector for the per-source heartbeat and last-error code, which usually points straight at the cause.

How big should the ForwardedEvents log be?

Budget at least 100 MB per active source per day at the baseline event set above. For a fleet of 500 endpoints, that is roughly a 50 GB log to retain a single day — which is the point at which custom event channels start paying for themselves. Domain controllers push significantly more volume than member servers, so split them out first.

Can I forward events from workgroup (non-domain) machines?

Yes, but with significantly more work. WinRM has to be configured with client certificates on the source, a matching certificate authority has to be trusted by the collector, and the source thumbprint has to be added to AllowedSourceNonDomainComputers in the subscription. For more than a handful of non-domain sources, an agent-based shipper is usually cheaper than maintaining the certificate plumbing.

Conclusion

Windows Event Forwarding is one of the more useful native Windows features that almost nobody enables until they have to. The setup is tedious — multiple GPOs, an XML subscription, an SDDL string — but everything is built in, costs nothing, and survives both the collector and the SIEM being swapped out for something else. Once it is running, the rest of the Windows-side detection stack quietly assumes it is there.

If we had to pick the single highest-leverage thing to do after configuring audit policy, this would be it. Centralised logs make every other monitoring decision — log retention, correlation rules, hunting queries — significantly easier.

Related Posts

0 comments:

Post a Comment