Alright so I've been trying to set up Windows Event Forwarding via HTTPS for a while now and in the process, I've hit my share of errors that I managed to address one by one, but now I've been stuck on one that I can't seem to fix.

Also, I want to say that via HTTP, everything works fine. But if I try to use HTTPS instead of HTTP, the source computer cannot connect to the collector.

Guide I've been following (in addition to following instructions from other sources):


Seems like I'm having the same kind of issues as this user:



  • Windows Server 2016 acting as a Windows Event Collector, via Source Initiated subscription
  • Windows 10 Enterprise, using a Windows Event Forwarding subscription that uses HTTPS
  • Both are on the same domain, let's say domain.example.com

For the sake of simplicity, let's call them WS2016 and WIN10. No objections? Good.

So on WIN10, the following GPO is set:

Computer Configuration\Administrative Templates\Windows Components\Event Forwarding\Configure target Subscription Manager

And this is the value I'm using:


Technically, I don't even need to add the IssuerCA part, since both systems are on the same domain, but even without, I get the error.

Now, once the subscription is configured on the source computer (WIN10), it tries to connect to the WEC (WS2016), but fails and this error is logged in the Event Viewer, under the Eventlog-ForwardingPlugin\Operational log.

The forwarder is having a problem communicating with subscription manager at address https://WS2016.example.domain.com:5986/wsman/SubscriptionManager/WEC. Error code is 5 and Error Message is 
<f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="5" Machine="WIN10.example.domain.com"><f:Message>WinRM client cannot process the request. The destination computer (WS2016.example.domain.com:5986) returned an 'access denied'
error. Specify one of the authentication mechanisms supported by the server. If Kerberos mechanism is used, verify
that the client computer and the destination computer are joined to a domain. Possible authentication mechanisms
reported by server: Negotiate Kerberos </f:Message></f:WSManFault>.

And if I check in the Windows Remote Management\Operational logs, I can see these errors:

EventID 164: The destination computer (WS2016.example.domain.com) returned an 'access denied' error. Verify your credentials are correct.

EventID 142: WSMan operation Enumeration failed, error code 5

I'm basically at the end of my rope here. I tried a lot of stuff and nothing works.


Some of the stuff I tried:

  • Using Test-WSMan via PowerShell to connect to WS2016 using the -UseSSL and -Authentication Default parameters, it works.
  • Adding the current user (one with the session opened) on WIN10 in WS2016 Administrators' group

As for the "checks", way too many to remember and list them all...

  • If you can use Kerberos authentication, you don't need HTTPS. Are you sure that you really want to use HTTPS instead of Kerberos ? The events are encrypted even if you use HTTP
    – Swisstone
    May 3 '19 at 18:52
  • I just read the paragraph that you linked, and from my understanding, it means that HTTPS should only be used when Kerberos authentication isn't an option (ie: a non-domain computer is trying to send Windows Event logs to a domain-joined server) and therefore, you would need to configure certificate-based authentication. Is that right?
    – Aura
    May 3 '19 at 19:01
  • The opposite can occur: domain computers forwarding events to non-domain joined collector. But you get the idea. And it takes more steps to setup because you have to install a PKI, create a certificate template etc... I will post an answer for your question with a link to a step by step tutorial.
    – Swisstone
    May 3 '19 at 20:14

In a typical domain environment, you probably don't need to setup HTTPS to transmit the events because they are encrypted by Kerberos.

However, if the server or the clients are not domain joined, you can replace Kerberos by HTTPS to transmit the events. You'll have to take care of the certificate distribution, renewal, etc...

For example, it's possible to setup your event collector as a non-domain server for security purposes (the server is in a workgroup so even domain admins can't connect and delete logs.)

Microsoft published a step-by-step tutorial on technet to achieve this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.