Ansible: Up and Running, 2nd Edition

Chapter 17. Managing Windows Hosts

Ansible is also known as SSH configuration management on steroids. Historically, Ansible has had a strong association with Unix and Linux, and we often see evidence of this in things like variable naming (e.g., ansible_ssh_host, ansible_ssh_connection, and sudo). However, Ansible has had built-in support for various connection mechanisms since the early days of the project.

Supporting an alien in terms of operating systems—as Windows is to Linux—was not only a matter of 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).

Note

Ansible introduced beta support of Microsoft Windows in version 1.7, but support has been out of beta only since version 2.1. In addition, the only way to run Ansible from a Windows host (i.e., to use a Windows-based control machine) is to run Ansible within the Windows Subsystem for Linux (WSL).

In terms of module contributions, Windows module contributions have been lagging behind a bit compared to the Linux community contributions.

Connection to Windows

To add Windows support, Ansible did not depart from its path by adding an agent on Windows—and in my opinion, this was a great decision. Ansible uses the integrated Windows Remote Management (WinRM) functionality, a SOAP-based protocol.

WinRM is our first dependency, and we need to get it covered in Python by installing the appropriate package ...