Windows Logs Forwarding - Error code is 2150859027 -HTTP server that does not support the WS-Management protocol

Question

Windows Logs Forwarding - Error code is 2150859027 -HTTP server that does not support the WS-Management protocol

Mountain Pond 1,716

Hello.

I'm setting up Event Log Forwarding on Windows 11. This is a new server designed for log collection.

The "Sourcew computer initialized" model is selected. I've configured log forwarding before and haven't encountered this issue.

The client can connect via WinRM without any problems, and traffic is not blocked.

Test-WSMan shows success Test-WSMan elastic_server.contoso.local wsmid : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd ProtocolVersion: http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd Product Vendor: Microsoft Corporation ProductVersion: OS: 0.0.0 SP: 0.0 Stack: 3.0

Test-NetConnection port 5985 shows success

ComputerName: elastic_server.cintoso.local RemoteAddress: 192.168.10.101 RemotePort: 5985 InterfaceAlias: Ethernet SourceAddress: 192.168.10.60 TcpTestSucceeded: True

IPv6 is disabled

The browser http://elastic_server.contoso.local:5985/wsman is unavailable, error 405.

The page http://elastic_server.contoso.local:5985/wsman/SubscriptionManager/WEC is completely unavailable.

Group Policy:

Windows Components/Event Log Services/Security Configure log access is Enabled Log Access: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;NS)

Windows Components/Event Forwarding Configure target Subscription Manager: Enabled SubscriptionManagers: Server=http://elastic_server.contoso.local:5985/wsman/SubscriptionManager/WEC,Refresh=60

Also:

Added "NT AUTHORITY\NETWORK SERVICE" to the "Event Log Readers" group.

Tried:

https://learn.microsoft.com/en-us/troubleshoot/windows-server/admin-development/events-not-forwarded-by-windows-server-collector netsh http delete urlacl url=http://+:5985/wsman/ netsh http add urlacl url=http://+:5985/wsman/ sddl=D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116 970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517) netsh http delete urlacl url=https://+:5986/wsman/ netsh http add urlacl url=https://+:5986/wsman/ sddl=D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)

Unfortunately, no results.

Client error:

The forwarder is having a problem communicating with the subscription manager at http://elastic_server.contoso.local:5985/wsman/SubscriptionManager/WEC. Error code is 2150859027 and Error Message is <f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2150859027" Machine="FS.contoso.local"><f:Message>The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol. </f:Message></f:WSManFault>.

Warning on the server:

The Subscription All Windows Events could not be activated on machine due to an error. Error Code is 2150858895. Subscription will remain inactive on this target until subscription is resubmitted / reset.

If this is not a network problem or a problem with privileges, then I don’t know what the problem is.

I don't know the infrastructure, so it's possible there's something blocking it at the network level, but the tests seem to show no issues.

Thanks in advance.

0 comments

3 answers

Your answer

Answer 1

VPHAN 38,360 Independent Advisor

Hi Mountain Pond,

Has your issue been resolved yet? If it has, please consider accepting the answer as it helps others sharing the same problem benefit too. Thank you :)

VPHAN

0 comments

Answer 2

Mountain Pond

Modern Windows versions, including Windows 11, automatically isolate background services into their own individual processes to improve system stability. This architecture accidentally breaks Event Log Forwarding because the Windows Event Collector and Windows Remote Management services end up conflicting over the exact same HTTP endpoint on port 5985 and triggers the error 2150859027. You can try modifying the registry to explicitly prevent Windows from splitting these two specific services apart. By forcing them to share a process host, they can seamlessly share the WS-Management port without locking each other out.

To implement this fix, open an elevated Command Prompt to add a specific override key to the registry for both services. You will execute REG ADD HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Wecsvc /v SvcHostSplitDisable /t REG_DWORD /d 1 /f to apply the fix to the Windows Event Collector service. Immediately following that, execute REG ADD HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinRM /v SvcHostSplitDisable /t REG_DWORD /d 1 /f to apply the exact same fix to the Windows Remote Management service. Adding the SvcHostSplitDisable key with a value of 1 instructs the operating system to bypass its default isolation behavior and bundle these services together. And remember to reboot the server to force the architecture change to take effect and activate your subscriptions.

VPHAN

Mountain Pond 1,716 Reputation points

2026-06-01T18:14:41.4433333+00:00

Thanks for the reply.

But that didn't work either.

I'll ask them to prepare the 2022 server.

Answer 3

The error and tests indicate that WinRM is listening and reachable, but the URL ACLs for the WSMan listener on the collector are not correctly granting access to both WinRM and the Windows Event Collector (WecSvc) services.

On current Windows Server/Windows 10+ builds, WinRM and WecSvc may run in separate svchost processes. If the URL reservations for http://+:5985/wsman/ and https://+:5986/wsman/ only grant access to the WinRM service SID, WecSvc cannot use those URLs and source-initiated subscriptions fail with the WS-Management URL-not-available error (2150859027) even though Test-WSMan succeeds.

To fix this, ensure the URL ACLs match the documented defaults that include both service SIDs (WinRM and WecSvc):

Open an elevated Command Prompt on the collector.
Inspect current URL ACLs:
```
   netsh http show urlacl
```

Remove any existing reservations for the WSMan URLs:

   netsh http delete urlacl url=http://+:5985/wsman/
   netsh http delete urlacl url=https://+:5986/wsman/

Recreate the URL ACLs with the correct SDDL that grants access to both services:

   netsh http add urlacl url=http://+:5985/wsman/ sddl=D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)
   netsh http add urlacl url=https://+:5986/wsman/ sddl=D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)

These SDDL entries correspond to the service SIDs for WinRM and WecSvc and are the documented defaults when both services must share the WSMan URLs.

Restart the WinRM and Windows Event Collector services, then re-test event forwarding.

If the collector is running a newer Windows Server/Windows 10+ build where services are split into separate svchost processes by default, this URL ACL configuration is required for source-initiated subscriptions to function.

References: