Here are some commonly asked questions in regards to Ansible and Windows and their answers.
Note
This document covers questions about managing Microsoft Windows servers with Ansible. For questions about Ansible Core, please see the 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 lastest 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 cannot run on a Windows host and can only manage Windows hosts, but Ansible can be run under the Windows Subsystem for Linux (WSL).
Note
The Windows Subsystem for Linux is not supported by Microsoft or 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-pyp 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
Windows uses WinRM as the transport protocol. WinRM supports a wide range of authentication options. The closet option to SSH keys is to use the certificate authentication option which maps an X509 certificate to a local user.
The way that these certificates are generated and mapped to a user is different from the SSH implementation; consult the Windows Remote Management documentation for more information.
Ansible executes commands through WinRM. These processes are different from running a command locally in these ways:
Access is
Denied errors.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 become is used. See the Understanding Privilege Escalation documentation for more
information.win_scheduled_task. Like
become, it will bypass all WinRM restrictions, but it can only be used to run
commands, not modules.win_psexec to run a command on the host. PSExec does not use WinRM
and so will bypass any of the restrictions.See Understanding Privilege Escalation more info on how to use become. The limitations section at Windows Remote Management has more details around WinRM limitations.
See the 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 this 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.
Microsoft has announced and is developing a fork of OpenSSH for Windows that allows remote manage of Windows servers through the SSH protocol instead of WinRM. While this can be installed and used right now for normal SSH clients, it is still in beta from Microsoft and the required functionality has not been developed within Ansible yet.
There are future plans on adding this feature and this page will be updated once more information can be shared.
When trying to connect to a Windows host and the output error indicates that SSH was used, then this is an indication that the connection vars are not set properly or the host is not inheriting them correctly.
Make sure ansible_connection: winrm is set in the inventory for the Windows
host.
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
host.
See also