Windows Event Forwarding (WEF) gives you centralized log collection with tools that ship in every supported version of Windows. There are no agents to deploy and no licenses to buy: a collector server, a Group Policy Object (GPO), and a subscription are enough to start moving events. That makes WEF one of the most accessible routes to getting Windows logs into one place. It also has hard limits in platform coverage, in resource cost, and in the kinds of data it can carry. This post explains how WEF works, where it serves you well, where it falls short, and how NXLog helps you close each gap.
How Windows Event Forwarding works
WEF is built around subscriptions. A subscription defines which events to collect, using the same XML query syntax that Event Viewer uses, and where to send them. The receiving server is the Windows Event Collector (WEC), also called the Subscription Manager.
Subscriptions run in one of two modes. In source-initiated (push) mode, you configure clients through Group Policy to contact the collector and forward matching events. In collector-initiated (pull) mode, the collector connects to each client instead. Push mode scales better administratively because Group Policy enrolls machines automatically, so you never maintain a client list by hand. Pull mode suits small, fixed sets of servers where the source list rarely changes.
Transport runs over Windows Remote Management (WinRM), Microsoft’s implementation of the WS-Management protocol. Connections are mutually authenticated and encrypted with Kerberos by default, with NTLM as a fallback. For machines that cannot join the domain, HTTPS with certificate-based authentication is available. Before transmission, the client renders each event as XML; you can forward events with or without localized message strings to keep payloads smaller. By default, events are pre-rendered on the forwarder, so they remain readable at the collector even when the originating event provider is not installed there.
A minimal push setup needs a single Group Policy setting on the clients:
-
Navigate to Computer Configuration > Administrative Templates > Windows Components > Event Forwarding > Configure target Subscription Manager.
-
Add your WEC server URL:
Server=http://wec.example.com:5985/wsman,Refresh=1200The
Refreshvalue sets how often, in seconds, clients re-check the subscription configuration. -
Apply the policy with
gpupdate /force, and clients with matching events begin forwarding to the collector.
Where WEF earns its place
If your environment runs on Windows and you have no centralized collection at all, WEF is the fastest way out of the dark. Local-only logging means an attacker with administrator rights can clear the trail on the machine itself. Forwarding events off the host preserves that evidence.
Three strengths stand out:
- It is built in
-
There is no third-party software to install on endpoints, no dependencies to patch, and no per-endpoint license cost.
- It scales administratively
-
Group Policy enrolls thousands of machines into a subscription without per-host configuration.
- Microsoft documents the strategy
-
Microsoft’s intrusion detection guidance describes a baseline subscription that collects a core set of security events from every host, and a targeted subscription that gathers richer detail from hosts you suspect are compromised.
Forwarded events land in the collector’s Forwarded Events channel, where Event Viewer and any tool that reads the Windows Event Log can work with them. For a small or mid-sized, all-Windows environment with modest log volume, that may be everything you need.
Where Windows Event Forwarding runs out of road
WEF only works with Windows
WEF is incompatible with syslog and every other log transport. Linux servers, network devices, and appliances cannot forward to a WEC, and a Windows machine cannot forward via WEF to a non-Windows destination. In a hybrid environment, you are forced to run two collection pipelines side by side.
NXLog removes that constraint. With the Windows Event Collector input module, NXLog Agent acts as a Windows Event Collector on any supported platform, including Linux and containers. The same NXLog Agent instance can receive syslog messages, so a single collector serves both streams. That matters most when installing an agent on every source is not an option, and you still want a single collection point for the whole network. The following configuration, accepts WEF connections over HTTPS (the port is configurable; this example uses 5985, but you can just as well use 5986, the conventional WinRM HTTPS port):
<Input windows_events>
Module im_wseventing
ListenAddr 0.0.0.0
Port 5985
Address https://wec.example.com:5985/wsman
HTTPSCertFile %CERTDIR%/agent-cert.pem
HTTPSCertKeyFile %CERTDIR%/agent-key.pem
HTTPSCAFile %CERTDIR%/ca.pem
<QueryXML>
<QueryList>
<Query Id="0">
<Select Path="Security">*</Select>
<Select Path="System">*</Select>
</Query>
</QueryList>
</QueryXML>
</Input>If the collector is joined to your domain, Kerberos authentication is also supported.
WEF costs more resources than it appears to
WS-Management is a SOAP-based protocol, so every event is serialized into XML before it leaves the source. On busy systems, especially domain controllers, the serialization work and WinRM overhead add up, even when your query filters down to a subset such as the Security log. Filtering in the subscription query reduces what crosses the network, but the source still pays the cost of evaluating, rendering, and serializing each matching event, and domain controllers generate Security log volumes that keep this pipeline under sustained load.
Reliability can also degrade without warning. Microsoft’s troubleshooting documentation records that on Windows Server 2019, when a machine has more than 3.5 GB of RAM, WinRM and the Event Collector service run in separate svchost processes, and event forwarding may stop working in the default configuration. A collector that fails this way raises no alarm; events simply stop arriving.
Be careful with products that advertise WEC support, but only read events from the Forwarded Events channel on a Windows collector. In that design, the built-in WEC service first writes each event to the Windows Event Log, and the product then reads it back out. The disk and CPU do the work twice, and you still need a licensed Windows server in the middle. NXLog implements the collector protocol natively, so no intermediate write is needed. And because NXLog Agent runs on Linux and in lightweight containers, the collector tier also avoids the base OS requirements of a Windows server.
For high-volume sources, collect at the source instead. The Event Log for Windows input module in NXLog Agent reads the Windows Event Log API directly and filters events before anything crosses the network:
<Input windows_events>
Module im_msvistalog
<QueryXML>
<QueryList>
<Query Id="0">
<Select Path="Security">*[System[Level<=3]]</Select>
</Query>
</QueryList>
</QueryXML>
</Input>No forwarding for events outside Windows Event Log
WEF carries only what lives in Windows Event Log, and that excludes more than you might expect.
- Event Tracing for Windows (ETW)
-
Event Viewer can display Analytic and Debug channels, but that data flows through ETW, which WEF cannot subscribe to. NXLog Agent collects ETW providers directly with the Event Tracing for Windows input module.
- Flat files and databases
-
Application logs written to disk and audit records stored in Microsoft SQL Server are out of WEF’s reach.
- Windows DNS Server logging
-
DNS analytical and debug logging is a frequent monitoring requirement that WEF cannot deliver, because the high-volume analytical data comes through ETW rather than the event log channels WEF can subscribe to.
Limited visibility into the pipeline itself
WEF gives you few tools for operating the pipeline.
There is no delivery confirmation to your final destination, and no alerting when a source goes quiet.
Checking source health means querying subscription runtime status with wecutil collector by collector, and diagnosing a failed forwarder means reading the Event-ForwardingPlugin operational channel on the affected host.
Filtering happens only at the query level: you cannot transform, enrich, or reformat events before they reach storage or a SIEM. If your destination charges by ingested volume, forwarding raw rendered XML is an expensive default.
NXLog handles this at the collection layer. You can parse forwarded events into structured fields, drop noise, convert Windows Event Log to syslog or JSON, and route the result directly to most SIEM products.
WEF, agents, or both?
There is no single right answer, and the two data collection modes are not mutually exclusive.
WEF alone is a reasonable fit for smaller, all-Windows environments with modest volume, where the baseline subscription covers your security monitoring needs.
Agent-based collection makes sense for domain controllers and other high-volume servers, for data outside the Windows Event Log, and wherever you need filtering or enrichment before shipping. Installing NXLog Agent on Windows takes one MSI package.
The hybrid pattern combines the two: workstations push events over WEF to an NXLog Agent collector running as a Windows Event Collector, servers run NXLog Agent locally, and both streams converge in one pipeline. Group Policy continues to enroll workstations exactly as before; nothing changes on the client side. If you manage agents at scale, NXLog Platform handles configuration and monitoring of the whole fleet.
Going beyond Windows Event Forwarding
WEF remains what it has always been: a capable, no-cost baseline for centralizing Windows logs and far better than leaving events scattered across hosts. Its boundaries have not moved either. It speaks only to Windows, it carries only the Windows Event Log, and it offers little control over volume, format, or delivery.
NXLog Agent lets you keep the parts of WEF that work, such as Group Policy enrollment and agentless push from workstations, while removing the constraints. You gain a collector that runs on any platform, support for ETW, files, and databases, and processing that turns raw events into data your SIEM can use at a volume you can afford.
Our documentation includes ready-to-use configurations for every scenario in this post. If you would like to test these capabilities yourself, you can request a trial or contact us with your questions. We are happy to help.
