Eine Administrationsaufgabe sicher automatisieren

Neue Projektordner sollen nachts vorbereitet werden

Die Riedtal Services GmbH betreibt einen Windows-Dateiserver. Für neue Kundenprojekte legt die Administration immer dieselbe Ordnerstruktur an: Eingang, Berichte und Archiv. Bisher überträgt eine Person die Projektdaten aus einer Tabelle und erstellt die Ordner einzeln. Das kostet Zeit und führt zu uneinheitlichen Namen.

Ein Skript soll die Aufgabe künftig aus einer CSV-Datei übernehmen. Es läuft zunächst in einer Testablage. Erst nach einer kontrollierten Freigabe darf ein geplantes Dienstkonto es im vorgesehenen Projektverzeichnis ausführen.

Nach dieser Lektion kannst du:

• eine Administrationsaufgabe in klar begrenzte Schritte zerlegen,
• Eingaben prüfen und Änderungen vorab mit -WhatIf anzeigen,
• einen wiederholbaren, idempotenten Ablauf entwerfen,
• Fehler, Rechte, Protokolle und Geheimnisse einordnen,
• Testfälle und einen begrenzten Rollback dokumentieren.

Du solltest Bedingungen, Schleifen und Funktionen grundsätzlich lesen können. Wenn diese Bausteine noch neu für dich sind, beginne mit der Lektion Programmiergrundlagen an einem Ablauf verstehen. Hier geht es nicht um allgemeine Sprachgrundlagen, sondern um den sicheren Betrieb einer konkreten Administrationsautomatisierung.

Automatisieren heißt, eine Änderung kontrolliert wiederholbar zu machen

Ein Skript ist nicht allein deshalb sicher, weil es dieselbe Arbeit schneller erledigt. Für die Projektordner braucht es einen kontrollierten Weg von der Eingabe bis zum nachweisbaren Ergebnis:

1. Die CSV-Datei wird eingelesen und vollständig validiert.
2. Aus gültigen Datensätzen entsteht der gewünschte Zielzustand.
3. Der Dry-Run zeigt geplante Änderungen, ohne sie auszuführen.
4. Nach der Freigabe setzt das Skript nur nötige Änderungen um.
5. Das Protokoll hält neue, unveränderte und fehlgeschlagene Schritte fest.
6. Tests vergleichen Soll und Ist; das Änderungsjournal begrenzt einen möglichen Rollback.

Die Reihenfolge schützt vor zwei typischen Fehlern. Eine ungültige Projektkennung erreicht das Dateisystem nicht. Außerdem sieht die zuständige Person die geplanten Ziele, bevor das Skript etwas verändert.

Gültige Eingaben begrenzen den Wirkungsbereich

Die CSV-Datei enthält nur fachliche Steuerdaten:

ProjectCode,DisplayName,OwnerGroup
KUND-2041,Kundenportal Nord,GG_KUND_2041_RW
NETZ-2042,Standortanbindung West,GG_NETZ_2042_RW

Für die Projektkennung gilt im Beispiel das Muster VIER BUCHSTABEN, Bindestrich und VIER ZIFFERN. Der Gruppenname darf aus Großbuchstaben, Ziffern und Unterstrichen bestehen. Der Anzeigename darf weder leer noch länger als 80 Zeichen sein.

Diese Regeln sind keine allgemeingültigen Standards. Sie gehören zum neu erstellten Szenario. Im Betrieb würden Auftraggeber und Administration sie passend zum Namenskonzept festlegen.

Eine Prüfung mit regulären Ausdrücken hat hier auch eine Sicherheitsfunktion. Die Zeichenfolgen ../ oder ..\ passen nicht zum erlaubten Muster. Ein Datensatz kann dadurch das festgelegte Stammverzeichnis nicht über eine manipulierte Projektkennung verlassen. Zusätzlich wird das Stammverzeichnis fest konfiguriert und nicht pro CSV-Zeile übernommen.

Der Zielzustand macht das Skript idempotent

