Windows-Automatisierung mit Polycrate: Ansible und WinRM ohne Schmerzen

TL;DR

• Du richtest WinRM einmal sauber mit HTTPS, Zertifikat und Firewall-Regeln ein und hast danach eine stabile Basis für Ansible-Automatisierung auf Windows-Servern.
• Mit Polycrate läuft Ansible inklusive aller WinRM- und Python-Abhängigkeiten im Container – kein pywinrm-Chaos, keine lokalen Installationen, keine Versionsdiskussionen im Team.
• Windows-Automatisierung ist im Polycrate-Ansible-Image schon enthalten: u. a. die Collection ansible.windows (z. B. win_service, win_updates), pywinrm und das passende Ansible-Bundle – ohne eigenes Dockerfile, ohne manuelles ansible-galaxy-Nachinstallieren für den üblichen Einsatz. Du konfigurierst nur noch Workspace, Inventory und Playbooks.
• Ein eigener Polycrate-Block für Windows bildet deine wiederverwendbare „Windows-Toolbox“: Dienste verwalten, Features installieren, Registry anpassen, Software verteilen, Patches einspielen – alles als klar strukturierte Actions.
• Passwörter und andere Secrets landen in secrets.poly und werden über die eingebaute Workspace-Verschlüsselung mit age abgesichert – nicht im inventory.yml.
• ayedo unterstützt Windows-Teams mit praxisnahen Automatisierungs-Blueprints, Polycrate-Implementierung und einem fokussierten Windows-Automatisierung Workshop – von WinRM-Basics bis zu skalierbarem Patch-Management.

Warum Windows-Admins sich mit Polycrate + Ansible beschäftigen sollten

Viele Windows-Admins schauen skeptisch auf Ansible:

• „Das ist doch ein Linux-Tool.“
• „WinRM einrichten ist nervig.“
• „Python, pywinrm, OpenSSL – das will ich nicht alles lokal anfassen.“

Technisch gesehen ist Ansible ein hervorragendes Werkzeug, gerade für Windows:

• Es gibt eigene Collections wie ansible.windows und community.windows.
• Du kannst Dienste, Rollen/Features, Registry, Software und Patches idempotent verwalten.
• Du bekommst saubere, nachvollziehbare Änderungen mit Playbooks, die sich gut versionieren lassen.

Was in der Praxis weh tut, ist etwas anderes:

1. Dependency-Problem:
   Auf jedem Admin-Laptop und jeder Jump-Box dieselben Python-/Ansible-/WinRM-Versionen zu pflegen, ist anstrengend – und sicherheitssensibel.

2. Playbook-Wildwuchs:
   Fünf verschiedene Skript-Ordner, leicht unterschiedliche Playbooks, niemand weiß, was „offiziell“ ist.

3. Secrets überall:
   Passwörter in inventory.yml, in group_vars, in Skripten – und dann kommt der Audit.

Polycrate setzt genau hier an:

• Das mitgelieferte Image bringt Ansible für Windows inklusive ansible.windows und pywinrm mit – die Windows-Module sind nicht „optional nachzurüsten“, sondern Teil der Standard-Toolchain. Für typische ansible.windows.*-Playbooks brauchst du kein zusätzliches Dockerfile.poly und kein manuelles ansible-galaxy collection install ansible.windows. Nur wenn du weitere Collections brauchst, erweiterst du das Image (z. B. community.windows).
• Ansible läuft immer in einem Container – identisch auf jedem Rechner.
• Deine Automatisierung ist in Blöcke strukturiert, die du lokal oder über eine OCI-Registry und den PolyHub teilen kannst.
• Workspace-Verschlüsselung mit age sorgt dafür, dass du Passwörter in secrets.poly sicher ablegen kannst, ohne extra Vault-Lösung.

In diesem Beitrag bauen wir das Schritt für Schritt auf – mit Fokus auf Windows-Admins ohne Cloud-Native-Vorkenntnisse.

