Windows Event Forwarding (WEF) Subscription Issue in Workgroup Environment

_Raj — Mon, 27 Jul 2026 11:56:01 GMT

Hi Everyone,

I'm building a lab to centralize Windows Event Logs before sending them to Splunk. The objective is to collect Windows event logs from multiple Windows servers at a single Windows Event Collector (WEC), then forward the centralized logs to Splunk using a Universal Forwarder.

Lab Architecture

AWS VPC

WINSRC01 (Windows Server 2022)
Event Source
│
│
WINSRC02 (Windows Server 2022)
Event Source
│
│
Windows Event Forwarding (WEF)
│
▼
WEC01 (Windows Server 2022)
Windows Event Collector (WEC)
+ Splunk Universal Forwarder
│
│
▼
Splunk Heavy Forwarder (RedHat)
Splunk Enterprise 9.4.1

Objective

WINSRC01 and WINSRC02 should forward their Windows Event Logs (Application, Security, and System) to WEC01 using Windows Event Forwarding (WEF).
WEC01 should collect all forwarded events in the Forwarded Events log.
A Splunk Universal Forwarder installed on WEC01 should monitor the Forwarded Events log and forward the data to a Splunk Heavy Forwarder running on Redhat.
This design reduces the number of Splunk forwarders and provides a centralized Windows event collection point.

Configuration Performed
- Deployed three Windows Server 2022 EC2 instances in the same AWS VPC.
- Configured one server as the Windows Event Collector (WEC01).
- Configured the other two servers as event source computers.
- Enabled WinRM and PowerShell remoting on all servers.
- Successfully initialized the Windows Event Collector using:
  Powershell
  wecutil qc
  
  Verified WinRM connectivity between the collector and both source servers using Test-WSMan.
  Confirmed TCP port 5985 is reachable.
  Configured Windows Firewall appropriately.
  Problem Faced
  Since the servers are standalone workgroup machines (not joined to Active Directory), we encountered multiple issues while configuring Windows Event Forwarding.
  1. Collector-Initiated Subscription
  When creating a Collector-Initiated subscription, clicking Select Computers failed because the dialog searches Active Directory for computer objects. Since our servers are not domain joined, Windows could not locate WINSRC01 or WINSRC02.
  2. Source-Initiated Subscription
  We then switched to a Source-Initiated subscription.
  The Event Viewer GUI would not allow us to save the subscription correctly, so we created it using:
  wecutil cs WindowsServerLogs.xml
  The subscription was created successfully, but it never became active.
  Running:
  cmd
  wecutil gr WindowsServerLogs
  returned:
  RunTimeStatus : Inactive
  LastError : 1337
  ErrorMessage : The security ID structure is invalid.
  The subscription creation command also reported:
  The subscription is saved successfully,
  but it can't be activated at this time.
  Error = 0x3ae8
  The subscription fails to activate.
  Additional Observation
  Running:
  cmd
  wecutil gs WindowsServerLogs
  shows:
  AllowedSourceDomainComputers:
  O:NSG:NSD:(A;;GA;;;DC)(A;;GA;;;NS)
  which appears to be a security descriptor intended for domain computers, even though our environment consists entirely of workgroup servers.
  Question
  Has anyone successfully implemented Windows Event Forwarding in a standalone workgroup environment using the architecture shown above?
  Specifically:
  Is Source-Initiated WEF over HTTP supported without Active Directory?
  Does the LastError: 1337 (The security ID structure is invalid) indicate that the collector is expecting domain-based security identifiers?
  Is HTTPS with certificates required for workgroup-based Source-Initiated subscriptions?
  Would it be better to deploy Active Directory and use Kerberos authentication for this architecture?
  Any guidance or working examples would be greatly appreciated.
  Thank you!

Re: Windows Event Forwarding (WEF) Subscription Issue in Workgroup Environment

PickleRick — Mon, 27 Jul 2026 12:20:32 GMT

I haven't worked with it for quite a while (I had a non-AD WEF setup some 5+ years ago) but I seem to recall that without AD WEF worked only in one mode (apparently it is pull only).

And it required an insane amount of work to establish the trust relation between the source and the collector (AFAIR it was all based on cert-based authentication and there was no way around it).

So you'd be much better of with just installing the UF on the source machines if you have that possibility.

BTW, if you do have AD environment WEF is a very easy thing to set up.

topic Windows Event Forwarding (WEF) Subscription Issue in Workgroup Environment in Deployment Architecture

Windows Event Forwarding (WEF) Subscription Issue in Workgroup Environment

Lab Architecture

Objective

Configuration Performed

Problem Faced

Re: Windows Event Forwarding (WEF) Subscription Issue in Workgroup Environment