Ansible: Up and Running, 3rd Edition

Chapter 12. Managing Windows Hosts

Ansible is sometimes called “SSH configuration management on steroids.” Historically, Ansible has had a strong association with Unix and Linux, and we saw evidence of this in things like variable naming (ansible_ssh_host, ansible_ssh_connection, and sudo, for example). However, Ansible has had built-in support for various connection mechanisms since its early days.

Supporting unfamiliar operating systems—as Windows is to Linux—was a matter of not only figuring out how to connect to Windows but also making internal naming more operating-system generic (e.g., renaming variables ansible_ssh_host to ansible_host, and sudo to become).  

Windows module contributions have lagged a bit compared to the Linux community’s contributions. If you are interested in using Ansible to manage Windows systems, follow the blog posts of Jordan Borean, the Windows specialist on the Ansible Core team. He created the VirtualBox image we’ll use in this chapter.

Connection to Windows

To add Windows support, Ansible did not depart from its path by adding an agent on Windows—and in our opinion, this was a great decision. Introducing a new agent that listens on the network would introduce a new attack surface. Instead, Ansible uses the integrated Windows Remote Management (WinRM) functionality, a SOAP-based protocol over HTTPS created by Microsoft.

WinRM is the first dependency, and you should install the WinRM Python library in a virtualenv on the control host (authentication ...