WinRM einmal richtig einrichten: HTTPS, Zertifikat, Firewall

Bevor Ansible über Polycrate mit deinen Windows-Servern sprechen kann, muss WinRM vernünftig konfiguriert sein. Wir konzentrieren uns auf:

• HTTPS (Port 5986)
• Zertifikat (Self-Signed oder aus eurer PKI)
• Firewall-Freigabe
• Authentifizierung mit NTLM

Schritt 1: WinRM-Dienst aktivieren

Auf dem Ziel-Server (z.B. Windows Server 2022) öffnest du eine PowerShell als Administrator:

winrm quickconfig

Wenn der Dienst noch nicht läuft, wirst du gefragt, ob er konfiguriert werden soll. Bestätige das.

Das legt in der Regel einen HTTP-Listener auf Port 5985 an. Für Ansible über das Internet oder in sensiblen Netzen solltest du HTTP abschalten und HTTPS nutzen.

Schritt 2: Zertifikat für HTTPS erstellen oder zuweisen

Für Test- und kleine Umgebungen reicht ein Self-Signed-Zertifikat. In einer Domäne solltest du besser ein Zertifikat aus eurer Unternehmens-PKI verwenden.

Self-Signed-Beispiel:

$newCert = New-SelfSignedCertificate `
  -DnsName "win01.acme-corp.com" `
  -CertStoreLocation "Cert:\LocalMachine\My"

Merke dir den Thumbprint:

$newCert.Thumbprint

In produktiven Umgebungen ersetzt du diesen Schritt durch ein ausgestelltes Server-Zertifikat aus eurer CA.

Schritt 3: HTTPS-Listener für WinRM konfigurieren

Zuerst existierende HTTP-Listener prüfen:

winrm enumerate winrm/config/Listener

HTTPS-Listener mit deinem Zertifikat erstellen (Thumbprint einsetzen):

$thumb = "<DEIN_THUMBPRINT>"

winrm create winrm/config/Listener?Address=*+Transport=HTTPS `
"@{Hostname=`"win01.acme-corp.com`"; CertificateThumbprint=`"$thumb`"}"

Falls bereits ein HTTPS-Listener existiert, kannst du ihn alternativ mit winrm set anpassen.

Sicherheitseinstellungen prüfen:

winrm get winrm/config

Wichtige Punkte:

• AllowUnencrypted sollte false sein.
• Unter Service/Auth sollte Basic im Idealfall false sein, NTLM/Kerberos sind vorzuziehen.

Schritt 4: Firewall für WinRM HTTPS öffnen

Standardport für WinRM über HTTPS ist 5986. Öffne den Port in der Windows-Firewall:

New-NetFirewallRule `
  -Name "WINRM_HTTPS_IN" `
  -DisplayName "WinRM over HTTPS" `
  -Protocol TCP `
  -LocalPort 5986 `
  -Direction Inbound `
  -Action Allow

Je nach Umgebung kannst du den Zugriff auf bestimmte Subnetze oder Management-Server beschränken.

Schritt 5: Verbindung von einem Test-Client prüfen

Von einem Admin-Rechner (oder einer Jump-Box) kannst du mit PowerShell prüfen, ob HTTPS funktioniert:

Test-WsMan win01.acme-corp.com -UseSSL

Wenn das klappt, sind die technischen Grundlagen für Ansible gelegt. Mit plain Ansible würdest du jetzt Python, Ansible, pywinrm und SSL-Libraries installieren und passend konfigurieren.

Mit Polycrate überspringst du diesen Teil komplett – das bringt uns zum Workspace.

Polycrate-Workspace für Windows-Hosts

Wir legen einen einfachen Polycrate-Workspace an, der deine Windows-Server verwaltet.

workspace.poly mit Windows-Block

Im Root-Verzeichnis deines Workspaces liegt die workspace.poly:

name: acme-corp-automation
organization: acme

blocks:
  - name: windows-baseline
    from: windows-baseline
    config:
      windows_group: "windows"

