WinGet liefert den Installer, PSAppDeployToolkit das Verhalten

Wer Software für Windows paketiert, kennt die zwei Stunden, die ein „kleines Update“ kostet: Installer suchen, Version prüfen, Silent-Switch raten, im Testsystem ausprobieren, Deinstallation vergessen, Deinstallation nachreichen. Der WinGet-Katalog von Microsoft hat einen Teil dieser Arbeit für alle gleichzeitig erledigt. Er weiß nur nicht, wie Software in Ihrem Unternehmen verteilt werden soll. Genau an dieser Stelle setzt das PSAppDeployToolkit an, und genau deshalb kombinieren wir beides.

Was der Katalog kann

Das Repository microsoft/winget-pkgs ist eine Sammlung von Manifesten. Für jede Anwendung und jede Version stehen darin die Installer mit URL, Typ, Architektur, Scope und SHA-256-Hash, oft auch ProductCode, UpgradeCode und die Silent-Switches. Stand August 2026 sind das rund 14.600 Anwendungen, 165.000 Versionen und 324.000 Installer.

AppCloud365 spiegelt diesen Katalog in eine lokale Datenbank. Ein separater Sync-Prozess klont das Repository und verarbeitet danach nur noch die Änderungen seit dem letzten Lauf. Entfernte Pakete werden als inaktiv markiert, nicht gelöscht, damit die Historie erhalten bleibt und keine Geisterpakete entstehen.

Vergrößern

Was dem Katalog fehlt

Ein Manifest beschreibt einen Installer. Es beschreibt nicht, was passieren soll, wenn die Anwendung während der Installation läuft, wie Fehler protokolliert werden, welche Exit-Codes als Erfolg gelten oder wie sich die Installation gegenüber angemeldeten Benutzern verhält. Für einen Entwickler, der ein Werkzeug auf seinem Rechner installiert, ist das egal. Für eine Verteilung auf zweihundert Geräte ist es der Unterschied zwischen einer ruhigen und einer lauten Nacht.

Das PSAppDeployToolkit, kurz PSADT, ist seit Jahren der Standard, um genau dieses Verhalten zu definieren: Prozesse schließen, Benutzer informieren, Protokolle schreiben, Rückgabecodes behandeln, Deinstallation und Reparatur im selben Skript. Die Version 4 bringt ein Template mit klar markierten Stellen für Installations- und Deinstallationsaufrufe.

Die Kombination

AppCloud365 nimmt den verifizierten Installer aus dem Katalog und legt ihn in das offizielle PSADT-v4-Template. Die Sitzungsvariablen für Hersteller, Name, Version und Architektur werden gesetzt, die Install- und Uninstall-Aufrufe an den vorgesehenen Markern eingetragen. Das Ergebnis ist ein PSADT-Paket, wie Sie es von Hand bauen würden, nur ohne die zwei Stunden.

Die Kommandos stammen aus dem Manifest. Ein MSI bekommt msiexec.exe /i "datei.msi" /qn /norestart und, wenn ein gültiger ProductCode vorliegt, den passenden Deinstallationsaufruf mit /x. Ein Inno-Setup- oder Nullsoft-Installer bekommt den dokumentierten Silent-Switch des Frameworks, falls das Manifest keinen eigenen nennt. Ein EXE-Installer ohne bekannten Switch wird ehrlich als unsicher markiert, statt mit einem geratenen Parameter versehen zu werden.

Vergrößern

Und wenn Sie kein PSADT wollen?

Es gibt Umgebungen, die das Toolkit bewusst nicht einsetzen. Dafür baut AppCloud365 einen schlanken nativen Wrapper aus Install.ps1 und Uninstall.ps1, der das bestätigte Kommando ausführt und die Exit-Codes 0, 3010 und 1641 als Erfolg durchreicht. Beide Varianten lassen sich mit dem Microsoft Win32 Content Prep Tool als .intunewin verpacken, fertig für Intune. Wer lieber Configuration Manager oder eine klassische Verteilung nutzt, nimmt das ZIP.

Vergrößern

Was das im Alltag bedeutet

Aus „7-Zip aktualisieren“ wird: Anwendung suchen, Version wählen, Paketoption anklicken, Zusammenfassung lesen, bauen, herunterladen. Das Wissen, das früher im Kopf eines einzelnen Paketierers steckte, liegt jetzt im Manifest und im Template. Und wenn das Manifest etwas nicht weiß, sagt der Assistent das, statt es zu verschweigen.

Der Katalog liefert den Installer. Das Toolkit liefert das Verhalten. AppCloud365 bringt beides zusammen, ohne etwas dazuzuerfinden.