Windows in brief, and why it is different

This course targets Linux. That is a deliberate scope decision and this lesson does not change it.

But Windows is the largest category of managed node that needs no Python at all, and an engineer who has just spent five lessons on interpreter discovery should know that an entire supported platform sidesteps the question — not least so that a Windows host appearing in an inventory does not read as a mystery.

What follows is orientation: enough to recognise the shape of the problem, understand the inventory you will see, and make an informed decision about scope. It is not a Windows curriculum, and at the end of the lesson the course says plainly where it stops.

The one-sentence version

A Windows managed node runs PowerShell modules, not Python modules. The controller ships PowerShell to it over a Windows-appropriate transport, and PowerShell 5.1 ships with every supported Windows version, so there is nothing to bootstrap.

The upstream documentation states the requirement directly: Windows nodes must be running Windows Server 2016 or Windows 10 or newer, and “as these versions of Windows ship with PowerShell 5.1 by default there are no additional requirements to bootstrap a Windows node.” PowerShell 7 is also supported.

Everything else in this lesson follows from that.

What changes

The last row is the reason this lesson sits in this part. Every interpreter question you have just learned to answer simply does not arise. Discovery does not run. There is no fallback list, no warning, no pinning decision, and no bootstrap play.

The three connections

ansible-core ships all three, and you can confirm that on the controller without touching a Windows host:

$ ansible-doc -t connection -l

ansible.builtin.local execute on controller
ansible.builtin.psrp  Run tasks over Microsoft PowerShell Remoting Protocol
ansible.builtin.ssh   connect via SSH client binary
ansible.builtin.winrm Run tasks over Microsoft's WinRM

Three of those four are Windows-capable. Briefly:

winrm — Windows Remote Management, the long-standing default. Well understood, widely deployed, and the one most existing documentation assumes. It needs a Python library on the controller to speak the protocol, which is a controller-side dependency and has nothing to do with the target.

psrp — PowerShell Remoting over the same underlying transport, but running inside a PowerShell interpreter rather than driving a shell. The plugin describes itself as “similar to the ansible.builtin.winrm connection plugin which uses the same underlying transport but instead runs in a PowerShell interpreter.” It is generally faster and handles some data types better.

ssh — Windows has had an OpenSSH server for years, and the ssh connection has worked against it since Ansible 2.8. It became officially supported in ansible-core 2.18, which is the version to quote if somebody asks whether it is production-appropriate.

Inventory, without breaking the Linux estate

The shape that works is a separate group with its own variables, and Linux patterns that cannot accidentally match it.

# inventory/production/windows.yml
windows:
  hosts:
    win-app01.example.com:
    win-app02.example.com:
  vars:
    ansible_connection: winrm
    ansible_port: 5986
    ansible_winrm_transport: kerberos
    ansible_user: REPLACE_ME

Two points about this.

ansible_python_interpreter does not appear, and must not. Setting it on a Windows group is harmless in the sense that nothing reads it, and harmful in the sense that it tells the next reader something false about how the host works.

The credentials are not in this file. ansible_user here is a placeholder; the password or Kerberos configuration belongs in Vault or an external secret manager, exactly as Part XXI describes for any other credential. Windows changes the authentication mechanisms available, not the rule about where secrets live.

If your Linux plays target hosts: all, adding this file changes the blast radius of every one of them. Narrow those patterns before adding Windows hosts, not after — Part XXX on host patterns and blast radius applies directly, and this is one of the few cases where a change to inventory alone can break a working estate.

Where this course stops

Plainly: this course does not teach Windows automation, and a Windows estate deserves its own treatment rather than a corner of this one.

The reasons are not about difficulty. They are about the amount of distinct knowledge involved, none of which this course covers:

• Authentication. Kerberos, NTLM, CredSSP, certificate authentication, and the domain-joined versus workgroup distinction. This is most of the operational difficulty of Windows automation and it has no Linux analogue.
• The double-hop problem — a Windows-specific credential delegation constraint that has no equivalent in the SSH model and that shapes how many real playbooks must be written.
• Domain and directory operations, which are a subject in themselves.
• A different module set with different idempotency characteristics, different check-mode support, and its own idioms.

If you have a Windows estate, that is a good reason to learn Windows automation properly from the upstream Windows guides, and to keep it in its own project with its own inventory, its own roles and its own review. Interleaving it with a Linux project produces a repository where half the roles fail against half the hosts and every pattern needs a comment.

The blast-radius argument that runs through this whole course is the strongest version of that recommendation. If a mistake in a Linux pattern can reach Windows hosts, or the reverse, you have doubled the consequence of every pattern error for no benefit.

Knowledge check