Windows Event Forwarding (WEF) Collector Configuration

Purpose

This guide explains how to collect Windows event logs in Logsign USO with the built-in Windows Event Forwarding (WEF) collector, from an empty configuration to events arriving in the platform. Windows ships its own event logs to Logsign over WinRM, which is already installed on every Windows machine, so no third-party agent is installed on the source.

Microsoft calls this model a source-initiated subscription. If you search Microsoft's documentation for background, that is the term to use. Plan about 30 minutes for the first machine.

How It Works

The single most important point, because everything else follows from it: the Windows machine connects to Logsign. Logsign never connects to Windows. The forwarder asks who the collector is (Identify), asks what it should send (Enumerate), and then posts its events, all over HTTPS on port 5986.

Three consequences:

• Port 5986/tcp must be open inbound on the Logsign appliance, not on the Windows machines.
• There is no "test connection" button for this source type, because there is nothing for Logsign to connect to. You verify the setup by looking at what arrives.
• The Windows machine identifies itself with a client certificate. No username or password is used anywhere in this flow, and no service account is created.

Three certificates are involved, each with a different job. Getting these straight before you start prevents most first-time failures:

Prerequisites

Collect the following before you open the Logsign interface, because the first value in the list is written into the server certificate and is difficult to change afterwards.

• The address Windows machines will use to reach Logsign. An IP address or a DNS name. On a cluster this is the VIP, not a single node. Write it down: it goes into the server certificate and must match exactly everywhere afterwards.
• A Logsign user with device management permission, so the Add Device page is available.
• Local Administrator on the Windows machine you start with. This is needed only to run the enrollment script; the forwarder itself then runs as NETWORK SERVICE, and no domain administrator account or service account password is involved.
• Network path: the Windows machine can reach <logsign-address>:5986/tcp, and the appliance allows that traffic inbound.
• Licensing: WEF sources consume the same license quota as WMI sources. Check that you have room before onboarding a large fleet.

Address format matters. Enter the collector address as a bare host or IP, exactly as Windows will dial it. Correct: 10.0.0.5 or collector.example.com. Wrong: https://10.0.0.5, 10.0.0.5:5986 or collector.example.com/. The value is written into the certificate's subjectAltName and into the subscription URL, and a mismatch here is the single most common cause of a setup that never works.

Start with one Windows machine. Do not touch Group Policy until that machine is delivering events.

This collector is available as of Logsign USO version 6.4.115. If your instance is on an earlier build, upgrade before starting.

Choosing a Certificate Path

Path A, Logsign issues the certificates. Use this if the organization has no certificate authority, or if you simply want the integration working. Logsign becomes a small CA that issues WEF certificates only, and nothing else in the environment is affected by it. Steps 1 to 6 below describe this path.

Path B, your own CA (Active Directory Certificate Services). Use this if you run AD CS and want to keep certificate issuance in your own PKI. The benefits are real: client certificates reach machines through autoenrollment, and revocation works. See the section "Using Your Own CA" near the end of this guide.

If you are unsure, use Path A. You can move to Path B later, which means replacing the certificates and re-enrolling the machines, but nothing else changes.

Step 1: Generate the Collector Certificates

1. Go to Settings > Add Device and select WEF as the device type.
2. In the Collector address field, enter the address from your prerequisites list, in the bare format described above.
3. Click Generate certificates.

Logsign creates a CA and a server certificate, stores them, and starts serving HTTPS on port 5986 with them. No service restart is required. The page then shows two values you will need later:

• Issuer CA Thumbprint, a 40 character hexadecimal string.
• The subscription URL, in the form Server=https://10.0.0.5:5986/wsman/SubscriptionManager/WEC,Refresh=60,IssuerCA=A66DDD87.... The Refresh=60 part means each machine re-reads its subscription every 60 seconds.

Do not click Regenerate certificates on a running installation without planning for it. Every machine already enrolled stops delivering events until the new package is installed on it. Logsign warns you and asks for confirmation first, and the warning tells you how many enrolled machines are affected.

Step 2: Register the Windows Machine as a Device

Continue on the same form.

Host defines which machines are allowed to send. Three formats are accepted:

Anything connecting from outside the configured addresses is refused. For your first machine, enter its single IP address.

Channels defines which Windows logs to collect. The defaults (Security, Application, System) are a sensible start. Add more by typing the channel name and pressing Enter, for example Microsoft-Windows-Sysmon/Operational.

The channel name must match the Windows channel name exactly. To find it on the machine, run wevtutil el and search the output, or open Event Viewer, right-click the log, choose Properties, and copy the Full Name field. A misspelled channel does not produce an error: it is simply silent, and each channel is advertised as its own subscription, so a wrong name affects only that one channel.

Fill in the remaining standard fields (description, data policy) and save the device.

Step 3: Download the Enrollment Package

In the Windows enrollment package section of the WEF form, type the computer name of your machine (for example SRV-FILE-01) and click Download package. You receive wef-SRV-FILE-01.zip containing:

The PFX password is random and is shown only in README.txt. Treat the ZIP as a credential, because it identifies that machine to your SIEM: transfer it over a secure channel and delete it from the Windows machine once the installation is finished.

Generate a separate package per machine. The certificate carries the computer name, and one package per machine is what makes the per-machine statistics meaningful.

Step 4: Run the Installer on Windows

Copy the ZIP to the machine and extract it. Open PowerShell as Administrator, change into the extracted folder and run:

powershell -ExecutionPolicy Bypass -File .\install.ps1

The script prints six steps. What each one does, and why, because you will eventually have to do them by hand on a machine where the script cannot run:

