Windows Event Forwarding (WEF) Collector Setup - Basic (Logsign PKI)

Collect Windows event logs without installing an agent. Logsign issues the certificates and you install a single package on each machine. Only the user interface on the Logsign side, PowerShell on the Windows side.

Screenshots come from a sample environment; machine names, IP addresses, definition names and the CA name will differ in yours. Replace the <angle-bracket> placeholders in the text with your own values. Field and button names are written exactly as they appear in the product interface.

Purpose

Collect the event logs of Windows machines (Security, Application, System, Sysmon, PowerShell…) centrally in Logsign without installing any agent, using Windows' built-in Event Forwarding (WEF) mechanism.

This guide describes the Logsign PKI route: Logsign issues the certificates and you install one package on each machine. This is the right route when the organisation has no certificate infrastructure of its own and the number of machines is limited. The setup is completed entirely through the user interface plus a few PowerShell commands on the machine.

⚠ If you run your own certificate infrastructure (Active Directory Certificate Services) and want the certificates distributed automatically to every domain machine by Group Policy, use the WEF Setup Guide - Advanced instead. The two routes replace each other; do not run both on the same machine. You can start with this guide and move to the other one later.

How it works

The Windows machine connects to Logsign; Logsign never connects to Windows. Microsoft calls this a "source-initiated subscription". The WinRM service already installed on every machine dials the collector address it has been given over 5986/tcp, asks "what should I send?" (it receives a subscription) and delivers its logs itself. The machine proves its identity with a client certificate; there is no username or password anywhere in this flow.

Windows (WinRM) ──HTTPS 5986──▶ Logsign WEF collector ──▶ parser → search screen

On the Logsign side the model has two layers. First you create a definition: a name, an IP scope, default channels, a default data policy, a health check and a certificate mode. When a machine inside the scope reaches the collector for the first time, it appears in the definition's Clients table as pending (amber). When you click Enable on that row, a source record specific to that machine is created, one device licence slot is consumed and the row turns enabled (green). Only from that moment does the machine receive a subscription and start sending logs.

Natural consequences of that direction:

• 5986/tcp must be open on the Logsign side, not on the Windows machines.
• Logsign cannot "test the connection" to a machine; there is nothing to connect to. You verify the setup by looking at what arrives.
• A row in the Clients table is not proof that the Windows side is ready. The order is: first the certificate and the definition on the Logsign side (Steps 1-2), then the Windows side (Step 3), and Enable last (Step 4).

Three certificates, three different jobs:

Prerequisites

