Using Ansible for Windows System Management: What You Need to Know

Original source reference: searchitoperations.techtarget.com (2019)

Can Ansible Manage Windows Systems?

Ansible is a widely used configuration management and automation tool with deep roots in the Linux ecosystem. However, it can also target Windows hosts for configuration, provisioning, and application lifecycle management. The catch: the setup process is noticeably more complex than it is on Linux, and there are meaningful constraints on how Windows machines can participate in an Ansible environment.

How Ansible Communicates with Windows Hosts

On Linux, Ansible uses SSH to communicate with managed nodes. Because SSH is available by default on most Linux distributions, getting Ansible to control a Linux host is relatively straightforward.

Windows is different. Rather than SSH, Ansible communicates with Windows hosts over WinRM (Windows Remote Management) using PowerShell. To prepare a Windows host for Ansible management, the following minimum requirements must be met on the managed node:

• PowerShell 3.0 or higher
• .NET Framework 4.0 or higher
• WinRM configured and enabled

Ansible’s official documentation includes a ConfigureRemotingForAnsible.ps1 script that automates much of the WinRM setup on Windows managed nodes. Running this script is typically one of the first steps when onboarding a Windows host.

Where the Ansible Control Node Must Run

A critical architectural point: the Ansible control node—including Ansible Tower (now AWX/Red Hat Ansible Automation Platform)—must run on Linux. Ansible itself cannot natively execute on a Windows host as the control machine.

If your only available machine is a Windows server, you have two realistic options:

• Run a Linux virtual machine on the Windows host and use that VM as the Ansible control node.
• Use Windows Subsystem for Linux (WSL)—a Microsoft feature available since Windows 10 that allows native Linux command-line tools to run on Windows. WSL can be installed from the Microsoft Store.

It is important to note that Ansible does not officially support WSL for production use. WSL may be suitable for development, testing, or learning purposes, but relying on it in a production environment is not recommended based on Ansible’s own guidance.

What Windows Can and Cannot Do in an Ansible Environment

Understanding the role Windows can play helps set accurate expectations:

Because Python modules cannot run directly on Windows managed nodes, teams that rely heavily on Python-based Ansible modules need to account for this. A common workaround is to run those modules on the Ansible controller itself using the delegate_to: localhost directive in a playbook task.

Setting Up Ansible to Manage a Windows Host: Key Steps

Unlike Linux, where a single apt-get install ansible or dnf install ansible command gets you most of the way there, managing Windows with Ansible requires several configuration steps across both the control node and the managed Windows host.

On the Windows Managed Node

1. Verify PowerShell 3.0+ and .NET 4.0+ are installed.
2. Enable and configure WinRM (use the Ansible-provided setup script for convenience).
3. Configure firewall rules to allow WinRM traffic (typically TCP 5985 for HTTP, 5986 for HTTPS).
4. Set up an appropriate authentication method (Basic, NTLM, Kerberos, or CredSSP depending on your environment).

On the Ansible Control Node (Linux)

1. Install Ansible on your Linux control node.
2. Install the pywinrm Python library, which Ansible requires to communicate with Windows hosts over WinRM: pip install pywinrm
3. Define Windows hosts in your inventory file with the correct connection variables:

[windows]
win-server-01 ansible_host=192.168.1.10

[windows:vars]
ansible_user=Administrator
ansible_password=YourPassword
ansible_connection=winrm
ansible_winrm_transport=ntlm
ansible_winrm_server_cert_validation=ignore

Always store credentials securely using Ansible Vault rather than plaintext in inventory files.

Why Windows Teams Should Still Consider Ansible

Despite the added complexity, Ansible offers real value for organizations running Windows infrastructure:

• Unified tooling: A single configuration management platform can manage both Linux and Windows infrastructure, reducing the number of tools teams need to learn and maintain.
• Agentless architecture: Like Linux, Windows managed nodes do not require an Ansible agent installed—only WinRM must be configured.
• Rich Windows module library: Ansible ships with many Windows-specific modules covering tasks such as managing IIS, Active Directory, Windows features, registry keys, services, and software packages.
• DevOps and automation adoption: Teams can use the same playbook-based workflows for Windows application lifecycle management as they do for Linux workloads.

Summary

Ansible can absolutely be used to manage Windows systems—but Windows is strictly a managed node, not a control node. The Ansible controller must run on Linux (directly, via VM, or via WSL for non-production use). Windows managed nodes communicate via WinRM and PowerShell rather than SSH. The setup involves more steps than a typical Linux Ansible deployment, but the payoff is a unified automation platform capable of managing your entire infrastructure regardless of operating system.