1. Imports ca.crt into Trusted Root. Without it the machine does not trust the collector's server certificate and the TLS connection fails.
2. Imports client.pfx into LocalMachine\My. This is the machine's identity.
3. Grants NETWORK SERVICE read access to the private key. The forwarder runs as NETWORK SERVICE. If it cannot read the key it cannot present the certificate, and the subscription silently never activates.
4. Grants access to the Security channel. By default NETWORK SERVICE cannot read the Security log, so the script edits the channel's SDDL directly. Advice you will find online often suggests adding NETWORK SERVICE to the Event Log Readers group instead. Avoid that: the group is renamed on localized Windows (Turkish, German and others) and net localgroup matches the name literally, so the command appears to succeed and does nothing. The SDDL form is language independent.
5. Writes the subscription URL into HKLM\SOFTWARE\Policies\Microsoft\Windows\EventLog\EventForwarding\SubscriptionManager. This is what tells the machine where to send its logs.
6. Restarts WinRM so the forwarder picks up the new configuration immediately.

Step 6 can take several minutes on a busy machine, in particular on a domain controller, and WinRM sits in StopPending while it finishes its current work. This is expected. The script tolerates it and makes sure the service comes back up. You do not have to wait for it: the forwarder re-reads its subscription every 60 seconds regardless.

Step 5: Verify

Open the device you created and look at the Forwarding machines table. It lists every machine that delivered to this source in the last 30 minutes:

This table is the fastest way to answer "is this machine still sending?" for a source registered as a subnet, where the device level counters lump every machine together.

Then search the platform for events from the machine. WEF events are stored with EventSource.Collector set to wef, EventSource.IP set to the forwarding machine's address, and EventSource.HostName set to the computer name.

Rolling Out to a Fleet with Group Policy

Once one machine works, two things change when you scale up.

Register the network, not the machines. Change the device's Host field from a single address to the subnet or range covering your machines, for example 10.0.0.0/24. Do not create one device per workstation: WEF fleets are hundreds of machines with DHCP addresses, and the per-machine breakdown lives in the Forwarding machines table instead.

Distribute the configuration with GPO. install.ps1 configures one machine; for a domain, do the same three things centrally:

1. Trust the CA. Distribute ca.crt through Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities.
2. Point the forwarders at the collector. Computer Configuration > Policies > Administrative Templates > Windows Components > Event Forwarding > Configure target Subscription Manager > Enabled > Show, and add the subscription URL from Step 1.
3. Give the forwarder access to the Security channel. Either run the SDDL command from step 4 of the installer through a startup script, or configure it centrally under Computer Configuration > Policies > Administrative Templates > Windows Components > Event Log Service > Security > Configure log access.

Then run gpupdate /force on a test machine and watch the Forwarding machines table.

Client certificates still have to reach each machine. On Path A that means one enrollment package per machine, which does not scale beyond a few dozen. That is exactly the problem Path B solves.

Using Your Own CA (AD CS)

If you run Active Directory Certificate Services, let it issue the certificates.

On your PKI:

1. Issue a server certificate for the collector, with the Server Authentication EKU and a subjectAltName containing the collector address from your prerequisites list.
2. Enable autoenrollment for a Computer template carrying the Client Authentication EKU, so every domain machine receives a client certificate automatically.

On Logsign:

1. On the WEF form, paste three PEM blocks into Server Certificate, Server Private Key and CA Certificate. Logsign validates them together before saving and refuses a certificate whose key does not match, a certificate the CA did not issue, or a certificate with no subjectAltName. Each of those failures would otherwise appear on the Windows side only as a forwarder that never enrolls.
2. The page then shows the issuer thumbprint derived from the CA you pasted. Use it in the GPO subscription URL exactly as described above.

The Windows enrollment package section disappears in this mode. Logsign does not hold your CA private key, so it cannot issue client certificates, and that is the intended behaviour. Everything else, including device registration, channels and verification, is identical.

Troubleshooting

Windows records forwarding errors in Event Viewer under Applications and Services Logs > Microsoft > Windows > Eventlog-ForwardingPlugin > Operational. Open that first, because it usually names the problem.

Useful commands on the Windows side:

wevtutil el                                                        # list every channel
Get-ChildItem Cert:\LocalMachine\My | Format-List Subject,Thumbprint,NotAfter
Get-ItemProperty HKLM:\SOFTWARE\Policies\Microsoft\Windows\EventLog\EventForwarding\SubscriptionManager
Get-WinEvent -LogName Microsoft-Windows-Eventlog-ForwardingPlugin/Operational -MaxEvents 20
Restart-Service Winrm -Force                                       # can take several minutes

Notes and Limits

• Delivery is at-least-once. The collector acknowledges a batch only after every event in it has been handed to the processing pipeline, and a batch it cannot accept is refused so Windows re-sends it. A retry may therefore duplicate events, which is the safer of the two failure modes.
• A machine with nothing to report still checks in through a heartbeat every 900 seconds, so silence in the Forwarding machines table for much longer than that means the machine is genuinely not talking to the collector.
• Certificate lifetimes on Path A: the CA is valid for 10 years, server and client certificates for 825 days. Plan re-enrollment before client certificates expire.
• Per-machine statistics are retained for 7 days. The noisier counters (rejected requests and requests from unregistered addresses) are retained for 1 day.
• WEF sources consume the same license quota as WMI sources, so a large fleet must be sized against that quota.
• An unregistered sender belongs to no device, so it does not appear in any device's Forwarding machines table. It is visible only in the unfiltered host list.
• Acknowledgement means the events were handed to the processing pipeline, not that they are already written to disk.