Windows-Software-Deployment ohne SCCM: Chocolatey und Ansible

TL;DR

• Du kannst standardisiertes Windows-Software-Deployment ohne teure SCCM-Infrastruktur umsetzen – mit Chocolatey als Paketmanager und Ansible als Steuerzentrale.
• Polycrate packt Ansible, Python und die gesamte Toolchain in einen Container, löst damit das Dependency-Problem und bringt Struktur in deine Automatisierung über wiederverwendbare Blöcke.
• Eine Software-Baseline wird als Polycrate-Block modelliert: Office-, Developer- und Server-Profile sind versioniert, reproduzierbar und per polycrate run ausführbar – ohne lokale Ansible-Installation.
• Über Gruppen im Inventory setzt du einen Rolling-Rollout um: erst Test-Workstations, dann breite Ausrollung in die Produktion.
• ayedo unterstützt Teams dabei, genau solche Szenarien in einem praxisnahen Software-Deployment Workshop zu modellieren und nachhaltig in den Betrieb zu bringen.

Das SCCM-Problem: Wenn der Overhead größer ist als der Nutzen

Viele Windows-Admins kennen das Dilemma: Microsoft Endpoint Configuration Manager (früher SCCM) ist mächtig, aber:

• Lizenzkosten sind hoch – besonders für kleinere und mittlere Umgebungen schwer zu rechtfertigen.
• Die Infrastruktur ist komplex (SQL Server, Site Server, Verteilpunkte).
• Änderungen brauchen lange Vorlaufzeit, weil alles erst „richtig“ in SCCM modelliert werden muss.
• Skripte und kleine Automatisierungsbausteine verschwinden in der GUI oder in Einzel-Skripten und sind schwer versionierbar.

Gleichzeitig ist der Bedarf klar:

• Standardsoftware wie 7-Zip, Browser, PDF-Viewer, Admin-Tools.
• Unterschiedliche Baselines: Office-User vs. Entwickler vs. Server.
• Reproduzierbarkeit: Eine neue Maschine soll in 30–60 Minuten auf demselben Stand sein wie die bestehenden.

An dieser Stelle sind Chocolatey, Ansible und Polycrate eine spannende Kombination: Du erreichst viele der Vorteile von SCCM (standardisiert, wiederholbar, auditierbar), ohne dessen Kosten und Komplexität.

Chocolatey als Windows-Paketmanager

Chocolatey ist – vereinfacht gesagt – apt oder yum für Windows:

• Pakete werden aus Repositories installiert (z. B. das öffentliche Chocolatey Repository oder ein internes).
• Installation, Update und Deinstallation laufen über einen konsistenten CLI-Befehl (choco install, choco upgrade, choco uninstall).
• Viele Standardtools gibt es bereits als fertiges Paket: Browser, Tools, Runtime-Umgebungen usw.

Für Admins bedeutet das:

• Keine manuellen MSI-Downloads und Klick-Installer mehr.
• Versionspinning ist trivial: choco install 7zip --version 22.1.0.
• Pakete sind skriptbar und damit ideal für Ansible geeignet.

Wichtig: In produktiven Umgebungen setzt du meist ein internes Chocolatey-Repository ein. Das Prinzip ändert sich aber nicht – nur die URL der Quelle.

win_chocolatey in Ansible: Pakete installieren, aktualisieren, entfernen

Ansible bringt mit win_chocolatey ein eigenes Modul mit, das genau diese Chocolatey-Funktionalität kapselt.

Ein minimales Beispiel-Playbook (ohne Polycrate, nur zur Einordnung):

- name: Windows Baseline mit Chocolatey
  hosts: windows_office
  gather_facts: false

  tasks:
    - name: Sicherstellen, dass Chocolatey installiert ist
      ansible.windows.win_chocolatey:
        name: chocolatey
        state: present

    - name: 7zip installieren
      ansible.windows.win_chocolatey:
        name: 7zip
        version: '22.1.0'
        state: present

    - name: Google Chrome installieren
      ansible.windows.win_chocolatey:
        name: googlechrome
        version: '118.0.5993.90'
        state: present

Mit plain Ansible bedeutet das für dich:

