Code 500 WinRM ping failed

I have been looking into this for a dew days now and have not found a solution to the issue I am running into.

This is just a test setup so I can learn to use Ansible before moving onto a larger deployment. It is between two custom computers over a Netgear AC1750 router which has caused me some issues with communication like this using fog and PXE. Treat this like I have no idea what I am doing because I probably don’t.

Command:
ansible win -m win_ping

Error:

[WARNING]: ERROR DURING WINRM SEND INPUT - attempting to recover: WinRMError
The pipe has been ended.  (extended fault data: {'transport_message': 'Bad HTTP
response returned from server. Code 500', 'http_status_code': 500,
'wsmanfault_code': '109', 'fault_code': 's:Receiver', 'fault_subcode':
'w:InternalError'})
192.168.1.13 | FAILED! => {
    "msg": "winrm send_input failed; \nstdout: \nstderr "

}

Host File:

[win]
192.168.1.13

[win:vars]
ansible_user=user
ansible_password=Password
ansible_port=5985
ansible_connection=winrm
ansible_winrm_transport=basic
ansible_winrm_message_encryption=never
ansible_winrm_server_cert_validation=ignore

Host WinRM configuration:

Service
    RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
    MaxConcurrentOperations = 4294967295
    MaxConcurrentOperationsPerUser = 1500
    EnumerationTimeoutms = 240000
    MaxConnections = 300
    MaxPacketRetrievalTimeSeconds = 120
    AllowUnencrypted = true
    Auth
        Basic = true
        Kerberos = true
        Negotiate = true
        Certificate = false
        CredSSP = false
        CbtHardeningLevel = Relaxed
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    IPv4Filter = *
    IPv6Filter = *
    EnableCompatibilityHttpListener = true
    EnableCompatibilityHttpsListener = true
    CertificateThumbprint
    AllowRemoteAccess = true

Winrs
    AllowRemoteShellAccess = true
    IdleTimeout = 7200000
    MaxConcurrentUsers = 2147483647
    MaxShellRunTime = 2147483647
    MaxProcessesPerShell = 2147483647
    MaxMemoryPerShellMB = 2147483647
    MaxShellsPerUser = 2147483647

try running this command on your windows box

winrm enumerate winrm/config/Listener

this should output is listerners are active and if the ssl is active, also make sure the firewall is not interfering with the communications you can test this from a linux box try connecting to one of those ports

nc -zv 192.168.*.* 5985
nc -zv 192.168.*.* 5986

This is the results of the first command:

Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 169.254.93.237, 169.254.100.170, 169.254.138.38, 169.254.170.28, 169.254.182.145, 169.254.246.123, 192.168.1.13, ::1, fe80::c0d:7aa8:c083:8a26%14, fe80::251f:e0dd:2dfb:64aa%19, fe80::58c5:44:fd21:f67b%5, fe80::88f4:1ea3:e209:5ded%20, fe80::b90e:5b91:1381:aa1c%9, fe80::d07d:917e:ddf9:b691%3, fe80::e087:27ff:60f7:aed2%4

Listener
    Address = *
    Transport = HTTPS
    Port = 5986
    Hostname = DESKTOP-940MHK9
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint = 6038452067F88B131CC682A14952F73E85A1D270
    ListeningOn = 127.0.0.1, 169.254.93.237, 169.254.100.170, 169.254.138.38, 169.254.170.28, 169.254.182.145, 169.254.246.123, 192.168.1.13, ::1, fe80::c0d:7aa8:c083:8a26%14, fe80::251f:e0dd:2dfb:64aa%19, fe80::58c5:44:fd21:f67b%5, fe80::88f4:1ea3:e209:5ded%20, fe80::b90e:5b91:1381:aa1c%9, fe80::d07d:917e:ddf9:b691%3, fe80::e087:27ff:60f7:aed2%4

Listener [Source="Compatibility"]
    Address = *
    Transport = HTTP
    Port = 80
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 169.254.93.237, 169.254.100.170, 169.254.138.38, 169.254.170.28, 169.254.182.145, 169.254.246.123, 192.168.1.13, ::1, fe80::c0d:7aa8:c083:8a26%14, fe80::251f:e0dd:2dfb:64aa%19, fe80::58c5:44:fd21:f67b%5, fe80::88f4:1ea3:e209:5ded%20, fe80::b90e:5b91:1381:aa1c%9, fe80::d07d:917e:ddf9:b691%3, fe80::e087:27ff:60f7:aed2%4

