WinRM Listener not bound to IPv4

Question

Hi all

On one of our Servers, I face the problem to not being able to query WinRM from a remote Computer.
After investigating different things, I found, that the WinRM listener is not bound to the IPv4 address of the Server.
Unfortunately, I was not able to find out, why the listener not binds to that address.

I setup WinRM with the following command:

winrm create winrm/config/Listener?Address=*+Transport=HTTP

If I run the the command to get the running configuration I get:

PS C:\WINDOWS\system32> winrm enumerate winrm/config/Listener
Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 192.168.0.130, ::1, fe80::91f5:13f7:9b77:88cd%4

Test with wsman locally :

PS C:\WINDOWS\system32> test-wsman


wsmid           : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor   : Microsoft Corporation
ProductVersion  : OS: 0.0.0 SP: 0.0 Stack: 3.0

But if I take a look with netstat, only the IPv6 address has a listener bound to it:

PS C:\WINDOWS\system32> netstat -ano | findstr 5985
  TCP    [::]:5985              [::]:0                 LISTENING       4

On other Servers I can also see a listener bound do IPv4 with 0.0.0.0
In that case, for example, netstat shows the following:

PS C:\Windows\system32> netstat -ano | findstr 5985
  TCP    0.0.0.0:5985           0.0.0.0:0              LISTENING       4
  TCP    [::]:5985              [::]:0                 LISTENING       4

Any Idea, where to look at next?

Answer 1

the command netsh http show iplisten gives back:

IP addresses present in the IP listen list:
-------------------------------------------

    ::

Answer 2

Hello @MaHuBe ,

You could try the following:

• Start a ETW trace on the system where the WinRM listener is running with the command netsh trace start provider=Microsoft-Windows-WinRM provider=Microsoft-Windows-TCPIP keywords=ut:Global,ut:Endpoint,ut:TcpipEndpoint,ut:TcpipListener,ut:TcpipBind,ut:ConnectPath level=4 provider=Microsoft-Windows-HttpService provider=Microsoft-Windows-HttpEvent provider={20f61733-57f1-4127-9f48-4ab7a9308ae2} keywords=0xFFFFFFFF level=5 report=disabled tracefile=why.etl
• Restart the WinRM service.
• Stop the ETW trace with the command netsh trace stop
• Either analyse the why.etl file yourself or make it available here.

Gary

Answer 3

Hello Martin,

This is the key sequence of the trace and everything seems to proceed as expected:

One would not expect to see explicit mention of an IPv4 address in that trace; the addresses that are shown are all zeroes addresses and just displayed in IPv6 format as a limitation of the trace format.

I can't see the cause of the problem in the trace either, but that prompted me to think about what could be causing the issue and the HTTP "IP listen list" emerged as the most likely explanation. What does the output of netsh http show iplisten look like?

Gary