• A Logsign user: an account with device management permission that can see the Settings → Integrations → Windows Event Forwarding page. Enable needs the device management permission; Disable and Forget delete the machine's source record, so the profile also needs the device deletion permission (delete_settings_device_list); without it the action fails with HTTP 403 "…needs the delete_settings_device_list permission". For certificate renewal (Regenerate) the signed-in user must be a super admin; the password alone is not enough. The warning dialog appears when you click Save.
• The address the Windows machines will use to reach Logsign: an IP or a DNS name. In a cluster this is the shared (float/VIP) address, not a single node. This address is written into the server certificate and must be used identically everywhere afterwards.
• Network path: every Windows machine must be able to reach <collector-address>:5986/tcp. Do not test this port before Step 1: the port stays closed until the certificates are generated, and being closed is normal. Testing early returns TcpTestSucceeded : False and sends you hunting for a firewall for nothing.
• Windows permissions: local administrator on the machine where you install the package. No domain-admin rights and no Group Policy access are needed.
• Windows version: Windows Server 2012 R2 and later / Windows 10 and later (PowerShell 5.1). Server 2012 R2 has no Get-LocalGroupMember/Add-LocalGroupMember cmdlets; on those machines do the same job with net localgroup "Event Log Readers" (on a localised Windows, with the group's local name). On 2016 and later the cmdlets are present.
• Licensing: every machine you enable consumes one device slot. pending rows consume nothing. Once the quota is full, Enable is refused in the interface with the message "Maximum device limit reached". Check how many free slots you have before onboarding a fleet (compare the total device count at the top of Settings → Data Collection with your licence). If the licence limit is not visible in the interface, confirm it with Logsign support.
• Start with one machine. Do not move on to the others until the first one is delivering events; the package is installed per machine, so mistakes are fixed per machine too.

Step 1 - Collector certificate

On both paths Logsign issues the collector's server certificate. This step is independent of any definition and is done once. Until it is complete, port 5986 stays closed.

Open the Settings → Integrations → Windows Event Forwarding page. With no definitions yet the page reads "No WEF definitions yet."; the Certificates panel on the page shows a Generate certificates button.

The Certificates panel (sample environment, after setup): Collector address, the button, Issuer CA Thumbprint (SHA1) and the unlabeled subscription line. On a first install the button reads Generate certificates and the thumbprint is empty.

1.1 · Check and correct the Collector address field

The Collector address field is mandatory and comes pre-filled with the hostname from your browser's address bar. If the value is already correct, leave it alone; otherwise replace it with the address the Windows machines will use to reach Logsign, the IP or DNS name you chose under Prerequisites. Confirm it from a Windows machine: if you chose a DNS name, check that Resolve-DnsName <address> resolves it; if you chose an IP address, skip that check, the command returns nothing for an IP. Either way Test-NetConnection <address> -Port 443 must succeed. In a cluster, enter the shared (float/VIP) address, not a single node's. This value:

• is written into the server certificate's CN/SAN (Windows compares the address it dials against the address in the certificate);
• is the source of the subscription line; the line that tells Windows "come here" is derived from it.

⚠ Choose the address correctly, then do not change it. If the machines will reach the collector by IP, enter the IP; if by DNS name, enter the DNS name. A wrong address produces no error whatsoever on the Windows side; the forwarder simply never enrolls. Changing the address later means a new certificate, and therefore a new CA (see If the collector address changes).

1.2 · Generate certificates → Save

Click Generate certificates. On its own this button produces nothing; it only records the intent. The certificates are generated and written when you click the Certificates panel's Save button. In the panel's own words: "Save writes the new certificates. Nothing changes before that." The only visible result of clicking Generate is that the button turns orange and Save becomes enabled; in the dark theme the warning band underneath is hard to read.

Click Save. Within roughly 15 seconds the collector opens port 5986.

You should see: after Save, two new values appear in the panel: Issuer CA Thumbprint (SHA1) (the fingerprint of Logsign's CA, 40 hex characters) and, right under it, an unlabelled read-only box holding the subscription line: it starts with Server=https://…:5986/wsman/SubscriptionManager/WEC,Refresh=60,IssuerCA=… and carries the hint "Set this value in Group Policy: Computer Configuration → …" (the box itself has no label; the term "subscription URL" appears only in the hint text of the Collector address field). The button is now labelled Regenerate certificates. From a Windows machine, Test-NetConnection <collector-address> -Port 5986 now returns TcpTestSucceeded : True.

If the button reads Regenerate certificates, the certificates have been generated before. If the panel shows a thumbprint and Test-NetConnection <collector-address> -Port 5986 returns True from a Windows machine, Step 1 is already done: leave it alone and go to Step 2. If the thumbprint is there but the port is closed, the PKI is incomplete; with an empty definitions list and no enabled client, Regenerate + Save is safe. With enrolled clients, the warning in 1.4 applies.

1.3 · Note the expiry date

The lifetime of the PKI Logsign issues is fixed: the CA lasts 10 years, the server certificate and the client certificates 825 days. There is no renewal mechanism and no expiry warning. When it expires, every machine goes silent at the same time. The only interface path to renew the server certificate is Regenerate, and that means a new CA: the whole fleet is set up again.

Add 825 days to today's date; put the result in your calendar as a reminder at least one month in advance. If you want to check from a Windows machine, once the machine has enrolled:

Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Issuer -like '*Logsign WEF CA*' } | Select-Object Subject, NotAfter

This command shows the machine's client certificate (it is filled in once the package has been installed). The collector's server certificate is valid for 825 days; count its expiry from the day you did Generate + Save and put it in the calendar.

1.4 · Regenerate certificates: when, and why it is dangerous

⚠ Do not click Regenerate after the setup is done.

Regenerate certificates + Save produces a new CA and a new server certificate. Every client certificate issued by the old CA becomes invalid at that instant: every machine goes silent and the fleet is rebuilt from scratch: a new package is downloaded and install.ps1 is run again on every machine.

The product guards this with two gates: while enrolled clients exist, clicking Save after Regenerate shows a warning ("Generating a new CA will break the N enrolled WEF client(s)…") and asks for the super admin password to proceed; the signed-in user must be a super admin. When you see that warning, stop; unless you are performing a deliberate migration, cancel.

You should see: in the Certificates panel a filled-in Collector address, an Issuer CA Thumbprint (SHA1), the read-only subscription line under it, and a button labelled Regenerate certificates. You will come back to this panel only for a planned certificate renewal.

Step 2 - Create a WEF definition

A definition is a template for an IP scope: the machines that fall inside the scope are listed under this definition and inherit its defaults when they are enabled. On the same page, click New definition.

The create dialog (sample environment) asks for four fields: Name, Scope, Default channels, Excluded event categories. The certificate mode is not here; it is chosen on the definition's form after saving.

2.1 · The create dialog: Name, Scope, Default channels, Excluded event categories

⚠ Scope overlap is not checked. Two definitions may cover the same subnet; the product does not prevent it. A machine appears as pending in the Clients table of every definition whose scope it falls into. Enable it only in the definition you want: the first Enable binds the machine to that definition; an Enable attempt in another definition is refused with "belongs to another definition", and the machine keeps showing as pending there (harmless). 0.0.0.0/0 is also a valid scope; do not type it by accident.

⚠ Narrowing the scope later is refused if it would leave an enabled or disabled machine outside: "Scope <scope> leaves N client(s) outside the definition: <ip…>. Disable and delete them first." Although the message says "Disable and delete", the correct action is Forget; a disabled machine still counts as outside the scope. Move those machines to pending with Forget first, then narrow the scope.

Click the New definition button at the bottom of the dialog (the button is not labelled Save). The definition appears in the list. Click its name; the real settings and the Clients table live on the definition's own form.

The definition form (sample environment): in Logsign PKI mode the Windows enrollment package section is visible.

2.2 · Fields on the definition form

⚠ Inheritance is one-way. Changing the definition's defaults later does not affect existing machines. To roll a new channel out to the fleet you either update each machine from its own card (see Day-to-day operations), or Disable→Enable them, which also resets every per-machine setting back to the defaults.

When the fields are filled in, click the Save button at the bottom of the form. Do not use the Windows enrollment package section before saving; a package downloaded from an unsaved definition carries the old settings.

You should see: the new definition in the list. The Pending counter may be greater than 0: a machine inside the scope that has reached the collector within the last 7 days (for example from an earlier installation) is listed straight away. That is normal. When you open the form again, Default channels shows three tags (Security, Application, System), Default data policy shows the policy you picked and Certificate mode shows Logsign PKI; the Windows enrollment package section is inside the form.

Ignore two texts in the interface: the empty-state text of the Clients table and the hint under the Certificates panel point you at Group Policy. This guide does not use Group Policy; install.ps1 writes the subscription setting into the machine's own registry. The same pointer appears in the package's README.txt.

Step 3 - The installation package and install.ps1

For every machine you download a package from the definition and run it on that machine. A package is machine-specific; never use one machine's package on another.

3.1 · Download the package

Open the definition (click its name in the list). The Windows enrollment package section is on the definition's form, not in the Certificates panel, and it is shown only while Certificate mode = Logsign PKI. Under its heading there is an unlabelled box with the placeholder text WIN-SRV-01 and a Download package button. Type the machine's computer name into the box (not its IP; the name the hostname command returns on Windows) and click Download package. With the box empty the button does nothing and no file is downloaded; the warning message flashes very briefly or may not appear at all. If nothing downloads, first make sure you typed the computer name into the box. The browser downloads wef-<machine>.zip.

Download a separate package for every machine. The client certificate inside is that machine's identity. If you download the package for the same machine a second time, the browser names the file something like wef-<machine> (1).zip. Always use the newest package; if you did Regenerate + Save in the Certificates panel, the ca.crt/client.pfx in older packages belong to the old CA and will not work; delete the old ones.

⚠ Package generation only looks for Logsign's CA. If you see either of these two messages:

• "No collector-managed CA is available. Generate a PKI first" → Step 1 (Generate + Save) has not been done.
• "Save the certificate change first. A package made now would carry the old CA." → there is an unsaved change in the Certificates panel. Save first (or discard the change), then download. The package is produced with the CA in effect at that moment.

The ZIP is a credential. Move it over a secure channel; once the install finishes delete both the ZIP and the folder you extracted it to (Remove-Item C:\wef-setup -Recurse -Force); the README.txt inside carries the PFX password in clear text. Do not put it on shared folders, especially ones readable domain-wide.

3.2 · Run install.ps1

Copy the ZIP to the machine, log in at the console or over RDP, and run it from an elevated (Run as administrator) PowerShell:

Expand-Archive -Force C:\wef-<machine>.zip C:\wef-setup
cd C:\wef-setup
powershell -ExecutionPolicy Bypass -File .\install.ps1

The script prints its steps in order (the line under [4/6] reads Already granted. if the permission is already in the channel SDDL; both are normal):

[1/6] Importing the CA into Trusted Root...
[2/6] Importing the client certificate...
    Imported: <client-certificate-thumbprint>
[3/6] Granting NETWORK SERVICE read access to the private key...
[4/6] Granting access to the Security channel...
    Granted.
[5/6] Pointing the forwarder at the collector...
    Server=https://<collector-address>:5986/wsman/SubscriptionManager/WEC,Refresh=60,IssuerCA=<logsign-ca-thumbprint>
[6/6] Restarting WinRM...
Done. CA thumbprint: <logsign-ca-thumbprint>

⚠ Run the script from a file, and verify afterwards. Copy the ZIP into the RDP session (clipboard or a mapped drive) and run install.ps1 from an elevated PowerShell on the machine with -File, as shown above. If you run it remotely and non-interactively (PowerShell Remoting, an RMM tool, a remote console), prefix the commands with $ProgressPreference='SilentlyContinue'; or run the script as a scheduled task under the SYSTEM account; in a non-interactive session the progress bar (notably Expand-Archive's) can stall the script. If you have no RDP, extract the ZIP on your own machine and copy the four files into a folder on the target machine, then run install.ps1 from there; that way you never reach the Expand-Archive step. Always verify after the run:
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\EventLog\EventForwarding\SubscriptionManager"
(Get-Service WinRM).Status

⚠ The channel hint on the script's last line is out of date. On completion install.ps1 tells you to look at the Eventlog-ForwardingPlugin path in Event Viewer. That path does not exist on modern Windows. The correct channel is Microsoft-Windows-Forwarding/Operational. Look there for errors.

3.3 · What install.ps1 does, and does not do

What it does not do - you complete it:

• Does not grant Event Log Readers membership, and does not grant access to channels other than Security. For the three default channels (Security, Application, System) no extra group action is needed: [4/6] grants NETWORK SERVICE access to the Security channel through its SDDL (the channel's access-descriptor string), and Application and System are readable anyway, on member machines and on Domain Controllers alike. Only if you are going to collect a non-default channel (Sysmon, PowerShell/Operational, DNSServer/Audit…) add (A;;0x1;;;NS) to that channel's SDDL (wevtutil sl <channel> /ca:…; on a Domain Controller this is the only way, there is no local group) or, on a member machine, grant it through group membership (language-independent, by SID): Add-LocalGroupMember -SID 'S-1-5-32-573' -Member 'S-1-5-20', then Restart-Service WinRM -Force.
• Does not install the software that produces a channel. If Sysmon is in the channel list, Sysmon must be installed on the machine.
• Does not change the WinRM service's startup type. On Windows Server WinRM is already Automatic; just check it: Get-Service WinRM | Select-Object Status, StartType. On Windows 10/11 clients the default is Manual: Set-Service WinRM -StartupType Automatic; Start-Service WinRM

⚠ A machine must not hold more than one Logsign client certificate. If another machine's package was installed by mistake, the forwarder picks a different identity each time, the subscription never settles and not a single event arrives. Check: Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Issuer -like '*Logsign WEF CA*' }: exactly one certificate should remain; remove extras with Remove-Item Cert:\LocalMachine\My\<thumbprint> -DeleteKey.

⚠ If a channel in the channel list does not exist on the machine (e.g. Sysmon not installed), the forwarder raises error 5004 for that channel and keeps creating and tearing down the subscription. Either install the software that provides the channel (Sysmon64.exe -accepteula -i), or after Step 4 remove the channel from that machine's channel list; the definition's Default channels does not affect an existing client.

Is the install complete? Run this on the machine. At this stage you will see ID=105 with code 2150859023 (0x8033810F); that is normal. The event is written not immediately but at the forwarder's next poll (≤60 seconds, sometimes 2 minutes); if the channel is empty when you first look, wait a minute and look again, the machine has not been Enabled yet; one ID=100 per channel arrives after Step 4:

wevtutil qe Microsoft-Windows-Forwarding/Operational /c:10 /rd:true /f:text

If you are looking from a remote/non-interactive session: Get-WinEvent -LogName Microsoft-Windows-Forwarding/Operational -MaxEvents 20 | Format-List TimeCreated,Id,Message; to count, (Get-WinEvent -LogName Microsoft-Windows-Forwarding/Operational | ? Id -eq 100).Count.

You should see: on Windows, Done. CA thumbprint: …; the SubscriptionManager registry key populated; WinRM Running. In Logsign, when you refresh the definition's form, the machine's IP appears in the Clients table as pending (the view is cached for 30 seconds; if it is not there immediately, wait half a minute and refresh). A machine showing as pending on its own does not prove the package was installed: look at the First seen / Last seen columns, which must have been updated in the minutes since the install. Now Step 4.

Step 4 - Enable the machines

When a machine inside the scope reaches the collector, it appears in the Clients table on the definition's form as pending. In that state it sends no logs: the machine reaches the collector but is turned away (per-machine counters of refused requests are not shown in the interface in this version; see 5.2). The Enable button on the row creates that machine's own source record, consumes one device slot, and collection starts. Before Enable, seeing ID=105 in Microsoft-Windows-Forwarding/Operational on this machine is normal; which code you see depends on how far the machine has got: 2150858882 (0x80338082) while the client certificate has not arrived yet, 995 (0x3E3) on transient retries, and 2150859023 (0x8033810F, collector 403) once the certificate is in place and the machine has not been approved yet. Look at the installation itself first: if install.ps1 finished all six steps without an error and the client certificate is on the machine, none of these codes is a fault. After Enable, one ID=100 per channel arrives within 1-2 minutes.

The Clients table (sample environment): machines arrive as pending first; Enable at the end of the row.

Click Enable one row at a time. There is no confirmation dialog and no notification; the row turns enabled (green) by itself within a few seconds. If it does not change, read the red error box under the row. Disable and Forget are equally unconfirmed; a wrong click deletes the machine's settings.

⚠ Enable, Disable and Forget are DESTRUCTIVE: per-machine settings are lost. Disable and Forget do not park the record; they actually delete it. When you Enable again, the record is rebuilt from scratch out of the definition's defaults at that moment: the channel list, data policy, health check and Offset you gave that machine are gone. If you are silencing a noisy machine temporarily, write down the settings on its machine card first. Forget returns the machine to pending; Disable marks it disabled and refuses the machine's requests.

⚠ Licensing: once the quota is full, Enable is refused in the interface with the message "Maximum device limit reached". pending rows consume no slot; as many machines as you like can wait. Enable only the machines where you actually installed the package; Enable consumes a device licence, and a machine with nothing installed sends no data at all.

⚠ A pending row is not proof that the Windows side is ready. Most rows come from the collector's 7-day machine registry, but a machine Logsign already knows by another route (an agent, WMI, syslog) can appear as pending inside the scope before any WEF traffic has arrived; on such a row EPS/Received may be showing that machine's non-WEF traffic. The only reliable test is that the First seen / Last seen columns are populated and refresh within minutes of the install.ps1 run. If the machine you expect is not listed at all, the problem is not in Logsign but on the Windows side (the SubscriptionManager entry, reachability of 5986, WinRM). A pending machine that has not connected for 7 days drops off the list; enabled/disabled rows are always shown. A machine that reached the collector earlier (an earlier installation, or a machine taken out of WEF) is listed as pending even if nothing has been installed today, and it may still carry its old counters.

⚠ Channels are copied at the moment of Enable. The definition's Default channels field is copied to the new client only at that instant. A channel you add to the definition after enabling does not reach existing machines; you add it from the machine card (see Day-to-day operations). This is the cause of the "the channel I added does not arrive, but Application+Security+System flow" symptom.

When does the first event arrive? The machine receives its subscription at its next poll (at most 60 seconds, Refresh=60). After that, delivery works per channel with two triggers: when the envelope reaches 512 KB, or when 60 seconds elapse. A busy machine (a DC) sends within seconds; on a quiet machine the first event takes ~1 minute. To speed it up, generate events on the machine:

1..25 | ForEach-Object { eventcreate /T INFORMATION /ID 999 /L APPLICATION /SO WefTest /D "test" | Out-Null }

You should see: the row turns enabled; the Enabled counter in the definitions list goes up by 1. Within a minute or two the row's Received column (events received in the last 30 minutes) starts climbing and EPS rises above zero. On Windows, one ID=100 per channel appears in the Microsoft-Windows-Forwarding/Operational channel.

Step 5 - Verify

5.1 · Logsign: the definitions list counters

The definitions list on the Windows Event Forwarding page shows Pending, Enabled and Disabled counters for every definition. Once the fleet is complete you should see Pending 0 and Enabled = the number of machines.

The definitions list (sample environment): Name, Scope, Pending, Enabled, Disabled and Actions columns.

After setup (sample environment): three machines enabled, none pending.

5.2 · Logsign: the Clients table columns

The view is cached for 30 seconds; if a counter does not change immediately, wait half a minute and refresh.

Error counters: the Clients table has no error columns, and per-machine error counters (refused / unregistered requests) are not shown in the interface in this version. Whether a machine is being turned away you tell from the Microsoft-Windows-Forwarding/Operational events on the Windows side (5.4) and, if you have console access, from the Dropping request from unregistered source lines in 5.5. The machine's card on Settings → Data Collection is only for editing its settings (card menu ☰ → Edit) and for Source Stats (menu → Stats).

5.3 · Logsign: the search screen

Open the Search screen from the top menu, set the time range to today (or the last hour), type the query and click the Search button (Enter goes to the autocomplete list, it does not run the search):

EventSource.Collector:"wef"                          # all WEF traffic (other definitions included)
EventSource.Description:"<definition-name> <ip>"    # a single machine (the client source's description has this form)
EventSource.Description:"<definition-name>*"           # every machine of this definition only
EventSource.Collector:"wef" AND EventSource.HostName:"<machine-fqdn>"   # by machine name

The EventSource.Collector:"wef" query also returns historical data from definitions that have been deleted; a high result count on its own does not mean "it is working". Do the health check with EventSource.Description:"<definition-name>*".

If you see a time difference: if there is a constant offset of whole hours between an event's Generated and Received times, the machine's time zone differs from Logsign's. It is corrected with the Offset field on the machine card (see Day-to-day operations).

5.4 · Windows: was the subscription created?

On the machine, in an elevated PowerShell:

wevtutil qe Microsoft-Windows-Forwarding/Operational /c:20 /rd:true /f:text

If you are looking from a remote/non-interactive session: Get-WinEvent -LogName Microsoft-Windows-Forwarding/Operational -MaxEvents 20 | Format-List TimeCreated,Id,Message; to count, (Get-WinEvent -LogName Microsoft-Windows-Forwarding/Operational | ? Id -eq 100).Count.

The line you are looking for, one per channel:

Event ID 100: The subscription LogsignWEFCollector-Security is created successfully.
Event ID 100: The subscription LogsignWEFCollector-Application is created successfully.
Event ID 100: The subscription LogsignWEFCollector-System is created successfully.

⚠ ID=104 "connected" does not mean done. The real signature is ID=100, and there must be as many as there are channels. If one channel is missing, check that channel's name and permissions (Troubleshooting → 5004). Not seeing events in Logsign right after ID=100 is not a fault; on a quiet machine the first event takes ~1 minute.

5.5 · Optional - watching from the Logsign console (SSH)

This box is optional; the main flow does not depend on it. If you can log in to the Logsign server over SSH, the collector's own log shows in real time what happens while a machine enrolls:

journalctl -u logsign-wef-collector -f | grep -E 'HANDSHAKE-OK|SUBSCRIPTION-LIVE|Dropping'

[HANDSHAKE-OK]      Subscription policies delivered to <ip>:...
[SUBSCRIPTION-LIVE] First event received from <ip>:... (events are flowing)

• SUBSCRIPTION-LIVE means events are actually flowing; HANDSHAKE-OK only says the policy was delivered.
• TLS handshake error … EOF lines are normal: Windows opens a throwaway probe connection before every real one. They matter only alongside another symptom.
• Dropping request from unregistered source <ip> → the machine is pending or disabled, or inside no definition's scope. Do not read "unregistered" literally; read "not approved". These lines are throttled to one per IP per minute; the suppressed count is reported at the end of the line as skipped_since_last=N; few lines does not mean few attempts.

You should see: Pending 0 in the definitions list; Received climbing for every machine in the Clients table; no new error event in Microsoft-Windows-Forwarding/Operational on Windows; on Search, EventSource.Collector:"wef" returning events from today; on Windows, as many ID=100 as there are channels. The setup is complete.

Day-to-day operations

Adding a machine

1. Does the machine's IP fall inside the definition's Scope? If not, widen the scope (widening is always allowed) or create a new definition.
2. Set up the Windows side: download that machine's package and run install.ps1 (Step 3).
3. When the machine shows up as pending, Enable.

Removing a machine

• Temporary silencing: Clients → Disable. The machine is refused, the slot is freed, the settings are deleted (write them down first). Enable to bring it back.
• Permanent removal: Disable, then clean the Windows side (see Removal). If you want to narrow the scope, move the machine to pending with Forget first; a scope change that leaves an enabled/disabled machine outside is refused with "Scope <scope> leaves N client(s) outside the definition: <ip…>. Disable and delete them first.". Despite the wording, the action that clears it is Forget, not Disable; a disabled machine also counts as out of scope.

Changing channels, data policy and health check

Every enabled machine appears with its own card on the Settings → Data Collection page; the card is named <definition-name> <ip>. The channel list, data policy and health check are edited from this card, per machine: open the card menu (☰) → Edit. The card is for two things only: that Edit, and Source Stats (menu → Stats); the card has no error counter or machine table. The card's host and type fields and its link to the definition are protected; they cannot be changed.

Data Collection (sample environment): typing the definition name in the search box lists only that definition's machine cards; every enabled machine is one card.

• Rolling a new channel out to the fleet: add it to the definition's Default channels (for future machines) and to the card of every existing machine. Changing the definition does not reach existing machines.
• Channel name: verify it exactly on the machine with wevtutil el | Select-String <fragment>. A wrong name drops that channel's subscription (ID=107); because the other channels keep flowing, the error goes unnoticed.
• Removing a channel: remove it from that machine's card only. The machine picks up the new list at its next poll (≤60 s).

Offset (time difference)

If a machine's events arrive with a constant offset (e.g. always 3 hours behind), enter the difference in the Offset field on the machine card. It is per machine; the definition has no such field.

Certificate lifecycle

If you are doing a planned renewal (Regenerate): pick a maintenance window; pass the warning and the super admin password; Save; then download the new package and run install.ps1 again on every machine.

If the collector address changes

The server certificate is bound to the address. When the address changes you must update the Collector address and do Regenerate + Save; that is a new CA, and the planned-renewal procedure above applies. The SubscriptionManager line on the Windows side is updated to the new address together with the new package. This is why choosing the address correctly in Step 1 matters; in a cluster always use the shared address.

Definition deletion rules

• Deletion is refused while enabled clients exist: "This definition still has N enabled client(s)… Disable them first" (In some versions the banner text is not visible in the dark theme; an empty red banner means exactly this.).
• Deleting a definition clears its disabled marks without warning.
• Even after the definition is deleted, 5986 stays open; every request is refused. Closing the port (removing the PKI) cannot be done from the interface → Logsign support.

Troubleshooting

Almost every WEF failure is visible on the Windows side. Logsign only tells you "nothing arrived"; Windows tells you why.

Symptom → cause → fix

Windows Event ID reference (Microsoft-Windows-Forwarding/Operational)

Error code reference

The text of the ID=105 event itself carries the explanation; read the event before looking up the code. Also: winrm helpmsg 0x<code>.

⚠ Two codes, the same sentence. 0x80338082 and 0x80090016 produce the same message ("cannot find the certificate that was requested"). Whoever reads only the message concludes "no certificate" and pokes at the wrong place: the code is what separates them; …0016 (a permission problem) is by far the more common one. certutil -error 5004 returns an unrelated explanation; 5004 is WEF-specific.

Granting the private-key permission by hand (normally install.ps1 grants it; for emergencies): certlm.msc → Personal → Certificates → right-click the certificate → All Tasks → Manage Private Keys → Add → NETWORK SERVICE → Read. Then Restart-Service WinRM -Force.

Manage Private Keys (sample environment).

Read permission for NETWORK SERVICE (sample environment).

The two causes of 5004

wevtutil gl "Microsoft-Windows-Sysmon/Operational"

⚠ This failure is silent. Even when Security drops, Application and System keep flowing; the machine looks "connected", Received climbs, but the most valuable channel has been cut. Count the ID=100 lines per channel.

Timing traps - the "installed but not working" illusion

⚠ 1. The first event from a quiet machine can take up to a minute. Delivery is a separate subscription per channel and has two triggers: when the envelope reaches 512 KB, or when 60 seconds elapse. The heartbeat is 900 seconds and is not a delivery trigger. There is no count-based trigger; a machine cannot flush early on "I have collected 20 events". Keep your verification window at 2-3 minutes at least, and generate events if needed (the command in Step 4).

⚠ 2. On Server 2016, Restart-Service WinRM may not be enough. If the Event Log Readers membership was added during that same boot, the new group does not enter the existing WinRM token and Security fails with ID=102/5004. On Server 2019 and later a service restart is sufficient. On Server 2016 stop WinRM, wait 10 seconds and start it again: Stop-Service WinRM -Force; Start-Sleep 10; Start-Service WinRM. If it is still 5004, add (A;;0x1;;;NS) to the channel's SDDL (wevtutil sl <channel> /ca:…); this requires no restart. The lasting fix is to use the channel SDDL instead of group membership: adding (A;;0x1;;;NS) needs no restart and removes this ordering problem altogether.

Removal

Order matters: stop the Logsign side first, then clean each machine. This guide does not use Group Policy; the subscription setting lives in each machine's own local registry, so cleaning the machine is permanent.

1 · Logsign side

1. Settings → Integrations → Windows Event Forwarding → click the definition → Disable every machine in the Clients table.
2. Return to the definitions list → Delete in the row's Actions column. If enabled clients remain it is refused; Disable all of them and try again. Delete opens a confirmation dialog (Enable/Disable/Forget do not); once you confirm, the definition and its settings are gone for good.

This much stops collection. No machine can obtain a subscription; every incoming request is refused. Port 5986 stays open; the listener depends on the collector's server certificate, not on the definitions. That is expected, and nothing is collected. Closing the port as well (removing the PKI) cannot be done from the interface; do it together with Logsign support.

2 · Windows

On every machine, run all four steps of the block below, in order. The filter in step 2 selects only the certificate issued by Logsign WEF CA; if the Logsign Agent is on the same machine, its O=Logsign certificate is left untouched.

Full cleanup on the Windows side (block)

# 1. SubscriptionManager - do NOT delete the whole key; there may be several numbered entries (a second collector)
$SM = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\EventLog\EventForwarding\SubscriptionManager'
reg export "HKLM\SOFTWARE\Policies\Microsoft\Windows\EventLog\EventForwarding" C:\wef-backup.reg /y
Get-ItemProperty $SM -EA SilentlyContinue | Format-List        # READ THIS FIRST
(Get-ItemProperty $SM -EA SilentlyContinue).PSObject.Properties |
  Where-Object { $_.Name -match '^\d+$' -and $_.Value -like "*<collector-address>*" } |
  ForEach-Object { Remove-ItemProperty -Path $SM -Name $_.Name -EA SilentlyContinue }

# 2. Logsign PKI certificates - filtered by ISSUER: leaves the Logsign Agent's O=Logsign certificate alone
Get-ChildItem Cert:\LocalMachine\My   | Where-Object { $_.Issuer -like '*Logsign WEF CA*' } | ForEach-Object { Remove-Item ("Cert:\LocalMachine\My\"+$_.Thumbprint) -DeleteKey }
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Subject -like '*Logsign WEF CA*' } | ForEach-Object { Remove-Item ("Cert:\LocalMachine\Root\"+$_.Thumbprint) }   # The Logsign WEF CA in Trusted Root

# 3. Script leftovers, Security channel permission and group membership (S-1-5-20 only)
Remove-Item C:\ProgramData\LogsignWEF -Recurse -Force -EA SilentlyContinue   # removes the script's traces if any; otherwise nothing happens
#    remove the (A;;0x1;;;NS) part that install.ps1 or you added by hand from the Security channel SDDL; if it is not there nothing changes
$ca = (wevtutil gl Security | Select-String '^channelAccess:').Line -replace '^channelAccess:\s*',''
if ($ca) { $ca = $ca -replace '\(A;;0x1;;;NS\)',''; wevtutil sl Security /ca:$ca }
# Run ONLY if YOU added this membership for a non-default channel; install.ps1 does not add it
Remove-LocalGroupMember -SID 'S-1-5-32-573' -Member 'S-1-5-20' -EA SilentlyContinue   # on a DC: Remove-ADGroupMember -Identity 'S-1-5-32-573' -Members 'S-1-5-20'
Restart-Service WinRM -Force
#    On a Windows 10/11 client put WinRM back to its old state (on a server it was Automatic already; leave it): Set-Service WinRM -StartupType Manual

# 4. The package folder - the PFX and its clear-text password in README.txt
Remove-Item C:\wef-setup -Recurse -Force -EA SilentlyContinue