Listener [Source="Compatibility"]
    Address = *
    Transport = HTTPS
    Port = 443
    Hostname = DESKTOP-940MHK9
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 169.254.93.237, 169.254.100.170, 169.254.138.38, 169.254.170.28, 169.254.182.145, 169.254.246.123, 192.168.1.13, ::1, fe80::c0d:7aa8:c083:8a26%14, fe80::251f:e0dd:2dfb:64aa%19, fe80::58c5:44:fd21:f67b%5, fe80::88f4:1ea3:e209:5ded%20, fe80::b90e:5b91:1381:aa1c%9, fe80::d07d:917e:ddf9:b691%3, fe80::e087:27ff:60f7:aed2%4

The results of those pings where a success. There has been no change for pinging it with ansible.

Ok the listener is configured correctly , have you tried running it with the firewall off ?
If not i should try this the ports 5986,5985 should be open to you ansible / awx host.

What is have done is bootstraped my windows template with packer with the correct configruation i have a set of powerhsell scripts that i execute to perform the provisioning. So i am sure the installation is always correct and working.

when you figured your issue out i recomend you also template your system.
So it is always repeatable and with packer you have infrastructure as code.

Turning off the firewall was one of the first things I did to try to fix it so no change.

Getting a WinRM http 500 error means that the service is running and listening, but something is bad about your request. There’s a reasonably good chance that there’s nothing wrong with your ansible win -m win_ping command itself though.

What’s most likely happening is that Windows doesn’t trust the incoming connection. You’ve enabled the listeners, disabled the firewall, allowed basic auth and unencrypted connections (yikes!), but there’s still something Windows just isn’t happy about. A couple of other places to look might be Group Policy and Security Policy settings, but I think the more likely problem is that your Windows host is on a “public” network. Windows will refuse any remote management attempts on a public network by default, so even if your ansible host is on the same subnet, if Windows considers it to be on a “public” instead of “private” or “domain” network, then it will refuse the connection.

To check and remedy this if this is the case, login to the windows box as an administrator and open powershell (as admin):

Manual step-by-step:

Get-NetConnectionProfile
# look for network name of public profiles
Set-NetConnectionProfile -Name "network name" -NetworkCategory private
# verify change
Get-NetConnectionProfile -Name "network name"

Automatic steps:

$con_profiles = Get-NetConnectionProfile
$con_profiles # show before
$con_profiles | Where-Object NetworkCategory -like "public"
 | Set-NetConnectionProfile -NetworkCategory private
Get-NetConnectionProfile

I have already made it a private network.

Name             : Network 3
InterfaceAlias   : Ethernet 2
InterfaceIndex   : 4
NetworkCategory  : Private
IPv4Connectivity : LocalNetwork
IPv6Connectivity : NoTraffic

Yea I get the security risks with how its setup but I do have a few things in my favor here.

  1. If they get in through winRM maybe they fixed the issue for me hopefully they left notes.
  2. This computer is wiped anyway with nothing on it its next destination is the shredder once this afterlife is over for it.
  3. This is an air gaped network its on anyway.

I was just trying to eliminate possibilities this way and if I got it working re enable them one by one.

Not seeing anything under the policy settings that would affect it though I am not entirely sure what I am looking for.

Have you run Enable-PSRemoting -Force -SkipNetworkProfileCheck on the windows host?

Have you tried connecting powershell remotely from another windows host using Enter-PSSession?

I did try the first thing with no change in results. I am going to try the second but the only windows machine I have at the moment outside of the problem child is locked down by IT so it probably will not work for this. I’ll see about figuring something out but assume its a non starter for now.

If you can log into it and have network connectivity to the problem child, then you should be able to test powershell remoting just fine (unless IT has blocked powershell itself). There’s not a lot of ways to actually block outbound powershell remoting connections, though there are plenty of settings for hardening/securing those connections.

You don’t need to be an admin, just open up powershell and try creating a PSSession with the problem child.

The problem is the network settings are locked and the ports are currently disabled. I can get access to them but it might take a couple days for IT to respond to my request. I get security is important but there are times its just getting in the way a bit too much.

The ports are disabled? On the other host? That’s okay, you don’t need to configure WinRM on both hosts to connect to the problem child. Or do you mean they have a network firewall blocking traffic between the windows hosts?

I mean the physical ethernet ports. Not the SSH or WinRM ports though those are probably disabled too or restricted to the program IT uses. The only network options with it are wifi and virtual ethernet over thunderbolt neither of which I can mess with at the moment.

I may have an idea though. I think I have a windows copy on a spare ssd somewhere around here I’ll see if I can’t just pop it into the machine with Ansible on it for a moment.