Packaging-Wissen für Windows und Intune

Warum Pakete im Test scheitern, nicht im Builder

Ein Paket entsteht in Minuten. Ob es funktioniert, zeigt sich beim zweiten Gerät. Die meisten Fehler liegen nicht im Klicken, sondern in den Entscheidungen davor: welche Quelle, welche stillen Parameter, woran die Installation erkannt wird und was beim Deinstallieren passieren soll. Wer diese vier Punkte beantwortet, hat ein Paket. Wer sie offen lässt, hat eine Datei, die auf dem Testgerät zufällig läuft.

Der Weg von der Herstellerdatei zum geprüften Paket

Am Anfang steht ein Installer vom Hersteller: MSI, EXE oder ein älteres DSM-Paket. Daraus wird ein Win32-Paket für Intune, mit Installationsbefehl, Deinstallationsbefehl, Erkennungsregel und einem Satz Rückgabecodes, den Intune versteht. Danach folgt der Teil, den niemand abkürzen kann: installieren, deinstallieren, neu installieren — auf einem Gerät, das nicht schon voller Testreste ist.

Fünf Themenblöcke

PSADT-Grundlagen erklären, was das Toolkit leistet und wann der direkte Weg reicht. Softwarepaketierung behandelt stille Parameter, Detection und die Wahl der Quelle. Migration beschreibt den Weg von DSM und SCCM. Betrieb dreht sich um Versionen, Logs und Bandbreite. Team behandelt Standards, Workspaces, API und Audit.

Was PilotDeploy prüft — und was beim Menschen bleibt

PilotDeploy liest Quellen lokal im Browser, ohne Installer hochzuladen. Es erzeugt ein PSADT-Paket mit festem Aufbau: Launcher, PowerShell-Skript, Quellen unter Files/Source, Berichte unter PackageInfo. Sichtbar bleiben die Punkte, die ein Werkzeug nicht für dich entscheiden kann: stille Parameter, Detection, Deinstallation, Rückgabecodes und der manuelle Test unter Windows.

Weiter zum Produkt

Wenn du den Ablauf kennst und nur noch ein Paket bauen willst: Der Builder startet ohne Kreditkarte. Wenn du zuerst verstehen willst, ob sich der Aufwand lohnt, beginne mit „Was ist PSADT".

---