Idempotent bedeutet hier: Mehrere Ausführungen mit derselben Eingabe führen zum selben gewünschten Zustand. Beim ersten Lauf legt das Skript fehlende Ordner an. Beim zweiten Lauf erkennt es die vorhandenen Ordner und verändert sie nicht erneut.

Das unterscheidet einen Zielzustand von einer blinden Befehlsfolge:

# Blinde Änderung: versucht bei jedem Lauf erneut, den Ordner anzulegen.
New-Item -ItemType Directory -Path $targetPath

# Zielzustand: ändert nur etwas, wenn der Ordner fehlt.
if (-not (Test-Path -LiteralPath $targetPath -PathType Container)) {
    New-Item -ItemType Directory -Path $targetPath
}

Test-Path allein reicht trotzdem nicht für jede denkbare Gleichzeitigkeit. Zwei parallele Läufe könnten beide denselben fehlenden Ordner sehen. Der geplante Job wird deshalb so konfiguriert, dass pro Zielablage höchstens eine Instanz läuft. Für verteilte Systeme wären weitergehende Sperr- oder Transaktionskonzepte nötig.

PowerShell zeigt Änderungen vor der Ausführung

Eine erweiterte PowerShell-Funktion kann mit SupportsShouldProcess die gemeinsamen Parameter -WhatIf und -Confirm anbieten. Vor jeder Änderung fragt die Funktion über $PSCmdlet.ShouldProcess(...), ob sie ausgeführt werden soll. Bei -WhatIf beschreibt PowerShell die Aktion und ShouldProcess gibt false zurück. Der Änderungsblock läuft dann nicht.

Der folgende Ausschnitt zeigt den Kern des Ablaufs. Das Beispiel ist bewusst auf eine Testablage begrenzt. Die eigentliche Rechtevergabe bleibt außerhalb dieses Ausschnitts, weil ACL-Befehle vom eingesetzten Dateisystem, vom vorhandenen Gruppenmodell und vom Freigabekonzept abhängen.

function Initialize-ProjectFolders {
    [CmdletBinding(SupportsShouldProcess)]
    param(
        [Parameter(Mandatory)]
        [ValidateScript({ Test-Path -LiteralPath $_ -PathType Leaf })]
        [string] $CsvPath,

        [Parameter(Mandatory)]
        [ValidateScript({ Test-Path -LiteralPath $_ -PathType Container })]
        [string] $RootPath
    )

    Set-StrictMode -Version Latest
    $ErrorActionPreference = 'Stop'
    $rows = @(Import-Csv -LiteralPath $CsvPath)

    if ($rows.Count -eq 0) { throw 'Die CSV-Datei enthält keine Projekte.' }
    $requiredColumns = 'ProjectCode', 'DisplayName', 'OwnerGroup'
    $actualColumns = @($rows[0].PSObject.Properties.Name)
    foreach ($column in $requiredColumns) {
        if ($column -notin $actualColumns) { throw "Spalte fehlt: $column" }
    }

    $duplicates = $rows | Group-Object ProjectCode | Where-Object Count -gt 1
    if ($duplicates) { throw 'Die CSV-Datei enthält doppelte Projektkennungen.' }

    foreach ($row in $rows) {
        if ($row.ProjectCode -cnotmatch '^[A-Z]{4}-[0-9]{4}$') {
            throw "Ungültige Projektkennung: $($row.ProjectCode)"
        }
        if ($row.OwnerGroup -cnotmatch '^GG_[A-Z0-9_]{3,50}$') {
            throw "Ungültiger Gruppenname für $($row.ProjectCode)"
        }
        if ([string]::IsNullOrWhiteSpace($row.DisplayName) -or
            $row.DisplayName.Length -gt 80) {
            throw "Ungültiger Anzeigename für $($row.ProjectCode)"
        }

        $projectPath = Join-Path $RootPath $row.ProjectCode
        foreach ($name in '.', 'Eingang', 'Berichte', 'Archiv') {
            $targetPath = if ($name -eq '.') { $projectPath } else {
                Join-Path $projectPath $name
            }

            if (Test-Path -LiteralPath $targetPath -PathType Container) {
                Write-Information "UNCHANGED folder=$targetPath"
                continue
            }

            if ($PSCmdlet.ShouldProcess($targetPath, 'Ordner anlegen')) {
                try {
                    New-Item -ItemType Directory -Path $targetPath | Out-Null
                    Write-Information "CREATED folder=$targetPath"
                }
                catch {
                    Write-Error "FAILED folder=$targetPath error=$($_.Exception.Message)"
                    throw
                }
            }
        }
    }
}

