Here are some commonly asked questions in regards to Ansible and Windows and their answers.
This document covers questions about managing Microsoft Windows servers with Ansible. For questions about Ansible Core, please see the general FAQ page.
Ansible does not support managing Windows XP or Server 2003 hosts. The supported operating system versions are:
Ansible also has minimum PowerShell version requirements - please see Setting up a Windows Host for the latest information.
Windows Nano Server is not currently supported by Ansible, since it does not have access to the full .NET Framework that is used by the majority of the modules and internal components.
No, Ansible can only manage Windows hosts. Ansible cannot run on a Windows host natively, though it can run under the Windows Subsystem for Linux (WSL).
The Windows Subsystem for Linux is not supported by Ansible and should not be used for production systems.
To install Ansible on WSL, the following commands can be run in the bash terminal:
sudo apt-get update sudo apt-get install python-pip git libffi-dev libssl-dev -y pip install ansible pywinrm
To run Ansible from source instead of a release on the WSL, simply uninstall the pip installed version and then clone the git repo.
pip uninstall ansible -y git clone https://github.com/ansible/ansible.git source ansible/hacking/env-setup # To enable Ansible on login, run the following echo ". ~/ansible/hacking/env-setup -q' >> ~/.bashrc
SSH keys are not supported when using the WinRM or PSRP connection plugins. These connection plugins support X509 certificates for authentication instead of the SSH key pairs that SSH supports.
The way X509 certificates are generated and mapped to a user is different from the SSH implementation; consult the Windows Remote Management documentation for more information.
Ansible 2.8 has added experimental support for using the SSH connection plugin, which supports authentication with SSH keys, to connect to Windows servers. See this question for more information.
Ansible executes commands through WinRM. These processes are different from running a command locally in these ways:
Access is Deniederrors.
Some ways to bypass these restrictions are to:
become, which runs a command as it would when run locally. This will bypass most WinRM restrictions, as Windows is unaware the process is running under WinRM when
becomeis used. See the Understanding Privilege Escalation documentation for more information.
become, it will bypass all WinRM restrictions, but it can only be used to run commands, not modules.
win_psexecto run a command on the host. PSExec does not use WinRM and so will bypass any of the restrictions.
See this question for more information about WinRM limitations.
Most of the Ansible modules in Ansible Core are written for a combination of Linux/Unix machines and arbitrary web services. These modules are written in Python and most of them do not work on Windows.
Because of this, there are dedicated Windows modules that are written in PowerShell and are meant to be run on Windows hosts. A list of these modules can be found here.
In addition, the following Ansible Core modules/action-plugins work with Windows:
No, the WinRM connection protocol is set to use PowerShell modules, so Python
modules will not work. A way to bypass this issue to use
delegate_to: localhost to run a Python module on the Ansible controller.
This is useful if during a playbook, an external service needs to be contacted
and there is no equivalent Windows module available.
Ansible 2.8 has added experimental support for using the SSH connection plugin
to manage Windows hosts. To connect to Windows hosts over SSH, you must install and configure the Win32-OpenSSH
fork that is in development with Microsoft on
the Windows host(s). While most of the basics should work with SSH,
Win32-OpenSSH is rapidly changing, with new features added and bugs
fixed in every release. It is highly recommend you install the latest release
Win32-OpenSSH from the GitHub Releases page when using it with Ansible
on Windows hosts.
To use SSH as the connection to a Windows host, set the following variables in the inventory:
ansible_connection=ssh # Set either cmd or powershell not both ansible_shell_type=cmd # ansible_shell_type=powershell
The value for
ansible_shell_type should either be
cmd if the
DefaultShell has not been configured on the SSH service
powershell if that has been set as the
Unless you are using
Win32-OpenSSH as described above, you must connect to
Windows hosts using Windows Remote Management. If your Ansible output indicates that
SSH was used, either you did not set the connection vars properly or the host is not inheriting them correctly.
ansible_connection: winrm is set in the inventory for the Windows
This can be due to a myriad of reasons unrelated to incorrect credentials.
See HTTP 401/Credentials Rejected at Setting up a Windows Host for a more detailed guide of this could mean.
When the Ansible controller is running on Python 2.7.9+ or an older version of Python that has backported SSLContext (like Python 2.7.5 on RHEL 7), the controller will attempt to validate the certificate WinRM is using for an HTTPS connection. If the certificate cannot be validated (such as in the case of a self signed cert), it will fail the verification process.
To ignore certificate validation, add
ansible_winrm_server_cert_validation: ignore to inventory for the Windows