Was hier passiert:

• name: Der Name deines Workspaces, z.B. dein Team oder Projekt.
• blocks: Liste der Block-Instanzen. Wir haben einen Block windows-baseline, der aus einem lokalen Verzeichnis ./blocks/windows-baseline kommt.
• config.windows_group: Die Hosts-Gruppe, auf die sich dieser Block standardmäßig bezieht.

Mehr zu Workspaces findest du in der Workspace-Dokumentation.

inventory.yml für Windows

Direkt im Workspace-Root liegt inventory.yml. Wie im Beitrag Multi-Server-Management mit Ansible-Inventories beschrieben, stehen alle Hosts unter all.hosts; unter children verweist die Gruppe windows nur noch per Hostname – gemeinsame WinRM-Parameter liegen in vars der Gruppe (keine Duplikate pro Host):

all:
  hosts:
    win01.acme-corp.com: {}
    win02.acme-corp.com: {}

  children:
    windows:
      hosts:
        win01.acme-corp.com:
        win02.acme-corp.com:
      vars:
        ansible_connection: winrm
        ansible_winrm_transport: ntlm
        ansible_port: 5986
        ansible_winrm_server_cert_validation: ignore

Wichtig:

• ansible_connection: winrm sagt Ansible, dass es WinRM nutzen soll.
• ansible_winrm_transport: ntlm wählt NTLM als Auth-Methode (passt gut zu vielen klassischen Windows-Umgebungen).
• ansible_winrm_server_cert_validation: ignore ist für Self-Signed-Zertifikate nützlich. In produktiven Umgebungen solltest du Zertifikate korrekt validieren.

Keine Passwörter im Inventory. Die kommen gleich in secrets.poly.

Weitere Details zur Ansible-Integration findest du in der Ansible-Dokumentation für Polycrate.

Secrets für Windows: Passwörter in secrets.poly statt in inventory.yml

Polycrate bringt Workspace-Verschlüsselung mit age direkt mit. Du musst kein externes Vault-Tool betreiben, um Passwörter sicher abzulegen.

secrets.poly anlegen

Im Workspace-Root legst du eine Datei secrets.poly an:

win_admin_user: "acme-admin"
win_admin_password: "SuperSicheresPasswort123!"

Bevor du diese Datei in Git eincheckst, verschlüsselst du den Workspace:

polycrate workspace encrypt

Details dazu findest du in der Dokumentation zur Workspace-Verschlüsselung.

Polycrate stellt dir diese Secrets im Playbook als workspace.secrets.* zur Verfügung. Das nutzen wir gleich, um ansible_user und ansible_password zu setzen – ohne sie im Inventory zu hinterlegen.

Der Windows-Block: Strukturierte Automatisierung statt Playbook-Wildwuchs

Jetzt definieren wir unseren Windows-Block. Das Verzeichnis ./blocks/windows-baseline enthält mindestens:

• block.poly
• baseline.yml (Windows-Basis-Konfiguration)
• patches.yml (Windows-Patch-Management)

block.poly für Windows

name: windows-baseline
version: 0.1.0
kind: generic

config:
  windows_group: "windows"

actions:
  - name: baseline
    description: "Windows-Basis-Konfiguration (Dienste, Features, Registry, Software)"
    playbook: baseline.yml

  - name: patches
    description: "Windows-Patch-Management mit win_updates"
    playbook: patches.yml

• kind: generic ist für klassische Ansible-Blöcke passend.
• Unter actions definierst du sprechende Aktionen, die jeweils ein Playbook ausführen.
• Über config.windows_group kannst du die Zielgruppe zentral steuern.

Best Practices zu Blöcken findest du in den Block-Best-Practices und in der Blocks-Dokumentation.

Actions ausführen

Eine Action ausführst du immer mit dem gleichen Schema:

polycrate run windows-baseline baseline

oder:

polycrate run windows-baseline patches