• Du brauchst lokal eine funktionierende Python- und Ansible-Installation.
• Alle im Team müssen kompatible Versionen nutzen, sonst kommt es zu „funktioniert bei mir“-Effekten.
• Du musst Ansible-Konfiguration (Inventory, ansible.cfg, Collections) selbst organisieren und dokumentieren.

Genau hier setzt Polycrate an.

Warum Polycrate ins Spiel kommt

Polycrate löst nicht Ansible ab – es gibt Ansible eine saubere, wiederverwendbare Verpackung.

Die relevanten Vorteile in diesem Szenario:

1. Dependency-Problem gelöst

   • Ansible läuft in einem Container, der von Polycrate bereitgestellt wird.
   • Kein lokales Python-Chaos, keine unterschiedlichen Ansible-Versionen im Team.
   • Über ein Dockerfile.poly oder ein Setup-Skript kommen zusätzliche Tools (z. B. choco, pwsh, kubectl) konsistent dazu.
   • Alle Kolleg:innen nutzen exakt die gleiche Toolchain – egal ob Laptop, VDI oder Terminalserver.

   Mehr dazu in der Ansible-Integration von Polycrate.

2. Guardrails und Sharable Automation

   • Anstatt einzelner Playbooks gibt es Blöcke, die klar strukturiert sind (mit block.poly).
   • Diese Blöcke können versioniert und in einer OCI-Registry geteilt werden.
   • Ein Block registry.acme-corp.com/acme/windows/windows-software-baseline:0.1.0 ist ein „Produkt“, das dein Team nutzen, testen und weitergeben kann – intern oder über den PolyHub.

   Best Practices dazu findest du unter Polycrate Best Practices.

3. Sichere Konfiguration

   • Lizenzschlüssel, interne Repository-URLs oder Admin-Credentials legst du im Workspace ab und verschlüsselst sie mit polycrate workspace encrypt.
   • Die eingebaute age-Verschlüsselung erleichtert Compliance ohne zusätzliches Tooling.
   • Details dazu: Workspace-Verschlüsselung in Polycrate.

Für dich als Windows-Admin heißt das: Du konzentrierst dich auf die Playbooks und die Software-Baselines – Polycrate kümmert sich um Toolchain, Struktur und Wiederverwendung.

Der Workspace: acme-corp-automation

Wir bauen ein Beispiel für die fiktive acme-corp.com:

• Drei Zielgruppen:
  • office-workstation
  • developer-workstation
  • server
• Jeweils eigene Host-Gruppen im Ansible-Inventory.
• Eine gemeinsame Software-Baseline als Polycrate-Block.

Ein minimales inventory.yml im Workspace-Root könnte so aussehen:

all:
  hosts:
    win-office-01.acme-corp.com: {}
    win-office-10.acme-corp.com: {}
    win-dev-01.acme-corp.com: {}
    win-srv-01.acme-corp.com: {}

  children:
    windows_office_test:
      hosts:
        win-office-01.acme-corp.com:
      vars:
        ansible_user: Administrator
        ansible_connection: winrm
        ansible_winrm_server_cert_validation: ignore

    windows_office_prod:
      hosts:
        win-office-10.acme-corp.com:
      vars:
        ansible_user: Administrator
        ansible_connection: winrm
        ansible_winrm_server_cert_validation: ignore

    windows_developer:
      hosts:
        win-dev-01.acme-corp.com:
      vars:
        ansible_user: Administrator
        ansible_connection: winrm
        ansible_winrm_server_cert_validation: ignore

    windows_servers:
      hosts:
        win-srv-01.acme-corp.com:
      vars:
        ansible_user: Administrator
        ansible_connection: winrm
        ansible_winrm_server_cert_validation: ignore

Keine Passwörter im Inventory – ansible_password setzen Sie in den Playbooks aus secrets.poly / workspace.secrets.* (siehe Workspace-Verschlüsselung).

Polycrate setzt ANSIBLE_INVENTORY automatisch auf diese Datei. Du brauchst keine zusätzliche ansible.cfg.

Unser workspace.poly definiert, welche Blöcke es gibt:

name: acme-corp-automation
organization: acme

