Automation is key to efficient management of complex IT infrastructures. When dealing with mixed environments where Linux and Windows coexist, Ansible emerges as a powerful and flexible tool. I’ve personally witnessed how manually managing hundreds of Windows servers can turn into an operational nightmare: patching 350 servers manually every month meant 3 days of intensive work, with a high probability of human error. This is not just a waste of resources but a constant risk to security and infrastructure stability. The introduction of Ansible, correctly configured with WinRM, revolutionized this process, reducing execution time to just 45 minutes with centralized logs and the ability for automatic rollback. This article explores how to leverage Ansible to orchestrate Windows servers, focusing on secure WinRM configuration, the use of core modules, and practical automation scenarios, including Active Directory management and patching.
Prerequisites: WinRM, PowerShell 5.1+, .NET Framework
Before you can manage Windows servers with Ansible, it’s crucial to ensure that the prerequisites are met. The key protocol for communication between the Ansible controller (typically Linux) and Windows hosts is WinRM (Windows Remote Management). This SOAP-based service allows remote execution of PowerShell commands and access to WMI data. For optimal and secure operation, target Windows servers must have:
- Windows Management Framework (WMF) 5.1 or higher: This includes PowerShell 5.1, which improves scripting capabilities and WinRM reliability. Many modern Windows Server versions include it by default, but older ones might require an update.
- .NET Framework 4.5 or higher: Necessary for the correct functioning of PowerShell and WinRM.
Ensuring these components are up-to-date is the first step to avoid connectivity and compatibility issues. I’ve seen this error repeatedly: attempting to configure Ansible on Windows servers with outdated PowerShell versions, leading to cryptic errors and wasted time.
Configuring WinRM for Ansible Connections (Secure via HTTPS)
WinRM configuration is at the heart of communication between Ansible and Windows servers. For security purposes, it is imperative to configure WinRM to use HTTPS. This ensures that all communications are encrypted, protecting credentials and exchanged data.
On the Windows server, open a PowerShell console as an administrator and execute:
winrm quickconfig
Set-Item WSMan:\localhost\Service\AllowUnencrypted $falseThe winrm quickconfig command configures basic WinRM listeners and opens necessary firewall ports. Set-Item WSMan:\localhost\Service\AllowUnencrypted $false disables unencrypted connections, a fundamental best practice. For HTTPS, you need an SSL certificate (self-signed for testing, CA-signed for production) and to configure an HTTPS listener. This is an often-overlooked but critical step for compliance (e.g., NIS2 art. 21) and data protection.
# Create a self-signed certificate (FOR TESTING ONLY)
$cert = New-SelfSignedCertificate -DnsName "$env:COMPUTERNAME" -CertStoreLocation Cert:\LocalMachine\My
# Create an HTTPS listener
winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="$env:COMPUTERNAME"; CertificateThumbprint="$($cert.Thumbprint)"}
# Open port 5986 in the firewall (if not already opened by quickconfig)
New-NetFirewallRule -DisplayName "WinRM HTTPS" -Direction Inbound -LocalPort 5986 -Protocol TCP -Action AllowVerify that port 5986 (default HTTPS for WinRM) is accessible from the Ansible controller and that the certificate is trusted. In enterprise environments, a certificate issued by an internal CA is the standard.
Inventory and Variables for Windows Hosts
For Ansible, Windows hosts are defined in the inventory file, just like Linux hosts. The difference lies in the connection variables specific to WinRM.
Here’s an example inventory.ini:
[windows_servers]
winserver01.example.com
winserver02.example.com
[windows_servers:vars]
ansible_port=5986
ansible_connection=winrm
ansible_winrm_transport=kerberos # or ntlm, or basic if https
ansible_winrm_server_cert_validation=ignore # or validate for valid CA certificates
ansible_user=Administrator
ansible_password='YourStrongPassword'
# ansible_winrm_kinit_mode=always # For Kerberos
# ansible_winrm_kerberos_delegation=true # For KerberosKey variables are:
ansible_port: 5986 for HTTPS, 5985 for HTTP.ansible_connection: Must bewinrm.ansible_winrm_transport:kerberosfor Active Directory environments (highly recommended),ntlmas a fallback, orbasicif using HTTPS and no Kerberos.basicwith HTTPS is an acceptable compromise for less complex environments.ansible_winrm_server_cert_validation:ignoreis useful for testing with self-signed certificates, but in production,validatewill be used if the certificate is valid and trusted.
To test the connection, use the win_ping module:
ansible windows_servers -m win_ping -i inventory.iniIf the connection is successful, you will receive a pong response. This confirms that WinRM is correctly configured and Ansible can communicate with the Windows host.
Core Modules: win_package, win_service, win_file, win_reg
Ansible offers a rich set of Windows-specific modules that allow you to manage virtually every aspect of a server. These modules are idempotent, meaning they can be run multiple times without causing unintended side effects.
win_package: Installs, uninstalls, or updates MSI or executable software packages. I used this module to deploy EDR agents on 2,000 workstations.
- name: Install 7-Zip
win_package:
path: 'C:\temp\7z1900-x64.msi'
product_id: '{23170F69-40C1-2702-1900-000001000000}' # MSI product ID
state: presentwin_service: Manages the state of Windows services (started, stopped, restarted, disabled, enabled).
- name: Ensure the Spooler service is running and set to automatic
win_service:
name: Spooler
state: started
start_mode: autowin_file: Creates, modifies, or deletes files and directories, sets permissions.
- name: Create a directory
win_file:
path: C:\ansible_logs
state: directorywin_reg: Manages Windows registry keys and values.
- name: Set a registry value
win_reg:
path: HKLM:\SOFTWARE\MyCompany
name: 'Setting1'
data: 'Value1'
type: string
state: presentThese are just a few examples; the Ansible documentation for Windows modules is extensive and covers multiple management scenarios.
Managing Active Directory Users and Groups with Ansible
Automating Active Directory management is an area where Ansible can bring enormous benefits, especially in enterprise environments with frequent personnel changes or compliance requirements. Modules like win_ad_user, win_ad_group, win_domain_controller (and others) allow direct interaction with AD.
- name: Create a new AD user
win_ad_user:
name: 'jdoe'
firstname: 'John'
surname: 'Doe'
password: 'SuperSecurePassword123!'
enabled: yes
state: present
path: 'OU=Users,OU=MyDept,DC=example,DC=com'
- name: Add user to a group
win_ad_group_membership:
name: 'SG_IT_Admins'
members: 'jdoe'
state: present
scope: domainlocalAutomating the creation and management of user accounts and groups in AD significantly reduces manual errors and ensures that security policies (such as NIS2 art. 21, which requires access controls) are applied consistently. I have used this functionality to automate new employee provisioning, reducing onboarding time from hours to just a few minutes.
Installing and Configuring Software via Chocolatey
Chocolatey is a package manager for Windows, similar to apt on Debian/Ubuntu or yum on CentOS/RHEL. Integrating Chocolatey with Ansible greatly simplifies software installation and management at scale.
First, ensure Chocolatey is installed (via PowerShell or another Ansible playbook):
Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))Once installed, you can use the Ansible win_chocolatey module:
- name: Install Google Chrome via Chocolatey
win_chocolatey:
name: googlechrome
state: present
- name: Ensure Notepad++ is at latest version
win_chocolatey:
name: notepadplusplus
state: latestThis approach centralizes software management, ensuring applications are installed consistently and kept updated across all servers. Adopting a package manager is a modern best practice, even in Windows environments.
Complete Playbook: Monthly Windows Patching
Here is an example Ansible playbook to automate the monthly patching process for Windows servers. This playbook installs critical and security updates, handles reboots, and ensures the system is fully updated.
---
- name: Windows Monthly Patching
hosts: windows_servers
gather_facts: no
tasks:
- name: Check for pending reboots before patching
win_reboot_info:
register: reboot_info
- name: Reboot if pending reboot is detected
win_reboot:
when: reboot_info.pending_reboot
- name: Install Windows Updates
win_updates:
category_names: ['SecurityUpdates', 'CriticalUpdates']
reboot: yes
log_path: C:\Windows\AnsiblePatching.log
state: installed
register: update_result
- name: Report update status
debug:
msg: "Updates installed: {{ update_result.updates | length }}. Reboot required: {{ update_result.reboot_required }}."
- name: Reboot if required after updates
win_reboot:
when: update_result.reboot_required
- name: Ensure all updates are checked and applied (optional, second pass)
win_updates:
category_names: ['SecurityUpdates', 'CriticalUpdates']
state: installed
register: second_pass_result
- name: Final reboot if second pass required one
win_reboot:
when: second_pass_result.reboot_requiredThis playbook is a robust example: it handles potential pre-patching reboots, installs updates, reboots if necessary, and can perform a second pass to catch any dependent updates. Patching automation like this can reduce downtime, improve compliance, and free up IT staff for more strategic tasks. I have seen the percentage of unpatched servers drop from 15% to less than 1% thanks to a similar approach.
Common Errors and Troubleshooting
When using Ansible with Windows, some recurring issues can slow down implementation:
- Incorrectly configured WinRM: The most common problem. Verify that the service is running, listeners are active (especially HTTPS on port 5986), and the firewall is open. Remember
Set-Item WSMan:\localhost\Service\AllowUnencrypted $false. - Authentication issues: Incorrect credentials, NTLM/Kerberos problems. Ensure the user specified in
ansible_userhas the necessary permissions on the Windows server. For Kerberos, the Linux controller-side configuration (keytab,/etc/krb5.conf) is crucial. - Invalid or untrusted SSL certificates: If using HTTPS, the certificate must be valid and trusted by the Ansible controller. Using
ansible_winrm_server_cert_validation=ignorefor testing only is not a long-term solution. - Outdated PowerShell/WMF versions: Some Ansible modules might not work correctly with older PowerShell versions. Ensure servers are updated to PowerShell 5.1+.
- Windows Defender/Firewall: Sometimes, aggressive Windows security settings can block WinRM connections, even if the firewall rule is active. Check Windows event logs for details.
For debugging, increasing Ansible verbosity with -vvv or -vvvv can provide detailed information on connection errors and module execution.
FAQ — Frequently Asked Questions
How can I securely manage sensitive credentials (passwords) in Ansible for Windows?
For passwords and other sensitive credentials, it is essential to use Ansible Vault. This tool allows you to encrypt files or variables, ensuring that information remains protected when not in use. During playbook execution, Ansible will prompt for the Vault password to decrypt it, keeping credentials safe in your code repository. Never hardcode passwords in playbooks or inventory.
What is the difference between ansible_winrm_transport=ntlm and ansible_winrm_transport=kerberos?
ntlm (NT LAN Manager) is an older, challenge/response-based authentication protocol, less secure, and does not support delegation. kerberos is the standard authentication protocol in Active Directory environments, offering greater security, supporting delegation, and reducing the need to send cleartext passwords. For enterprise environments with AD, Kerberos is the preferred choice for stability and security. It requires specific configuration on the Ansible controller.
Can I use Ansible to manage Windows workstations (not just servers)?
Absolutely. Ansible is equally effective at managing Windows workstations. The win_package, win_updates, win_product_feature modules, and many others are perfectly suited for configuring, patching, and installing software on client PCs. The approach and prerequisites (WinRM, PowerShell) remain the same. I have used Ansible to deploy software and configure policies on 2,000 Windows workstations, significantly reducing the IT team’s workload.
Is it possible to use Ansible to deploy .NET or IIS applications?
Yes, Ansible offers specific modules for IIS management (win_iis_website, win_iis_webapplication, win_iis_virtualdirectory) and for installing Windows features (win_feature), which are essential for .NET application deployment. You can automate the entire deployment lifecycle, from configuring the IIS server and installing dependencies to copying application files and configuring the website. This ensures rapid and reproducible deployments.
Conclusions with Operational Takeaways
Integrating Ansible for Windows server management is no longer a niche, but an essential practice for any IT team aiming to improve efficiency, security, and compliance. On one hand, it drastically reduces the time spent on repetitive tasks like patching or initial server configuration. On the other hand, it increases configuration consistency, minimizes human errors, and provides complete traceability of every operation, crucial aspects for audits and regulatory requirements like NIS2. The initial investment in securely configuring WinRM and learning the specific Windows modules quickly pays off in terms of saved time and increased infrastructure resilience. Automation with Ansible transforms a Windows environment from a manual burden into a system manageable with the same agility as a Linux infrastructure.
Updated: June 2026
Read also: SSH Hardening Linux: Complete Guide 2026 (10 Critical Settings)
Read also: Ansible Provisioning: 12 Automated Server Tasks (2026)
Read also: FortiGate SSL VPN: Complete Secure Remote Access Setup (2026)
