Errores esporádicos de respuesta con máquinas Windows

Me encuentro con algunos problemas de encendido y apagado cuando uso hosts de Windows en mis libros de jugadas Ansible. Estoy ejecutando Ansible 2.3 con pywinrm 0.2.2 instalado. Estoy usando autenticación básica con el usuario administrador local.

A veces recibo este problema cuando ejecuto una tarea:

 [WARNING]: FATAL ERROR DURING FILE TRANSFER: Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/ansible/plugins/connection/winrm.py", line 267, in _winrm_exec
  self._winrm_send_input(self.protocol, self.shell_id, command_id, data, eof=is_last)
File "/usr/local/lib/python2.7/dist-packages/ansible/plugins/connection/winrm.py", line 248, in _winrm_send_input
  protocol.send_message(xmltodict.unparse(rq))
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 191, in send_message
   raise WinRMTransportError('http', error_message) WinRMTransportError: (u'http', u'Bad HTTP response returned from server. Code 500')

Otras veces, cuando intenta ejecutar una win_shell/win_command/raw moduley with_itemsen un grupo de hosts de Windows que parece fallar en los archivos temporales creados por Ansible.

La tarea que intento ejecutar es:

- name: Check services up
  win_command: 'sc queryex {{ item }} | Findstr RUNNING'
  with_items: '{{ component_services }}'
  register: command_result
  ignore_errors: yes

Y el error que puedo obtener es:

changed: [172.16.104.169] => (item=Dnscache)
failed: [172.16.104.176] (item=Dnscache) => {"failed": true, "item": "Dnscache", 
  "module_stderr": "Exception calling \"Run\" with \"1\" argument(s): \"Exception calling \"Invoke\" with \r\n\"0\" 
     argument(s): \"The running command stopped because 
           the preference variable \r\n\"ErrorActionPreference\" 
           or common parameter is set to 
   Stop: (0) : cannot open \r\nC:\\Users\\ADMINI~1\\AppData\\Local\\Temp\\RESB3FF.tmp 
  for writing\r\n(1) : 
     using System;\r\n\"\"\r\nAt line:45 char:1\r\n+ 
     $output = $entrypoint.Run($payload)\r\n+ 
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n+ 
  CategoryInfo          : NotSpecified: (:) [], ParentContainsErrorRecordE \r\nxception\r\n+ 
  FullyQualifiedErrorId : ScriptMethodRuntimeException\r\n", 
  "module_stdout": "", "msg": "MODULE FAILURE", "rc": 1}
     changed: [172.16.104.141] => (item=Dnscache)
     changed: [172.16.104.168] => (item=Dnscache)
     changed: [172.16.104.145] => (item=Dnscache)

Ambos problemas son absolutamente aleatorios e incluso pueden no aparecer en una secuencia de ejecuciones diferentes.

Cualquier ayuda?

Probablemente debería crear un problema Ansible para esto, ya que es muy probable que sea un error en Ansible.

El primer error me hace pensar en la canalización de WinRM:

• Ansible 2.3.0 introdujo una característica de canalización WinRM siempre activa (similar a la canalización SSH ), y eso puede estar detrás de esto.
• La canalización de SSH puede causar problemas en Ansible para Linux, y puede ser útil desactivarla, pero esto aún no es posible para la canalización de WinRM.

Este problema relacionado incluye algunas confirmaciones de Git que volverán a habilitar el modo 'no interconectado' en una versión futura (ahora debería lanzarse en 2.4, posiblemente con un backport como parte de 2.3.2 - vea este comentario )

Intente actualizar a Ansible 2.4.1+ (que generalmente funciona bien) para obtener la solución. O intente bajar a Ansible 2.2.3 para ver si esto ayuda: esto deshabilitará la canalización de WinRM y puede evitar otros errores de regresión en esta área.

• Si instaló Ansible usando pip, puede hacerlo pip install ansible==2.4.1 para actualizar (o ansible==2.2.3degradar), luego, si eso no ayuda, haga lo mismo 2.3.1para actualizar nuevamente.
• También debe actualizar a la última pywinrmcomo se menciona en los problemas anteriores

He encontrado que Ansible 2.3.2 es el más estable, aunque todavía no he pasado mucho tiempo con 2.4.1. 2.4.0 definitivamente tiene algunos problemas de estabilidad cuando se trata de winrm.