PSADT: Grundlagen und Aufbau

Das Problem, das PSADT löst

Ein Installer tut selten genau das, was ein verwaltetes Gerät braucht. Er will klicken, startet Prozesse, die im Hintergrund weiterlaufen, und hinterlässt manchmal eine Deinstallation, die nichts aufräumt. PSADT setzt eine Schale um diesen Installer: ein PowerShell-Skript, das die Reihenfolge kontrolliert, Prozesse beendet, Ergebnisse prüft und am Ende einen Rückgabecode liefert, den Intune auswertet.

Aufbau eines Pakets

Ein PSADT-Paket besteht aus dem Einstiegsskript, einem Ordner mit den Quelldateien und Hilfsdateien für die Ausführung. In der klassischen Struktur heißt das Skript Deploy-Application.ps1; je nach PSADT-Version und Werkzeug kann der Name abweichen. Wichtig ist nicht der Name, sondern der Vertrag: fester Einstiegspunkt, klare Phasen, definierte Rückgabewerte.

Wann der direkte Weg reicht

Ein MSI mit dokumentierten Properties braucht kein Toolkit. Ein stiller Aufruf, eine Detection-Regel, ein Test — fertig. PSADT lohnt sich, sobald etwas dazukommt: Prozesse beenden, Vorgängerversion entfernen, Konfiguration nachziehen, dem Nutzer einen Hinweis zeigen oder nach der Installation prüfen, ob wirklich alles da ist.

Wo PSADT Aufwand erzeugt

Die Schale ist zusätzlicher Code, der getestet werden muss. Wer sie für jedes Paket verwendet, baut eine Vereinheitlichung, die bei einfachen Installationen nichts bringt und bei fehlerhafter Pflege mehr kaputt macht als der direkte Aufruf. Der Aufwand lohnt sich dort, wo die Logik wirklich komplex ist.

Entscheidungshilfe

Drei Fragen: Gibt es mehr als einen Installationsschritt? Muss vorher etwas beendet oder entfernt werden? Soll der Nutzer etwas sehen? Ein „ja" reicht für PSADT. Drei „nein" bedeuten: direktes MSI-Paket, weniger Code, weniger Fehlerquellen.

---