AAP 2.6 Windows Automation: WinRM, PowerShell, and Active Directory Management
By Luca Berton · Published 2024-01-01 · Category: installation
Automate Windows infrastructure with AAP 2.6. Configure WinRM connectivity, run PowerShell scripts, manage Active Directory, deploy IIS, handle Windows Updates, and integrate with domain environments.
Windows Automation in AAP 2.6
AAP 2.6 provides full Windows automation support through WinRM (Windows Remote Management) and SSH. You can manage Windows servers, workstations, and Active Directory environments using the same platform that handles Linux infrastructure.
Prerequisites
Windows Host Requirements
| Requirement | Details | |-------------|---------| | PowerShell | 5.1 or later | | .NET Framework | 4.6 or later | | WinRM | Enabled and configured | | OS | Windows Server 2016+ or Windows 10/11 |
Enable WinRM on Windows Hosts
Run this PowerShell script on target Windows hosts:
Or use the Ansible-provided ConfigureRemotingForAnsible.ps1 script:
Credential Configuration
Machine Credential for Windows
Inventory Variables for WinRM
Connection Methods
| Transport | Auth Method | Use Case | |-----------|-------------|----------| | ntlm | NTLM | Domain and local accounts | | kerberos | Kerberos | Domain environments (most secure) | | credssp | CredSSP | Double-hop scenarios | | basic | Basic auth | Local accounts over HTTPS | | certificate | Client cert | Certificate-based auth |
Kerberos Configuration
For domain environments, Kerberos is recommended:
Common Windows Automation Tasks
Install Windows Features and Roles
Manage Windows Services
Windows Updates
Active Directory Management
Group Policy Management
Deploy IIS Website
PowerShell Script Execution
Windows Certificate Management
Execution Environment for Windows
Build a dedicated EE with Windows dependencies:
FAQ
Should I use WinRM or SSH for Windows?
WinRM is the standard and best-supported method. Windows OpenSSH works but has limitations: no become, no win_* modules (only shell/raw). Use WinRM for production Windows automation.
How do I handle the double-hop problem?
When connecting to a Windows host and needing to access a network resource (like a file share), you hit the double-hop problem. Use CredSSP transport (ansible_winrm_transport: credssp) or Kerberos delegation to resolve this.
Can I manage Windows hosts from Linux execution nodes?
Yes. The EE runs on Linux and connects to Windows hosts via WinRM over the network. No Windows software is needed on the execution node — just the Python pywinrm library (included in the EE).
How do I run domain join operations?
Use the microsoft.ad.membership module. The credential must have domain join permissions, and the WinRM connection must use Kerberos or NTLM with a domain account.
What about Windows Nano Server or Server Core?
Both are supported via WinRM. Server Core works identically to full installations. Nano Server has limited PowerShell support, so test modules before deploying.
Conclusion
AAP 2.6 treats Windows as a first-class automation target. From Active Directory management to IIS deployments, Windows Updates to PowerShell scripting, the platform provides comprehensive Windows automation capabilities alongside Linux. Build a dedicated Windows EE, configure WinRM with Kerberos for enterprise environments, and automate your entire Windows estate through the same platform.
Related Articles • AAP 2.6 Architecture and Components: Complete Guide • AAP 2.6 Execution Environments: Build, Manage, and Deploy Custom EEs • AAP 2.6 Credential Management: Vaults, External Secrets, and Machine Credentials • AAP 2.6 Job Templates and Inventories: Complete Configuration Guide • AAP 2.6 Automation Mesh: Distributed Execution Across Sites and Networks
Category: installation