I would troubleshoot the windows side first. Are you able to psremote from 
a windows node to the "problem" node using 5986 (ssl)?

On Tuesday, June 7, 2016 at 7:03:03 PM UTC+2, Matt Davis wrote:
>
> Seriously- best thing you could do is figure out why Fiddler isn't working 
> for you and get a trace... Knowing where it's failing in the process can 
> really narrow some things down.
>
> On Tuesday, June 7, 2016 at 9:18:43 AM UTC-7, J Hawkesworth wrote:
>>
>> Sorry, I don't have a specific suggestion where to look.  Sometimes I 
>> toss all the event logs and then poke things rather than filter for a 
>> specific event category.
>>
>> One of my colleagues tells me there's an rc6 for pywinrm 0.2 - might be 
>> worth trying that if you aren't on it already.
>>
>> On Tuesday, June 7, 2016 at 4:32:19 PM UTC+1, Mike Fennemore wrote:
>>>
>>> Yes have seen the articles but this was a properly sysprepped template. 
>>> Have recreated listeners, changed self-signed cert and still seems to yield 
>>> the same result. 
>>>
>>> Jon any particular logs I should focus on? The Windows Remote Management 
>>> and security logs don't seem to show anything out of the ordinary.
>>> On 07 Jun 2016 4:04 PM, "Christoph Wegener" <cweg...@gmail.com> wrote:
>>>
>>>> If you are referring to cloning a Windows machine without proper 
>>>> sysprep usage then that's very well possible. I remember seeing some WinRM 
>>>> blogs where people had problems due to duplicate SIDs ... not 100% sure 
>>>> though.
>>>>
>>>> On Monday, June 6, 2016 at 10:20:21 PM UTC+10, Mike Fennemore wrote:
>>>>>
>>>>> I'm beginning to think this might be as a result of the problem 
>>>>> servers being templated in VMWare perhaps?
>>>>>
>>>>> On Wednesday, June 1, 2016 at 7:41:50 PM UTC+2, Matt Davis wrote:
>>>>>>
>>>>>> Sorry, by "local user" I just meant using a non-domain user via 
>>>>>> pywinrm/Ansible. But yeah, for Basic to work, you'd have to 
>>>>>> (temporarily) 
>>>>>> enable unencrypted auth with something like:
>>>>>>
>>>>>> Set-Item WSMan:\localhost\Service\AllowUnencrypted $true
>>>>>>
>>>>>> The HTTPS_PROXY not working seems odd- I use it dozens of times a 
>>>>>> day... Sure you've got it exported? The problem is almost certainly on 
>>>>>> the 
>>>>>> control-machine side, as it'd just hang if the envvar worked and Fiddler 
>>>>>> wasn't configured properly.
>>>>>>
>>>>>> On Monday, May 30, 2016 at 12:45:48 AM UTC-7, Mike Fennemore wrote:
>>>>>>>
>>>>>>> For testing locally I'm assuming you mean Test-WSMan -Authentication 
>>>>>>> Basic -Credential <problem account> ? I am currently connecting on 5986 
>>>>>>> with ignore certificate validation turned on.
>>>>>>> So in that case I would add -UseSSL switch on the Test-WSMan. 
>>>>>>> Currently running Test-WSMan -Authentication Basic -Credential <problem 
>>>>>>> account> gives:
>>>>>>>
>>>>>>> Test-WSMAN : <f:WSManFault xmlns:f="
>>>>>>> http://schemas.microsoft.com/wbem/wsman/1/wsmanfault"; 
>>>>>>> Code="2150858974" Machine="Server101"><f:Message>The WinRM client 
>>>>>>> cannot 
>>>>>>> process the request. Unencrypted traffic is currently disabled in the 
>>>>>>> client configuration. Change the client configuration and try the 
>>>>>>> request 
>>>>>>> again. </f:Message></f:WSManFault>
>>>>>>> At line:1 char:1
>>>>>>>
>>>>>>> Normally I would say that would mean mean configuring 
>>>>>>> AllowUnencrypted on Winrm Client, however the other working systems do 
>>>>>>> not 
>>>>>>> have this configured.
>>>>>>>
>>>>>>> Running Test-WSMAN -Authentication Negotiate -Credential "<user>" 
>>>>>>> -ComputerName localhost returns:
>>>>>>>
>>>>>>> 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: 6.3.9600 SP: 0.0 Stack: 3.0
>>>>>>>
>>>>>>> I will try the Fiddler method shortly and return the results.
>>>>>>>
>>>>>>> On Friday, May 27, 2016 at 7:48:53 PM UTC+2, Matt Davis wrote:
>>>>>>>>
>>>>>>>> Hey Mike,
>>>>>>>>
>>>>>>>> Unfortunately pywinrm currently has *zero* logging/diagnostic 
>>>>>>>> capabilities (something I'd like to correct for troubleshooting stuff 
>>>>>>>> like 
>>>>>>>> this). Meantime...
>>>>>>>>
>>>>>>>> A couple of things to try:
>>>>>>>> - Does it work with Basic auth and a local user on that same box?
>>>>>>>> - Any chance you could run with Fiddler in the middle? Just run 
>>>>>>>> Fiddler on some Windows box, configure it to capture/decrypt HTTPS and 
>>>>>>>> to 
>>>>>>>> allow external connection, then on your Ansible controller, export 
>>>>>>>> HTTPS_PROXY=http://(ip-of-fiddler-box):8888/ and go watch the fun.
>>>>>>>>
>>>>>>>> I'm mostly just curious where the connection reset is occurring, as 
>>>>>>>> there are numerous round-trips involved here (eg, is it NTLM auth 
>>>>>>>> failure, 
>>>>>>>> resource issue, or something else?).
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Matt
>>>>>>>>
>>>>>>>>
>>>>>>>> On Friday, May 27, 2016 at 7:26:32 AM UTC-7, Mike Fennemore wrote:
>>>>>>>>>
>>>>>>>>> I have a selected few workgroup Windows server 2012 R2 servers 
>>>>>>>>> that give the following error:
>>>>>>>>>
>>>>>>>>> <10.128.44.37> ESTABLISH WINRM CONNECTION FOR USER: ansible_user 
>>>>>>>>> on PORT 5986 TO 10.128.44.37
>>>>>>>>> server_101 | UNREACHABLE! => {
>>>>>>>>>     "changed": false,
>>>>>>>>>     "msg": "ntlm: ('Connection aborted.', error(104, 'Connection 
>>>>>>>>> reset by peer'))",
>>>>>>>>>     "unreachable": true
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> I am using ntlm with Ansible 2.1.0.0 and pywinrm [kerberos] 2RC4. 
>>>>>>>>> I have tested the port is open, recreated the listeners, run a curl 
>>>>>>>>> to the 
>>>>>>>>> server which delivers a successful 411 response.
>>>>>>>>> Any ideas on further troubleshooting?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -- 
>>>> You received this message because you are subscribed to a topic in the 
>>>> Google Groups "Ansible Project" group.
>>>> To unsubscribe from this topic, visit 
>>>> https://groups.google.com/d/topic/ansible-project/rcYvdFVO9ss/unsubscribe
>>>> .
>>>> To unsubscribe from this group and all its topics, send an email to 
>>>> ansible-proje...@googlegroups.com.
>>>> To post to this group, send email to ansible...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/ansible-project/16e035a7-72da-4155-b0c6-7407d4ab1825%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/ansible-project/16e035a7-72da-4155-b0c6-7407d4ab1825%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/053f64d2-3e50-46ae-a3ff-295a35ff86f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to