blocks:
  - name: windows-office-baseline
    from: registry.acme-corp.com/acme/windows/windows-software-baseline:0.1.0
    config:
      profile: office
      target_group: windows_office_test

  - name: windows-developer-baseline
    from: registry.acme-corp.com/acme/windows/windows-software-baseline:0.1.0
    config:
      base_profile: office
      profile: developer-extra
      target_group: windows_developer

  - name: windows-server-baseline
    from: registry.acme-corp.com/acme/windows/windows-software-baseline:0.1.0
    config:
      profile: server
      target_group: windows_servers
      allow_reboot: false

from: enthält die vollständige OCI-Registry-Referenz inklusive Versions-Tag; die Registry registry.acme-corp.com ist ein Beispiel (kein Bezug zu einer konkreten Produkt-Registry).

Wichtig:

• Alle drei Einträge nutzen dieselbe Block-Version; ausgepackt liegt der Block unter blocks/registry.acme-corp.com/acme/windows/windows-software-baseline/.
• Unterschiede liegen nur in der Konfiguration (profile, base_profile, etc.).
• Damit hast du bereits eine Form der Block-Vererbung über Konfiguration: Developer „erbt“ Office plus zusätzliche Tools.

Mehr zu generischer Vererbung in Polycrate findest du in der Doku zu Vererbung.

Der Polycrate-Block: name als vollständige Registry-Referenz in block.poly

Jetzt definieren wir den Block selbst unter blocks/registry.acme-corp.com/acme/windows/windows-software-baseline/block.poly (Verzeichnisbaum = Registry-Pfad). In block.poly muss name die vollständige Registry-URL sein – dieselbe Zeichenkette wie in from: im workspace.poly, aber ohne Versions-Tag (also ohne :0.1.0 am Ende). Kurz: from: = name + : + Tag. Das ist nicht derselbe Bezeichner wie die Block-Instanzen im workspace.poly (windows-office-baseline, windows-developer-baseline, …).

# name = from: ohne Tag (vollständiger Registry-Pfad)
name: "registry.acme-corp.com/acme/windows/windows-software-baseline"
version: 0.1.0
kind: generic

config:
  chocolatey_source: "https://community.chocolatey.org/api/v2/"

  # Zentrale Definition der Software-Profile
  software_profiles:
    office:
      - name: 7zip
        version: "22.1.0"
      - name: googlechrome
        version: "118.0.5993.90"
      - name: sumatrapdf
        version: "3.4.6"

    developer-extra:
      - name: vscode
        version: "1.84.0"
      - name: git
        version: "2.44.0"
      - name: postman
        version: "10.21.0"

    server:
      - name: sysinternals
        version: "2023.9.23"
      - name: notepadplusplus
        version: "8.6.2"

actions:
  - name: baseline
    playbook: baseline.yml

Ein paar Punkte dazu:

• polycrate run windows-office-baseline … und ähnliche Befehle nutzen den Instanznamen aus workspace.poly, nicht die vollständige Registry-Referenz in name (block.poly).
• Versionspinning: Alle Pakete haben konkrete Versionsangaben. latest wäre bequemer, aber du verlierst dabei jede Reproduzierbarkeit. Dein Ziel: „Eine Workstation im April 2026 sieht genauso aus wie eine im Juni – solange du nicht bewusst die Block-Version erhöhst.“
• Die Profile office, developer-extra und server sind zentral definiert. Workspace-spezifisch entscheidest du nur, welches Profil genutzt wird.

Wenn dieser Block später stabil läuft, kannst du ihn in eure OCI-Registry pushen – beispielhaft (fiktive Registry, gleiches Pfadschema wie oben):

registry.acme-corp.com/acme/windows/windows-software-baseline:0.1.0

Damit wird deine Software-Baseline zur sharable automation für andere Teams.

Das Ansible-Playbook: Profile kombinieren und ausrollen

Jetzt fehlt noch das Playbook blocks/registry.acme-corp.com/acme/windows/windows-software-baseline/baseline.yml, das Chocolatey nutzt und Profile kombiniert:

