Packaging-Wissen
Deploy-Application.ps1 verstehen
Der Aufbau des PSADT-Skripts: Pre-Install, Install, Post-Install, Uninstall und die Stellen, an denen eigene Logik hineingehört.
Die vier Phasen
Ein PSADT-Paket hat einen festen Ablauf: Pre-Install, Install, Post-Install, Uninstall. Jede Phase hat eine Aufgabe, und keine Phase sollte die Aufgabe einer anderen übernehmen.
Pre-Install bereitet vor: Prozesse beenden, Vorgängerversion entfernen, Voraussetzungen prüfen. Install führt den eigentlichen Installer aus. Post-Install zieht Konfiguration nach und prüft das Ergebnis. Uninstall entfernt das Produkt und räumt auf, was das Paket selbst angelegt hat.
Was in welche Phase gehört
Der häufigste Strukturfehler ist ein Install-Block, der alles macht. Dann steht das Beenden von Prozessen zwischen Installer-Aufruf und Konfiguration, und beim Deinstallieren fehlt genau dieser Teil.
Die Zuordnung ist einfach, wenn man sie einmal beantwortet: Alles, was vor dem Installer passieren muss, gehört in Pre-Install. Alles, was der Installer selbst tut, in Install. Alles, was danach kommt, in Post-Install. Alles, was rückgängig macht, in Uninstall.
Variablen und Rückgabewerte
Ein Paket sollte seine Werte an einer Stelle definieren: Produktname, Version, Pfade, Logpfad. Wer dieselbe Zeichenkette an fünf Stellen hardcodiert, ändert beim nächsten Update vier davon.
Der Rückgabewert ist der Vertrag mit Intune. Das Skript muss einen Code liefern, den Intune interpretieren kann — Erfolg, Erfolg mit Neustart, Fehler. Ein Skript, das immer 0 liefert, meldet Erfolg, auch wenn nichts installiert wurde.
Logging
Das Paket-Log ist die einzige Spur, die nach einem fehlgeschlagenen Rollout bleibt. Es sollte enthalten: welcher Befehl ausgeführt wurde, mit welchen Argumenten, welchen Code er zurückgegeben hat und wie lange es gedauert hat.
Ein Log, das nur „Start" und „Ende" schreibt, hilft bei der Fehlersuche nicht. Ein Log, das Passwörter oder Lizenzschlüssel mitschreibt, ist ein Sicherheitsproblem.
Typische Strukturfehler
Vier Fehler, die immer wieder auftauchen: Deinstallation im Install-Block, fehlende Fehlerbehandlung nach dem Installer-Aufruf, hartcodierte Pfade und ein Rückgabecode, der nicht weitergereicht wird. Alle vier sind im Test unsichtbar, wenn der Test nur den Erfolgsfall prüft.
Wie PilotDeploy das vorgibt
PilotDeploy erzeugt die klassische Struktur mit Launcher, Skript, Files/Source und PackageInfo. Die Phasen sind angelegt, die eigenen Entscheidungen bleiben sichtbar: silent parameters, Detection, Uninstall und Rückgabecodes stehen als Prüfpunkte im Review.
---