Polycrate startet dabei einen Container mit deiner definierten Toolchain, lädt den Workspace inklusive verschlüsselter Secrets und führt Ansible darin aus. Auf deinem Laptop musst du kein Ansible, Python oder pywinrm installiert haben.

Erste Windows-Aufgaben automatisieren: Dienste, Features, Registry, Software

Jetzt wird es konkret: Wir schreiben das Playbook baseline.yml und nutzen Module aus ansible.windows und community.windows.

baseline.yml: Windows-Basis-Konfiguration

- name: Windows-Baseline anwenden
  hosts: "{{ block.config.windows_group }}"
  gather_facts: false

  vars:
    ansible_user: "{{ workspace.secrets.win_admin_user }}"
    ansible_password: "{{ workspace.secrets.win_admin_password }}"
    ansible_connection: winrm
    ansible_winrm_transport: ntlm
    ansible_port: 5986
    ansible_winrm_server_cert_validation: ignore

  tasks:
    - name: Sicherstellen, dass der Dienst 'Spooler' läuft
      ansible.windows.win_service:
        name: Spooler
        start_mode: auto
        state: started

    - name: Feature 'Web-Server' (IIS) installieren
      ansible.windows.win_feature:
        name: Web-Server
        state: present
        include_sub_features: true
        restart: false

    - name: Registry-Key für Remote Desktop erlauben
      ansible.windows.win_regedit:
        path: HKLM:\System\CurrentControlSet\Control\Terminal Server
        name: fDenyTSConnections
        data: 0
        type: dword

    - name: Chocolatey installieren (falls nicht vorhanden)
      ansible.windows.win_chocolatey:
        state: present

    - name: 7zip über Chocolatey installieren
      ansible.windows.win_chocolatey:
        name: 7zip
        state: present

    - name: Custom MSI-Paket installieren
      ansible.windows.win_package:
        path: "\\\\fileserver.acme-corp.com\\software\\MyApp.msi"
        product_id: "{12345678-ABCD-1234-ABCD-1234567890AB}"
        state: present

Was hier passiert:

• hosts: Wir verwenden die Gruppe aus block.config.windows_group, also windows. So kannst du denselben Block in einem anderen Workspace mit anderer Gruppe verwenden.
• vars: Wir setzen Verbindungsparameter (User/Passwort, WinRM-Details) aus workspace.secrets.*. Das ist der Kern: keine Klartext-Passwörter im Inventory.
• ansible.windows.win_service: Dienst „Spooler“ muss laufen und automatisch starten. Das Modul gehört zu ansible.windows (nicht zu ansible-core); im Polycrate-Standard-Image ist das bereits enthalten (siehe TL;DR und Abschnitt „Polycrate setzt genau hier an“).
• ansible.windows.win_feature: Installiert die IIS-Rolle inklusive Subfeatures.
• ansible.windows.win_regedit: Schaltet Remote Desktop frei (klassisches Beispiel).
• ansible.windows.win_chocolatey: Installiert Chocolatey und anschließend ein Paket.
• ansible.windows.win_package: Installiert ein MSI von einem zentralen Share.

Mit plain Ansible würdest du das Playbook ähnlich schreiben – Ansible ist hier völlig okay. Der Unterschied liegt im Drumherum:

• Du müsstest lokal ansible.windows und community.windows bereitstellen.
• pywinrm und SSL-Abhängigkeiten sauber installieren.
• Dafür sorgen, dass alle Admins dieselbe Umgebung haben.

Mit Polycrate steckt all das im mitgelieferten Ansible-Container (siehe python-requirements.txt / Polycrate-Dockerfile: ansible-Bundle, pywinrm, zusätzliche Galaxy-Collections). Nur wenn du weitere Collections brauchst, erweiterst du das Image (z. B. Dockerfile.poly). Deine Kolleg:innen brauchen nur Polycrate und Docker – keine lokale Python-Feinabstimmung.

Windows-Patch-Management mit win_updates und Reboot-Handling