- name: Windows Software-Baseline mit Chocolatey
  hosts: "{{ block.config.target_group }}"
  gather_facts: false

  vars:
    choco_source: "{{ block.config.chocolatey_source }}"
    base_profile_name: "{{ block.config.base_profile | default(None) }}"
    profile_name: "{{ block.config.profile }}"

  tasks:
    - name: Sicherstellen, dass Chocolatey installiert ist
      ansible.windows.win_chocolatey:
        name: chocolatey
        state: present

    - name: Basispakete laden (z. B. office)
      ansible.builtin.set_fact:
        base_packages: "{{ block.config.software_profiles[base_profile_name] | default([]) }}"

    - name: Profilpakete laden (z. B. developer-extra oder server)
      ansible.builtin.set_fact:
        profile_packages: "{{ block.config.software_profiles[profile_name] }}"

    - name: Gesamtliste der Pakete zusammenführen
      ansible.builtin.set_fact:
        final_packages: "{{ base_packages + profile_packages }}"

    - name: Alle Pakete in gewünschter Version installieren/aktualisieren
      ansible.windows.win_chocolatey:
        name: "{{ item.name }}"
        version: "{{ item.version }}"
        state: present
        source: "{{ choco_source }}"
      loop: "{{ final_packages }}"

    - name: Optional: Neustart nach Installation zulassen
      ansible.windows.win_reboot:
        msg: "Reboot nach Baseline-Installation durch Polycrate/Ansible"
        pre_reboot_delay: 60
      when: block.config.allow_reboot | default(true)

Wichtige Details:

• hosts: "{{ block.config.target_group }}" sorgt dafür, dass du je Block-Instanz steuern kannst, welche Host-Gruppe angesprochen wird – ideal für Rolling-Rollouts.
• base_profile und profile implementieren unsere Konfigurations-Vererbung:
  • Office-Workstations nutzen profile: office ohne base_profile.
  • Developer-Workstations nutzen base_profile: office und profile: developer-extra – das entspricht „Developer erbt von Office + extra Tools“.
• Die Module ansible.windows.win_chocolatey und ansible.windows.win_reboot stammen aus den Windows-Collections; Polycrate sorgt im Container für eine passende Ansible-Umgebung.

Mit plain Ansible müsstest du alle Variablenquellen (z. B. group_vars, host_vars, extra_vars) und die CLI-Aufrufe sauber orchestrieren. Mit Polycrate werden diese Parameter Teil des Blocks und sind versioniert.

Rolling-Rollout: Test-Gruppe zuerst, dann Produktion

Der Rolling-Rollout ergibt sich jetzt fast von selbst, weil wir mit Inventar-Gruppen arbeiten:

1. Test-Gruppe definieren

   Im oben gezeigten inventory.yml gibt es windows_office_test und windows_office_prod. In workspace.poly ist target_group der Office-Baseline zunächst auf windows_office_test gesetzt.

2. Baseline auf Test-Gruppe ausführen

   polycrate run windows-office-baseline baseline

   Polycrate:

   • Startet einen Container mit Ansible und den nötigen Collections.
   • Lädt den Workspace (inkl. Inventar) in den Container.
   • Führt baseline.yml mit den in windows-office-baseline hinterlegten Parametern aus.

3. Nach Tests: Zielgruppe auf Produktion umschalten

   Du änderst in workspace.poly:

   - name: windows-office-baseline
     from: registry.acme-corp.com/acme/windows/windows-software-baseline:0.1.0
     config:
       profile: office
       target_group: windows_office_prod

   Workspace speichern, ins Git committen – damit ist dokumentiert, ab welcher Version der Workspace-Definition die Baseline auf Produktion ausgerollt wurde.

4. Produktion ausrollen

   polycrate run windows-office-baseline baseline

Wenn du willst, kannst du diese Schritte später in einem Polycrate-Workflow bündeln. Für viele Teams ist es aber schon ein großer Gewinn, dass Test vs. Produktion klar über Inventory-Gruppen und Git-Historie nachvollziehbar sind.

Häufige Fragen

Brauche ich für dieses Setup zwingend ein zentrales Chocolatey-Repository?

