What is Windows Event Forwarding?

What is Windows Event Forwarding?

Windows Event Forwarding is a built-in Windows feature that collects event logs from distributed computers and stores them on a designated Windows Event Collector server. Microsoft introduced WEF in Windows Server 2008, and it uses the WS-Management protocol (implemented by the Windows Remote Management service) as its transport layer.

Without centralized logging, security events sit isolated on individual machines. When an incident happens, you have to connect to each workstation or server one at a time and dig through its local event log for the entries you care about. WEF fixes this by pushing or pulling events to a single collection point where you can review them in Event Viewer or pass them to a downstream tool.

WEF doesn't require third-party agents. It relies entirely on the built-in WinRM service running on source computers and a subscription configuration on the collector that defines which events to gather and from where.

How Windows Event Forwarding works

WEF's architecture has four components that work together to move events from source machines to the central collector.

Architecture components

Source computers are the machines that generate events and send them to the collector. Any Windows machine with WinRM enabled can act as a source.

The Windows Event Collector (WEC) is the server that receives forwarded events and writes them to a local event log channel (typically "Forwarded Events"). You designate this role by running wecutil qc on the collector.

Subscriptions are XML-defined rules that specify which events to collect, from which sources, and how frequently. Each subscription defines an event query (using XPath), the delivery mode, and the transport protocol.

WinRM (Windows Remote Management) is the transport protocol that carries events between sources and the collector over HTTP (port 5985) or HTTPS (port 5986).

Subscription types

Source-initiated subscriptions are the standard choice for enterprise deployments. You configure a single GPO that tells all domain-joined machines where to send their events. Collector-initiated subscriptions require you to add each source computer to the subscription by hand, which gets impractical past a few dozen machines.

Configuration requirements

You need five things in place before WEF will start forwarding events:

1. WinRM enabled on all source computers (run winrm quickconfig or deploy via GPO).
2. A GPO defining the subscription manager URL so sources know which collector to contact.
3. Network connectivity on HTTP port 5985 or HTTPS port 5986 between sources and collector.
4. Event channel permissions configured on source machines (the Network Service account needs read access to the Security log).
5. Audit policies enabled on source machines to generate the events you actually want to forward.

Event delivery modes

WEF supports four delivery optimization modes that control how frequently events move from source to collector:

Normal mode is the default. For security monitoring, you'll typically switch to Minimize Latency, but expect higher network and CPU overhead on both source and collector machines.

Windows Event Forwarding vs. syslog forwarding

WEF is a Windows-native solution that preserves the full XML structure of Windows events. Syslog forwarding converts Windows events into syslog text format (RFC 5424) for consumption by non-Windows log management platforms.

If your environment is Windows-only and you plan to review events in Event Viewer on the collector, WEF is sufficient. If you need to feed events into a Linux-based SIEM or a centralized log manager that expects syslog input, you'll need a third-party forwarder running on the WEC server or directly on source machines.

Security risks of inadequate log forwarding

When event logs stay isolated on individual machines without central collection, you lose visibility into exactly the activity that attackers count on going unnoticed.

Blind spots in incident detection

Failed logon events (Event ID 4625) on workstations never reach the security team if those workstations don't forward their Security log. Password spray campaigns deliberately spread failed attempts across many machines to stay below lockout thresholds. Without centralized collection, each machine sees only one or two failures, and no single console reveals the coordinated pattern.

Log tampering and destruction

An attacker with local administrator access on a compromised machine can clear the Security event log (Event ID 1102) before defenders review it. If events were never forwarded off-box, that evidence is gone permanently. Centralized forwarding creates a second copy the attacker can't reach without also compromising the collector.

Lateral movement goes undetected

Pass-the-hash and pass-the-ticket attacks generate logon events (Event IDs 4624 and 4648) on the target machine. If that machine's logs aren't forwarded, the lateral movement trail is invisible to anyone reviewing only the domain controller logs. Attackers count on this gap.

Compliance gaps