Patches sind ein typischer Use-Case, den Windows-Admins sauber automatisieren wollen – inklusive kontrolliertem Reboot.

patches.yml: Updates nach Kategorien installieren

- name: Windows-Patches installieren
  hosts: "{{ block.config.windows_group }}"
  gather_facts: false

  vars:
    ansible_user: "{{ workspace.secrets.win_admin_user }}"
    ansible_password: "{{ workspace.secrets.win_admin_password }}"
    ansible_connection: winrm
    ansible_winrm_transport: ntlm
    ansible_port: 5986
    ansible_winrm_server_cert_validation: ignore

  tasks:
    - name: Sicherheits- und kritische Updates installieren
      ansible.windows.win_updates:
        category_names:
          - SecurityUpdates
          - CriticalUpdates
        state: installed
        reboot: yes
      register: update_result

    - name: Bei Bedarf neu starten
      ansible.windows.win_reboot:
        msg: "System wird für Windows-Updates neu gestartet."
        pre_reboot_delay: 60
        post_reboot_delay: 120
      when: update_result.reboot_required

Erklärung:

• ansible.windows.win_updates steuert, welche Updates installiert werden sollen; über category_names kannst du granular filtern.
• reboot: yes erlaubt win_updates, einen Neustart zu initiieren, falls nötig.
• ansible.windows.win_reboot behandelt den Neustart sauber im Ansible-Kontext und wartet, bis der Host wieder erreichbar ist.

Aus Sicht eines Windows-Admins ist das der Punkt, an dem Ansible glänzt: Du kannst ein reproduzierbares Patch-Playbook bauen, das du z.B. monatlich per Polycrate-Workflow ausrollst.

Mehr zu Workflows findest du in der Workflows-Dokumentation.

Vergleich mit plain Ansible: Was Polycrate dir abnimmt

Stell dir vor, du willst das gleiche Setup mit plain Ansible aufbauen – ohne Polycrate:

1. Auf deinem Admin-Laptop:

   • Python in einer passenden Version installieren.
   • Ansible installieren (z.B. per pip oder Paketmanager).
   • pywinrm und requests-ntlm installieren.
   • ansible.windows und community.windows Collections installieren.
   • ansible.cfg anpassen (z.B. Inventory-Pfad, WinRM-Defaults).

2. Auf dem Laptop deiner Kolleg:innen:

   • Dasselbe Setup – und zwar möglichst identisch.
   • Regelmäßig Updates koordinieren, damit keine Versionsdrift entsteht.

3. In der Doku:

   • Installationsanleitungen pflegen („Bitte installiert Python 3.11.2, dann pip install ...“).
   • Audit-Fragen zu Supply-Chain-Risiken („Wer prüft die PyPI-Pakete?“).

Mit Polycrate ändern wir das Bild:

• Ansible, pywinrm, Collections usw. stecken in einem Container-Image.
• Du definierst die Toolchain einmal (z.B. per Dockerfile.poly) und teilst sie im Team.
• Polycrate startet den Container, mountet deinen Workspace und führt die Actions aus.

Zusätzlich bringt das Block-Modell Ordnung:

• Statt lose Playbooks im Filesystem hast du einen Windows-Block mit klar benannten Actions (baseline, patches).
• Du kannst diesen Block über eine OCI-Registry teilen – intern oder über den PolyHub.
• Andere Teams können deinen Block direkt konsumieren, ohne deinen gesamten Workspace kopieren zu müssen.

Die technischen Details zu Registry und Sharing findest du in der Registry-Dokumentation und in den Hinweisen zu PolyHub.

Häufige Fragen

Funktioniert das nur mit Domain-Joined Servern?

Nein. Ansible über WinRM mit ansible_connection: winrm und ansible_winrm_transport: ntlm funktioniert auch mit Workgroup-Servern, solange:

• die Namensauflösung passt (DNS oder Hosts-Datei),
• du gültige lokale oder Domänen-Credentials hast,
• die Firewall-Regeln WinRM-Zugriff zulassen.

In einer Domänenumgebung kannst du zusätzlich Kerberos nutzen, was in vielen Fällen sogar empfehlenswert ist. Für den Einstieg ist NTLM aber oft einfacher, gerade in gemischten Umgebungen.

Wie gehe ich mit unterschiedlichen Administrator-Accounts pro Server um?

Du hast mehrere Möglichkeiten:

• Pro Host in inventory.yml eigene Benutzer hinterlegen und nur das Passwort aus secrets.poly beziehen.
• In secrets.poly mehrere Credentials ablegen (z.B. win_admin_user_dmz, win_admin_user_intern) und im Block über block.config steuern, welcher Account verwendet wird.
• Für besonders sensible Systeme ganz andere Playbooks/Blöcke definieren.

Polycrate gibt dir mit workspace.secrets.* und block.config.* genug Flexibilität, ohne dass du Passwörter in Klartext-Dateien streuen musst. Wie du Variablen am besten strukturierst, beschreibt die Best-Practices-Dokumentation.

Wir nutzen bereits Ansible – lohnt sich Polycrate trotzdem?

Wenn du heute schon ein funktionierendes Ansible-Setup hast, bringt dir Polycrate vor allem:

• Standardisierte Toolchain: Keine Diskussionen mehr, wer welche Python-/Ansible-Version installiert hat.
• Struktur durch Blöcke: Du kapselst bestehende Playbooks in klare Actions, die auch Nicht-Spezialisten gefahrlos ausführen können.
• Eingebaute Verschlüsselung: Secrets in secrets.poly und verschlüsselten Workspace-Verzeichnissen, ohne zusätzliche Tools.

In vielen Teams ist der erste Schritt, vorhandene Playbooks weitgehend unverändert in einen Block zu „heben“ und sie dann nach und nach aufzuräumen. Wie dieser Migrationspfad aussehen kann, beschreiben wir in weiteren Beiträgen dieser Reihe.

Weitere Fragen? Siehe unsere FAQ

Praktische Umsetzung

Was haben wir in diesem Beitrag erreicht?

• Du weißt, wie du WinRM auf deinen Windows-Servern einmal sauber mit HTTPS, Zertifikat und Firewall-Regeln einrichtest.
• Du hast gesehen, wie ein Polycrate-Workspace mit inventory.yml, workspace.poly, secrets.poly und einem Windows-Block (block.poly) aufgebaut ist.
• Du kannst Ansible-Playbooks schreiben, die mit ansible.windows und community.windows Dienste, Features, Registry-Einträge, Software und Updates automatisiert verwalten – ohne lokale Ansible-Installation.
• Du nutzt die eingebauten Sicherheitsmechanismen von Polycrate: Workspace-Verschlüsselung mit age und Secrets in secrets.poly statt in inventory.yml.

Für Windows-Teams ist das oft der Punkt, an dem Automatisierung von „gelegentlichen Skripten“ zu einer belastbaren Plattform wird: reproduzierbar, teilbar, auditierbar.

Als ayedo begleiten wir solche Setups regelmäßig:

• Wir entwickeln gemeinsam mit euch Windows-spezifische Blöcke (z.B. Baseline-Hardening, Rollen-spezifische Konfigurationen, Patch-Workflows).
• Wir helfen, bestehende Skripte und Playbooks in saubere Polycrate-Blöcke zu überführen.
• Wir unterstützen bei der Integration in eure bestehenden Prozesse, etwa Change-Management oder Compliance-Vorgaben.

Wenn du diesen Weg nicht alleine gehen möchtest oder mit deinem Team in kurzer Zeit einen praxisnahen Einstieg suchst, ist unser Windows-Automatisierung Workshop der richtige Rahmen dafür – von WinRM-Basics bis zu skalierbarem Patch-Management mit Polycrate.

Windows-Automatisierung Workshop