Nein, technisch kannst du auch direkt das öffentliche Chocolatey-Repository verwenden, wie im Beispiel (https://community.chocolatey.org/api/v2/). In vielen Unternehmen spricht aber Folgendes für ein internes Repository:

• Kontrolle darüber, welche Pakete und Versionen erlaubt sind.
• Bessere Reproduzierbarkeit, weil du nicht von Upstream-Änderungen überrascht wirst.
• Weniger Abhängigkeit von externen Diensten (Stichwort Offline-Fähigkeit / eingeschränkte Internet-Anbindung).

Im Polycrate-Block ist die Quelle nur eine Konfigurationsvariable (chocolatey_source), du kannst also problemlos von extern auf intern umschalten – ohne das Playbook umzuschreiben.

Wie hilft mir Polycrate konkret bei Compliance und Audits?

Zwei Punkte sind besonders wichtig:

• Versionierte Blöcke und Workspaces: Du kannst jederzeit sehen, welche Block-Version (z. B. registry.acme-corp.com/acme/windows/windows-software-baseline:0.1.0) mit welcher Workspace-Konfiguration auf welche Systeme ausgerollt wurde. Das unterstützt Nachvollziehbarkeit bei Audits.
• Workspace-Verschlüsselung: Sensible Informationen wie Credential-Objekte, Lizenzschlüssel oder interne URLs werden im Workspace gesichert abgelegt und mit polycrate workspace encrypt verschlüsselt. Das erleichtert es, Anforderungen aus Standards wie ISO 27001 oder internen Richtlinien umzusetzen, ohne auf externe Secrets-Manager angewiesen zu sein.

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

Wie unterscheidet sich das von „nur Ansible“ – lohnt sich Polycrate?

Mit plain Ansible kannst du alles aus diesem Beitrag ebenfalls umsetzen. Der Unterschied liegt im Drumherum:

• Du musst Ansible, Python, Collections, Inventarstruktur und Playbooks selbst standardisieren und im Team durchsetzen.
• Das Teilen von Automatisierungen erfolgt über Git-Repos, Ordnerkonventionen und Dokumentation – aber ohne klares Block-/Versionierungsmodell.
• Neue Kolleg:innen brauchen relativ viel Setup-Zeit, bis alles funktioniert.

Polycrate bringt:

• Einen vordefinierten Container mit Ansible-Toolchain, der überall gleich ist.
• Das Block-Modell als „Guardrail“ gegen Playbook-Wildwuchs.
• Eine Registry-Anbindung, um Automatisierungen als wiederverwendbare Bausteine zu verteilen (z. B. über den PolyHub).

Kurz: Polycrate ist dann interessant, wenn du mehr als ein paar Ad-hoc-Playbooks hast und du Automatisierung als „Produkt“ im Team etablieren willst.

Weitere Fragen? Siehe unsere FAQ

Von der Theorie zur Umsetzung

Mit Chocolatey, Ansible und Polycrate hast du einen praktikablen Weg, Windows-Software-Deployment ohne SCCM-Infrastruktur zu betreiben:

• Du hast gesehen, wie eine Windows-Software-Baseline als Polycrate-Block modelliert wird – inklusive klar versionierter Paketlisten.
• Du nutzt Konfiguration, um unterschiedliche Zielgruppen (Office, Developer, Server) aus demselben Block zu bedienen und damit Vererbung im Alltag umzusetzen.
• Durch Ansible-Module wie win_chocolatey bleibt die Automatisierung idempotent und nachvollziehbar, während Polycrate dir die Container-Toolchain, Workspace-Struktur und Wiederverwendbarkeit abnimmt.
• Rolling-Rollouts über Test- und Produktionsgruppen werden so zur Frage eines target_group-Parameters und eines Git-Commits – nicht zur neuen SCCM-Infrastruktur.

In unseren Projekten sehen wir immer wieder, dass Windows-Teams genau mit solchen Bausteinen anfangen und dann Schritt für Schritt weitere Themen integrieren: Patch-Management, lokale Admin-Gruppen, Browser-Hardening, bis hin zu kombinierten Workspaces für Linux-, Windows- und Edge-Umgebungen.

Wenn du diesen Ansatz in deiner Umgebung konkret durchspielen willst – von der ersten Workspace-Struktur bis zum getesteten Rollout in deine Testgruppe – begleiten wir dich gern in einem gemeinsamen Software-Deployment Workshop.