Legacy WinRM
When establishing remote communication on Windows Server 2016 or newer, configuring legacy WinRM listeners and firewall rules enables default, SOAP-based connectivity over HTTP/HTTPS.
Advantages
- Native to Windows (service enabled by default on Server 2016+).
- Deep integration with Active Directory authentication (Kerberos, NTLM).
- Supports CredSSP for "double-hop" authentication, for example, accessing a network share from the managed node.
Disadvantages
- Performance: Relies on XML/SOAP overhead. Each Ansible task spins up a new powershell.exe process, which is highly CPU-intensive and slow.
- Configuration Complexity: Setting up HTTPS listeners and managing WinRM certificates can be burdensome without existing PKI automation.
Ansible communicates with Windows hosts over the WinRM protocol using one of two connection plugins. While both use the same underlying protocol, they have different implementations and capabilities:
- ansible.builtin.winrm: The original WinRM connection plugin. While still fully functional, it is often superseded by PSRP for new deployments. It provides specific timeout controls, such as
ansible_winrm_operation_timeout_secandansible_winrm_read_timeout_sec, which can be tuned for long-running tasks. - psrp (PowerShell Remoting Protocol): For new deployments on Ansible Automation Platform, the psrp connection plugin is the recommended choice over winrm. It offers better performance and handles heavy loads more effectively. Use
ansible_connection: psrpin your inventory to enable this.