Blog · 2026-10-19 · Gardience Engineering

Running Ansible playbooks on Windows without WinRM

WinRM is the hardest part of Ansible on Windows. Your three options today (WinRM done right, OpenSSH on Server 2022+, or an agent-based transport), with the trade-offs of each.

Ansible is the easiest configuration tool to start with, right up until the first Windows server. Then you meet WinRM: listeners and HTTPS certificates on every host, Kerberos or NTLM, the "double hop" problem, firewall rules for ports 5985 and 5986 inbound to every server, and a controller that holds credentials for all of them.

There are three ways to run playbooks on Windows today, each with real trade-offs.

Option 1: WinRM, done properly#

The default and the most documented path. Done well, it means:

• An HTTPS listener with a real certificate on every Windows host (not the self-signed listener from a quick setup script).
• Kerberos through Active Directory, so you are not sending NTLM credentials around.
• CredSSP or Kerberos delegation if playbooks touch network resources (the double hop).
• Inbound 5986 open from the controller to every host.

It works and it is supported. The cost is operational: certificates to rotate, a management port open on every server, and a controller that can log in everywhere.

Option 2: OpenSSH#

Ansible's SSH connection is officially supported for Windows as of ansible-core 2.18, using Microsoft's built-in OpenSSH, version 7.9.0.0 or later. In practice that means Windows Server 2022 and later; Server 2019 ships an older OpenSSH (Ansible: Windows SSH).

If your fleet is all Server 2022 or newer, this removes certificates and Kerberos plumbing. You still distribute SSH keys, open an inbound port on every host, and Server 2016 and 2019 are left on WinRM.

Option 3: an agent that dials out#

The third way flips the direction. Instead of a controller connecting into every machine, an agent on each machine keeps an outbound connection to a central server, and the playbook's work travels over that connection. No inbound management port, no WinRM listener, no SSH keys on the hosts, and it works the same on Windows Server 2016 as on 2025.

This is what Gardience does. It runs on open-source Salt, whose agents already keep an authenticated, encrypted connection to the Salt master. Gardience runs your existing Ansible playbooks over that connection, on Windows and Linux, with no WinRM and no SSH keys, and builds the inventory from the machines you target.

What you get on top of plain Ansible:

• The same permissions, change windows, locks, and two-person approval as every other change.
• Every machine's result in a tamper-evident audit log.
• Native Windows management without playbooks: patching, a STIG/CIS-aligned baseline, services, packages and registry, from forms or an AI assistant that writes the Salt for you.

One limit to know: running a playbook means running commands on the machines, so in Gardience it needs command execution turned on for the server (it is off by default) and the right permissions for the person running it.

Which one should you pick?#

Questions#

Can Ansible manage Windows over SSH?#

Yes, officially since ansible-core 2.18, with Microsoft's built-in OpenSSH 7.9.0.0 or later, which in practice means Windows Server 2022 and newer.

Do I have to rewrite my Windows playbooks to run them through Gardience?#

No. Gardience runs existing playbooks as they are, over the Salt connection, in controller mode.

Is an agent less secure than agentless?#

It changes the direction of trust. With an outbound-only agent there is no inbound management port on the servers and no central store of Windows admin passwords. The agent authenticates with its own key pair and the server approves each one.