Packaging-Wissen
Was ist PSADT – und wann lohnt es sich?
Das Toolkit erklärt: was PSADT tut, welche Pakete davon profitieren und für welche einfachen Installer der direkte Weg besser ist.
Das Problem, das PSADT löst
Ein Windows-Installer ist für einen Menschen gemacht, der davor sitzt. In einem Unternehmensnetz sitzt niemand davor. Der Installer muss still laufen, darf nicht auf Eingaben warten, muss einen Rückgabecode liefern und sollte beim Deinstallieren nicht mehr hinterlassen als vorher.
Genau dafür gibt es das PowerShell App Deployment Toolkit: eine Schale um den Installer, die Reihenfolge, Fehlerbehandlung und Rückgabewerte übernimmt. Es installiert nicht selbst. Es führt aus, prüft und meldet.
Aufbau eines Pakets
Ein PSADT-Paket besteht aus vier Teilen: dem Einstiegsskript, den Quelldateien, einem Logbereich und den Hilfsdateien des Toolkits. Das Einstiegsskript ist der Vertrag. Es enthält die Phasen Pre-Install, Install, Post-Install und Uninstall. Alles, was ein Paket tut, steht dort — nicht in einer versteckten Batchdatei.
Je nach PSADT-Version heißt das Skript anders. In der klassischen Struktur ist es Deploy-Application.ps1; PilotDeploy erzeugt genau diese Struktur mit Launcher, Skript, Files/Source und PackageInfo.
Wann der direkte Weg reicht
Ein MSI, das stille Properties akzeptiert, braucht kein Toolkit. Ein Aufruf, eine Detection-Regel, ein Test. Wer hier PSADT einsetzt, baut eine zusätzliche Ebene, die gewartet werden muss, ohne dass sie etwas löst.
Dasselbe gilt für einfache EXE-Installer mit dokumentierten Argumenten: Wenn der Aufruf zuverlässig ist und die Deinstallation existiert, ist der direkte Weg kürzer und fehlerärmer.
Wann PSADT teuer wird
Die Schale ist Code. Sie kann falsch sein. Ein Paket, das Prozesse beendet, die es nicht sollte, oder eine Deinstallation, die zu viel löscht, ist gefährlicher als ein einfacher MSI-Aufruf. Der Aufwand lohnt sich nur, wenn die Logik wirklich gebraucht wird.
Teuer wird es auch, wenn jedes Paket anders aussieht: verschiedene Skriptstrukturen, verschiedene Rückgabecodes, verschiedene Logs. Dann kostet nicht das Toolkit Zeit, sondern die fehlende Konvention.
Entscheidungshilfe
Vier Fragen, ehrlich beantwortet:
1. Muss vor der Installation etwas beendet oder entfernt werden? 2. Gibt es mehr als einen Installationsschritt? 3. Soll der Nutzer etwas sehen oder bestätigen? 4. Muss nach der Installation etwas geprüft oder konfiguriert werden?
Ein „ja" genügt. Sind alle vier „nein", ist das direkte Paket die bessere Wahl.
---