I currently have four Windows Server 2012 servers I want to manage via Ansible.
On the first one, I turned off the Windows Firewall, added Ansible user as local admin, and ran the Powershell script.
I can win_ping to that one successfully and it all works fine.
For the other three, I went through the exact same steps, the script completed successfully, and yet when I try to win_ping I get: ntlm: (u’http’, u’Bad HTTP response returned from server. Code 500’)
I should mention I can telnet successfully to those servers via port 5985.
As you can see I am only using ntlm and port 5985.
I’ve kinda hit a dead end here - I also see no issues on the Windows Event log.
I should mention these are Amazon EC2 instances, I made sure to enable port 5985 for the security group etc.
Looks like you are trying to connect over port 5985 which is defaulting to http://hostname:5985/wsman instead of https://hostname:5986/wsman and Ansible by default doesn’t allow you to talk through HTTP unless you have disabled some security restrictions on the Windows host itself.
For a bit of background the default port for the HTTP listener is 5985 while HTTPS is 5986. You can see what your host is configured with by running the following in powershell on your Windows box.
winrm enumerate winrm/config/Listener
This is the type of output you would expect from this command (note the IP/Hostname/Certificate thumbprint would be different)
The above tells me I have a HTTP listener running and is over port 5985 while I also have a HTTPS listener running and is over port 5986. As I was saying at the start you can get Ansible to talk over HTTP but you will have to allow unencrypted messages to be received on the host. If you use HTTPS you don’t have to worry about encrypting the messages as it is done over TLS and so Ansible should work with that.
Once you have verified the above and ensured you have a HTTPS listener active you will also want to modify you configuration to be something like
There were a few entries in there that are not needed for NTLM which I’ve removed. You should be able to specify the user using the UPN format (username@REALM.COM) or Down Level login format (REALM\username), I usually use the down level for NTLM and UPN for Kerberos but they should be interchangable.
Hopefully this helps you to get it working and understand a bit more on the transport side.
Using module file /usr/local/lib/python2.7/dist-packages/ansible-2.4.1.0-py2.7.egg/ansible/modules/windows/win_ping.ps1
<KOR1074638.kor.apac.bosch.com> ESTABLISH WINRM CONNECTION FOR USER: lsl@APAC.COM on PORT 5986 TO
<KOR1074638.kor.apac.bosch.com> WINRM CONNECT: transport=ntlm endpoint=https://:5986/wsman
Using module file /usr/local/lib/python2.7/dist-packages/ansible-2.4.1.0-py2.7.egg/ansible/modules/windows/win_ping.ps1
<10.47.115.103> ESTABLISH WINRM CONNECTION FOR USER: lsl@APAC…COM on PORT 5986 TO 10.47.115.103
<10.47.115.103> WINRM CONNECT: transport=ntlm endpoint=https://:5986/wsman
<KOR1074638.kor.apac.bosch.com> WINRM CONNECTION ERROR: (u’http’, u’Bad HTTP response returned from server. Code 500’)
Traceback (most recent call last):
File “/usr/local/lib/python2.7/dist-packages/ansible-2.4.1.0-py2.7.egg/ansible/plugins/connection/winrm.py”, line 222, in _winrm_connect
self.shell_id = protocol.open_shell(codepage=65001) # UTF-8
File “/usr/local/lib/python2.7/dist-packages/winrm/protocol.py”, line 132, in open_shell
res = self.send_message(xmltodict.unparse(req))
File “/usr/local/lib/python2.7/dist-packages/winrm/protocol.py”, line 207, in send_message
return self.transport.send_message(message)
File “/usr/local/lib/python2.7/dist-packages/winrm/transport.py”, line 202, in send_message
raise WinRMTransportError(‘http’, error_message)
WinRMTransportError: (u’http’, u’Bad HTTP response returned from server. Code 500’)
What version of pywinrm are you using? 0.3.0 is released now and among other changes this version has better error reporting. Worth upgrading to 0.3.0 if you can.
I have occasionally encountered this ‘Bad HTTP response returned from server: Code 500’ and in all the cases I have encountered so far either something interrupted the networking on the windows box (usually a reboot) or the machine was busy 100 % cpu utilization (almost always because it has been recompiling .net code following the release of a new .net version via windows updates).