PCI-DSS Requirement 10 mandates centralized log collection with defined retention periods. HIPAA's Security Rule requires audit controls that record and examine activity in information systems containing protected health information.

ADAudit Plus addresses these blind spots by collecting security events directly from all configured domain controllers, member servers, and workstations without requiring WEF infrastructure. It correlates events against a behavioral baseline using machine learning to surface anomalies like unusual logon volume or first-time host access.

Limitations of native Windows Event Forwarding

WEF solves the basic problem of getting events off individual machines, but it introduces its own operational headaches once you try to build a security monitoring workflow on top of it.

No real-time alerting

WEF collects events but gives you no way to fire an alert when something critical happens. You still have to open Event Viewer on the collector and search through forwarded events manually, or cobble together custom Task Scheduler triggers that fire on specific Event IDs. There's no built-in way to send an email or SMS when a privileged account gets locked out or when a burst of failed logons hits a domain controller.

No correlation or analytics

WEF forwards raw events without context. Correlating a spike in Event ID 4625 (failed logon) with a subsequent Event ID 4624 (successful logon) from the same source IP takes manual analysis or a separate SIEM. WEF can't detect patterns like "50 failed logons from different accounts against the same server in three minutes, followed by one success," which is the fingerprint of a password spray attack.

WEC server scalability limits

Microsoft's own documentation notes practical limits around 10,000 source computers per WEC server, with throughput of 2,000 to 4,000 events per second depending on hardware. Enterprises with tens of thousands of endpoints need multiple WEC servers, each with its own subscription management, storage planning, and monitoring overhead.

No scheduled report delivery

WEF has no reporting engine. If you want a weekly failed logon summary or a monthly compliance report, you're writing custom PowerShell scripts or bringing in a separate tool. You can't schedule a "top 10 locked-out accounts this week" report and have it emailed to the help desk every Monday morning with WEF alone.

Complex GPO and subscription management

Each subscription requires XML authoring with XPath event queries. Changes to audit scope mean GPO modifications, Active Directory replication, and gpupdate cycles across the domain. Testing a new subscription against a subset of machines before rolling it domain-wide is cumbersome and easy to get wrong.

No cross-platform support

WEF works only with Windows sources. If your environment includes Linux servers, network appliances, or cloud workloads like Microsoft Entra ID (previously known as Azure Active Directory (Azure AD)), you need a completely separate collection mechanism for those event sources. WEF can't give you a unified view across hybrid infrastructure.

No retention management

Forwarded events land in the Forwarded Events channel on the collector, subject to the same log size and overwrite policies as any local event log. Long-term retention for compliance (PCI-DSS requires one year online; SOX requires up to seven years) means you have to build your own archiving pipeline on top of WEF.

Monitoring AD events with ADAudit Plus

ADAudit Plus collects Active Directory events directly from domain controllers and configured servers using an agent-based architecture. You don't need to configure WEF subscriptions, WinRM, or collector servers. Events flow into a centralized console with over 300 pre-configured reports, real-time alerts, and machine-learning-driven anomaly detection.

What ADAudit Plus monitors

ADAudit Plus covers the same event categories that WEF collects, plus the correlation and analytics that WEF can't provide:

• All logon and logoff events across domain controllers, member servers, and workstations (Event IDs 4624, 4625, 4634, 4647, 4648, 4768, 4769, 4771, 4776)
• AD object changes: user, group, computer, OU, GPO, schema, DNS, and permission modifications with before-and-after values
• File server access: reads, writes, deletes, and permission changes across Windows file servers and 13 NAS platforms
• Account lockout events with root cause identification via the Account Lockout Analyzer
• Group Policy setting changes with old and new values for each modified setting
• Detection of 25+ AD attack indicators via the Attack Surface Analyzer, including Kerberoasting, Golden Ticket attack, DCSync attack, pass-the-hash attack, and password spray attacks
• User behavior analytics: machine-learning baselines per user and host, with anomaly alerts for unusual logon volume, unusual time, or first-time resource access

Native WEF vs. ADAudit Plus

FAQ