XPLN/Lernbereiche

E09 · Windows PowerShell / Kea

Wiederholbare Automatisierung

Kapitel in dieser Lernstufe

Das lernst du

  • Ein parametriertes Skript sicher wiederholt ausführen.
  • Validierung, Idempotenz und Rücknahme von Änderungen unterscheiden.

Voraussetzungen: F10 · Windows Server praktisch einrichtenF11 · Linux und Kea praktisch einrichtenF13 · Systematische Fehlersuche

Ein Skript, das beim zweiten Start doppelte Objekte erzeugt oder vorhandene Fehler überdeckt, ist keine verlässliche Automatisierung. Die Ausführung muss mit dem vorhandenen Zustand umgehen.

Idempotenz
Eine Konfigurationsoperation ist idempotent, wenn ein weiterer Lauf bei bereits erreichtem Sollzustand keine zusätzlichen oder widersprüchlichen Änderungen erzeugt.

Ändern nur aus einem nachgewiesenen Unterschied

Der Unterschied ist der ÄnderungsauftragScope 192.168.10.0/24ISTSOLLPool.100–199.100–199DNS.20.11.20.101 Abweichung · Pool bleibt erhaltenKorrigieren → erneut auslesenZweiter Lauf: 0 Abweichungen, 0 Änderungen
Grafik vergrößern
Der Unterschied ist der ÄnderungsauftragScope 192.168.10.0/24ISTSOLLPool.100–199.100–199DNS.20.11.20.101 Abweichung · Pool bleibt erhaltenKorrigieren → erneut auslesenZweiter Lauf: 0 Abweichungen, 0 Änderungen
Soll-Ist-Vergleich vor dem Schreiben: Der Pool stimmt, die DNS-Option weicht ab. Nur die kontrollierte Abweichung wird korrigiert und anschließend erneut gelesen. Ein zweiter Lauf muss ohne Änderung enden; Fehler einfach zu ignorieren ist keine Idempotenz.

Idempotenz ist eine Zustandsaussage

Idempotent bedeutet hier: Wiederholte Anwendung derselben gewünschten Konfiguration führt zum gleichen fachlichen Ergebnis. Ein Fehler einfach zu ignorieren erfüllt das nicht. Prüfe, ob ein Objekt fehlt, bereits passt oder abweicht. Für Abweichungen gibt es einen bewussten Korrektur- oder Abbruchpfad.

Parametrisierung trennt Eingabedaten vom Ablauf. Prüfe Adressformat, Netzgrenzen, Kapazität und Überschneidungen vor Änderungen. Verwende Fehlerbehandlung, die einen fehlgeschlagenen Schritt sichtbar macht. Ein Erfolgstext am Ende darf keinen vorherigen Fehler verbergen.

Deklarativ und imperativ vergleichen

Kea-Dateien beschreiben einen gewünschten Zustand; Syntax- und Semantikprüfung kommen vor dem Anwenden. Ein Dateidiff macht Veränderungen sichtbar, prüft aber keine Clientkommunikation. PowerShell-Cmdlets verändern einzelne Objekte und brauchen deshalb explizite Existenz- und Driftprüfungen.

Exportiere Ausgangszustand und Leases, dokumentiere die geplanten Unterschiede und teste in einem kleinen Laborscope. Nach Anwendung Zustand erneut auslesen und einen Clienttest durchführen. Rücknahme braucht die vorherigen Werte, nicht nur ein Stoppen des Skripts.

Vorbedingungen, Änderung und Nachbedingungen trennen

Eine wiederholbare Automatisierung beginnt mit dem Lesen des tatsächlichen Zustands. Existiert der Scope bereits? Passt seine Netzmaske? Sind Poolgrenzen, Ausschlüsse und Optionen korrekt? Erst aus diesem Vergleich entsteht eine gezielte Änderung. „Anlegen versuchen und Fehler ignorieren“ ist keine verlässliche Idempotenz, weil ein vorhandener, aber falscher Scope dabei unbemerkt bleibt.

Definiere anschließend Nachbedingungen: Der gewünschte Scope existiert genau einmal, die effektiven Optionen stimmen und eine echte Testvergabe liefert die erwartete Konfiguration. Eine zweite Ausführung sollte keine unnötigen Änderungen erzeugen. Eine absichtlich abweichende Einstellung sollte dagegen erkannt und gemäß Vorgabe korrigiert oder ausdrücklich gemeldet werden. Diese Gegenprobe unterscheidet robuste Zustandsverwaltung von einem einmal erfolgreichen Skript.

Teilfehler und Rücknahme vorher entwerfen

Ein Ablauf kann nach dem Erstellen des Bereichs, aber vor dem Setzen der DNS-Option scheitern. Der nächste Lauf muss diesen Zwischenzustand sinnvoll behandeln. Ein pauschales Löschen und Neuerstellen könnte bestehende Leases oder andere bewusst gepflegte Daten gefährden. Definiere daher, welche Ressourcen der Ablauf besitzt und welche fremden Einstellungen erhalten bleiben müssen.

Vor produktiven Änderungen werden Plan, Sicherung und Rücknahmeweg vorbereitet. Protokolliere Soll-Ist-Differenzen und das tatsächlich angewendete Ergebnis ohne Zugangsdaten. Bei Konfigurationsdateien prüfst du zusätzlich, ob der Dienst die neue Version geladen hat; bei Verwaltungs-APIs, ob der gelesene Folgezustand der Änderung entspricht. Erfolg des einzelnen Aufrufs und Erfolg des gesamten Betriebsziels sind zwei verschiedene Nachweise.

DURCHGEARBEITETES BEISPIEL

Ein Scope ohne Duplikate

  1. Parameter für Server, ScopeId, Start, Ende und Maske definieren; Eingaben vor dem ersten Cmdlet prüfen.
  2. Bestehende Scopes lesen. Fehlt der Scope, anlegen. Existiert er, seine Grenzen mit dem Soll vergleichen; bei Abweichung mit verständlicher Meldung abbrechen statt stillschweigend überschreiben.
  3. Optionen bewusst setzen, auslesen und protokollieren. Skript zweimal ausführen; es bleibt genau ein passender Scope vorhanden.
  4. Ein absichtlich abweichender dritter Lauf muss die Drift melden. Danach kontrollierte Korrektur oder Rollback durchführen.

Ergebnis: P34 und P35 prüfen nicht nur syntaktischen Code, sondern wiederholte Ausführung, Objektzahl, Sollwerte und einen dokumentierten Fehlerfall.

Typische Fehler

  • -ErrorAction SilentlyContinue ist keine Idempotenz.
  • Ein erfolgreiches JSON-Parsing ist noch keine Kea-Semantikprüfung.
  • Ein zweiter erfolgreicher Start ohne Zustandsvergleich beweist wenig.

Praktisch anwenden

P34 öffnen P35 öffnen P21 öffnen P22 öffnen

Offizielle Quellen

Versionsbezüge geprüft am 14. Oktober 2026. Produktkonfigurationen werden im jeweiligen isolierten Labor validiert.