Ein Dry-Run verwendet denselben Entscheidungsweg wie die spätere Ausführung:

Initialize-ProjectFolders `
    -CsvPath '.\projekte.csv' `
    -RootPath 'D:\Automation-Test\Projekte' `
    -WhatIf

Der Dry-Run ist eine Vorschau, kein Beweis für eine erfolgreiche Änderung. Zwischen Vorschau und Ausführung können sich Zustand oder Berechtigungen ändern. Deshalb folgen nach der echten Ausführung weiterhin Soll-Ist-Tests.

Protokollierung soll Entscheidungen erklären, aber keine Geheimnisse verraten

Die Meldungen CREATED, UNCHANGED und FAILED beantworten drei Fragen: Was wurde neu angelegt, was war bereits richtig und wo ist der Lauf abgebrochen? Ein geplanter Job kann diese Informations- und Fehlerströme in eine zugriffsgeschützte Protokolldatei oder in die zentrale Überwachung umleiten.

Ein brauchbarer Eintrag enthält mindestens Zeitpunkt, Laufkennung, Skriptversion, Zielobjekt, Aktion und Ergebnis. Bei Fehlern kommt eine verständliche Fehlerklasse hinzu. Die rohe CSV-Datei, Kennwörter, Zugriffstoken oder der Inhalt vertraulicher Dateien gehören nicht in das Protokoll.

Das Beispiel benötigt kein Kennwort. Der Job läuft unter einer dafür eingerichteten technischen Identität. Wenn eine spätere Erweiterung ein Geheimnis braucht, bezieht das Skript es zur Laufzeit aus einem geeigneten Geheimnisspeicher. Das Geheimnis steht weder im Quelltext noch in den Startparametern oder der CSV-Datei. Auch ein verschleierter Klartextwert im Repository wäre kein sicherer Geheimnisspeicher.

Rechte werden auf den Auftrag begrenzt

Für den geplanten Lauf gilt das Prinzip der geringsten Berechtigungen:

• Das Dienstkonto darf die freigegebene CSV-Datei lesen.
• Es darf ausschließlich unterhalb der vorgesehenen Projektablage Ordner anlegen.
• Es braucht kein Domänenadministrationsrecht und keine interaktive Anmeldung.
• Protokolle dürfen nur die zuständigen Betriebsrollen lesen und ändern.
• Die fachlichen Projektgruppen erhalten ihre Zugriffsrechte über einen getrennt geprüften ACL-Schritt.

Die Trennung ist bewusst. Ein Skript, das Ordner, Gruppen, Berechtigungen und Datenmigration zugleich verändert, vergrößert seinen Wirkungsbereich und erschwert einen sicheren Rollback.

Fehler müssen sichtbar abbrechen

PowerShell unterscheidet unter anderem Fehler, die einen Befehl nicht automatisch beenden, und beendende Fehler. Ein catch-Block verarbeitet Fehler nur zuverlässig, wenn sie den umschlossenen Ablauf beenden. Im Beispiel setzt $ErrorActionPreference = 'Stop' nicht beendende Fehler für den Skriptbereich auf beendendes Verhalten. Alternativ kann ein einzelner kritischer Befehl -ErrorAction Stop verwenden.

Der Fehler wird nicht nur ausgegeben und anschließend verschluckt. Nach der Protokollmeldung wirft throw ihn erneut. Der geplante Job erhält dadurch einen fehlgeschlagenen Status und kann die Überwachung informieren.

Tests prüfen Zustand, Wiederholung und Schutzgrenzen

Ein einzelner erfolgreicher Lauf reicht nicht. Der Testplan verbindet Eingabe, Ausgangszustand und erwartetes Ergebnis:

Normal-, Rand- und Fehlerfälle beantworten verschiedene Fragen. Der Wiederholungstest prüft das idempotente Verhalten. Der Negativtest mit fehlendem Schreibrecht zeigt, ob ein Betriebsfehler sichtbar wird. Die manipulierte Kennung prüft die Schutzgrenze vor dem Dateisystemzugriff.

Ein Rollback nimmt nur eindeutig eigene Änderungen zurück

Vor dem Produktivlauf bekommt jede Ausführung eine Laufkennung. Ein Änderungsjournal hält für jeden tatsächlich neu angelegten Ordner dessen vollständigen Pfad und die Laufkennung fest. Bereits vorhandene Ordner stehen nicht als eigene Änderung im Journal.

Der dokumentierte Rollback läuft in umgekehrter Reihenfolge:

1. Die zuständige Person stoppt weitere Läufe und prüft die Laufkennung.
2. Sie vergleicht die Journalpfade mit dem festgelegten Stammverzeichnis.
3. Sie entfernt nur leere Ordner, die dieser Lauf neu angelegt hat.
4. Enthält ein Ordner inzwischen Dateien, bleibt er bestehen und wird manuell bewertet.
5. Der Rollback und ausgelassene Objekte werden protokolliert.
6. Ein Soll-Ist-Test bestätigt den verbleibenden Zustand.

Ein pauschales Remove-Item -Recurse gehört nicht in diesen Rollback. Nach der Ausführung könnten andere Prozesse Dateien abgelegt haben. Diese Daten darf das Skript nicht allein deshalb löschen, weil es ursprünglich den Ordner angelegt hat.

Was du für den Betrieb mitnimmst

Eine sichere Administrationsautomatisierung beginnt bei einem begrenzten Auftrag. Validierte Eingaben und ein festes Stammverzeichnis halten die Wirkung im vorgesehenen Bereich. ShouldProcess ermöglicht eine Vorschau mit -WhatIf, ersetzt aber nicht den Test nach der Ausführung.

Der Zielzustand macht Wiederholungen berechenbar. Protokollierung unterscheidet neue, unveränderte und fehlgeschlagene Schritte. Ein begrenztes Dienstkonto reduziert den möglichen Schaden. Geheimnisse werden nur bei Bedarf aus einem geeigneten Speicher bezogen und nie in Quelltext oder Protokoll geschrieben.

Damit steht der Ablauf vom Auftrag bis zur Rücknahme. Die Automatisierung führt nicht nur Befehle aus. Sie macht ihre Voraussetzungen, Entscheidungen und Grenzen prüfbar.

Quellenbasis und Abgrenzung

Der Rahmenlehrplan ordnet das Bereitstellen von Serverdiensten und das Automatisieren von Administrationsaufgaben dem Lernfeld 10b zu. Die Ausbildungsordnung trägt die Bezüge zu Qualitätssicherung, IT-Sicherheit, Automatisierung von Teilaufgaben und Administration von IT-Systemen. Der Prüfungskatalog nennt wiederkehrende Systemabläufe mit PowerShell, Bash oder Python sowie Qualitätssicherung und Tests als mögliche Themenbreite.

Die Beispielprüfung wurde nur auf der Ebene der Aufgabenform ausgewertet: einen Ablauf lesen, Fehler erkennen und eine Korrektur begründen. Szenario, CSV-Daten, Code und Lösungen dieser Lektion sind neu erstellt. Sie treffen keine Aussage darüber, welches Thema in einem konkreten Prüfungstermin vorkommt.

Die Lektion behandelt den sicheren Ablauf einer überschaubaren Dateisystemautomatisierung. Allgemeine Kontrollstrukturen, objektorientierter Entwurf, produktspezifische Zugriffslisten, zentrale Überwachungsplattformen und verteilte Transaktionen brauchen eigene Lerneinheiten.

Belegmatrix