Windows-Softwarepaketierung ist selten die Aufgabe, mit der ein IT-Team Aufmerksamkeit gewinnt. Sie ist aber eine der Aufgaben, bei denen kleine Unklarheiten später viel Zeit kosten. Ein falscher Silent-Parameter, eine fehlende Detection Rule oder ein uneinheitlich aufgebautes Projekt fällt oft erst auf, wenn das Deployment bereits in einer Testgruppe scheitert. Danach beginnt die Suche: Welche Installer-Version wurde verwendet? Wo liegt das Deinstallationskommando? Wurde das Paket für Intune anders vorbereitet als für SCCM? Genau an diesem Punkt setzt PSDeployStudio an.
Ich entwickle PSDeployStudio als Windows-Desktopsoftware für Administratoren, Managed-Service-Provider und professionelle Softwarepaketierer. Die Anwendung soll wiederkehrende Arbeitsschritte rund um das PowerShell App Deployment Toolkit in einen konsistenten Ablauf bringen. Der erste Release ist für den 15. September 2026 geplant und wird zunächst ausschließlich in Deutschland, Österreich und der Schweiz angeboten.
PSDeployStudio befindet sich aktuell noch in Entwicklung. Wer über den Verkaufsstart informiert werden möchte, kann bereits jetzt meinen Newsletter abonnieren und im Formular mindestens den Blog Newsletter auswählen. Abonnenten erhalten beim Release außerdem 50 % Einführungsrabatt. Die Details und den Aktionszeitraum versende ich zusammen mit der Release-Nachricht.
Das eigentliche Problem ist nicht PowerShell
Für eine saubere Paketierung sind viele einzelne Entscheidungen erforderlich. Der Installer muss geprüft, die passende Installationslogik festgelegt und ein zuverlässiger Deinstallationsweg dokumentiert werden. Metadaten wie Hersteller, Produktname, Version und Sprache müssen stimmen. Bei einer zentralen Softwareverteilung kommen Detection-Hinweise, Exit Codes, Abhängigkeiten und Anforderungen des Zielsystems hinzu.
PowerShell ist dabei nur ein Werkzeug. Die größere Herausforderung ist der wiederholbare Prozess. In kleinen Teams wächst häufig eine Ordnerstruktur über Jahre. Skriptvorlagen werden kopiert, persönliche Checklisten gepflegt und besondere Installationsparameter in Tickets oder Textdateien dokumentiert. Das funktioniert, solange dieselbe Person jedes Paket betreut und alle Besonderheiten kennt. Bei Vertretung, Übergabe oder steigender Paketanzahl zeigen sich die Grenzen.
Ein professioneller Paketierungsworkflow sollte deshalb mindestens vier Fragen schnell beantworten:
- Welche Quelle und welche Version wurden verwendet?
- Welche Installations- und Deinstallationslogik ist vorgesehen?
- Ist das Projekt vollständig genug für das gewünschte Exportziel?
- Welche Schritte müssen vor der produktiven Freigabe noch manuell geprüft werden?
PSDeployStudio macht diese Informationen nicht überflüssig. Es führt sie an einer Stelle zusammen und macht fehlende Angaben früher sichtbar.
Warum PSAppDeployToolkit eine gute Grundlage ist
Das PowerShell App Deployment Toolkit – kurz PSAppDeployToolkit – hat sich in vielen Windows-Umgebungen etabliert, weil es typische Deployment-Aufgaben strukturiert abbildet. Dazu gehören Installationsdialoge, Prozessprüfungen, Datei- und Registry-Aktionen sowie ein kontrollierter Umgang mit Rückgabecodes. Gleichzeitig bleibt ein Paket in PowerShell nachvollziehbar und ist nicht vollständig an das proprietäre Format eines einzelnen Verteilungssystems gebunden.
Diese Offenheit ist ein wichtiger Teil meiner Produktentscheidung. Ein Paketierungsprojekt sollte möglichst lange nutzbar bleiben, auch wenn sich das operative Zielsystem verändert. Heute wird ein Paket vielleicht über Microsoft Intune ausgerollt, während ein anderer Kunde SCCM nutzt. Ein Dienstleister pflegt zusätzlich ein internes Chocolatey-Repository. Das fachliche Wissen über Installation und Deinstallation sollte deshalb nicht mehrfach und widersprüchlich gepflegt werden müssen.
PSDeployStudio legt strukturierte PSAppDeployToolkit-Projekte an und unterstützt dabei, Installerdateien, zentrale Metadaten sowie Silent-Install- und Uninstall-Parameter zu erfassen. Das Projekt kann anschließend direkt im bevorzugten Editor geöffnet und fachlich ergänzt werden. Das Tool soll den Administrator nicht aus dem Prozess verdrängen. Es soll die wiederkehrende Vorarbeit reduzieren und einen verlässlichen Ausgangspunkt schaffen.
Drei Projektwege für unterschiedliche Ausgangslagen
Nicht jede Paketierungsaufgabe beginnt gleich. Deshalb unterstützt PSDeployStudio verschiedene Projektarten.
Ein leeres Projekt ist für erfahrene Paketierer gedacht, die bereits genau wissen, wie sie vorgehen möchten. Es liefert die Struktur, ohne einen unnötig engen Ablauf vorzugeben.
Ein Wizard-Projekt führt durch die wichtigsten Angaben. Das ist hilfreich, wenn ein Team Mindeststandards vereinheitlichen oder seltener paketierende Administratoren durch den Start führen möchte. Hersteller, Name, Version, Installer und Silent-Parameter werden nicht mehr über mehrere Orte verteilt zusammengetragen.
Ein Snapshot-Projekt adressiert Installationen, die sich nicht ausreichend über einen üblichen MSI- oder EXE-Aufruf beschreiben lassen. Dabei werden Zustände vor und nach einer Installation verglichen. Erkannte Datei- und Registry-Änderungen können anschließend als Grundlage für ein reproduzierbares Deployment dienen. Snapshot-Ergebnisse brauchen weiterhin eine fachliche Bereinigung, denn temporäre Dateien oder systembedingtes Rauschen gehören nicht automatisch in ein Paket.
Readiness statt falscher Automatisierungssicherheit
Automatisierung darf nicht so tun, als sei ein Paket allein durch das Vorhandensein einiger Dateien produktionsbereit. PSDeployStudio verwendet deshalb Readiness-Checks. Geprüft werden unter anderem die Projektdatei, das zentrale Deployment-Skript, Metadaten, Installerdatei, Silent-Parameter und Detection-Hinweise.
Das Ergebnis ist keine Freigabe. Es ist eine strukturierte Antwort auf die Frage, ob die notwendigen Grundlagen vorhanden sind. Ein Administrator muss weiterhin in einer geeigneten Testumgebung prüfen, ob Installation, Reparatur, Update und Deinstallation wie erwartet funktionieren. Ebenso bleiben organisatorische Entscheidungen – etwa Wartungsfenster, Benutzerkommunikation oder gestaffelte Rollouts – außerhalb des Tools.
Diese Abgrenzung ist mir wichtig. PSDeployStudio soll Routinearbeit vereinfachen, aber keine Scheinsicherheit erzeugen. Ein grüner Status bedeutet: Die bekannten Voraussetzungen für den nächsten Schritt sind vorhanden. Er bedeutet nicht: Dieses Paket kann ohne Test auf alle Geräte verteilt werden.
Mehrere Exportziele, eine gemeinsame Paketquelle
Die erste Version unterstützt Exporte für Microsoft Intune und SCCM sowie Arbeitsabläufe für Chocolatey, WinGet und NSIS. Je nach Ziel werden unterschiedliche Dateien, Skripte oder Hinweise benötigt. Intune verwendet beispielsweise das .intunewin-Format, während SCCM andere Strukturen und Detection-Informationen erwartet. Chocolatey und WinGet verfolgen wiederum eigene Paket- und Manifestkonzepte.
Der Nutzen liegt nicht darin, alle Zielsysteme gleichzumachen. Das wäre fachlich falsch. PSDeployStudio hält stattdessen die gemeinsamen Projektinformationen zusammen und bereitet daraus zielsystemspezifische Ergebnisse vor. So bleibt sichtbar, welche Informationen aus der Paketquelle stammen und welche Besonderheiten erst durch das Zielsystem entstehen.
Für MSPs ist das besonders relevant. Ein Dienstleister kann dieselbe Anwendung für mehrere Kunden betreuen, obwohl deren Endpoint-Management unterschiedlich aufgebaut ist. Ein nachvollziehbares Ausgangsprojekt reduziert die Gefahr, dass sich Installationslogik und Dokumentation zwischen Kunden unbemerkt auseinanderentwickeln.
Für wen PSDeployStudio gedacht ist – und für wen nicht
PSDeployStudio richtet sich an Menschen, die regelmäßig Windows-Anwendungen paketieren. Dazu zählen interne Client-Management-Teams, Intune- und SCCM-Administratoren, Managed-Service-Provider und spezialisierte Paketierer. Besonders sinnvoll ist das Tool, wenn mehrere Exportziele bedient, Projektstände übergeben oder Mindeststandards im Team vereinheitlicht werden sollen.
Wer einmal im Jahr einen einzelnen MSI-Installer per Gruppenrichtlinie verteilt, braucht wahrscheinlich keinen eigenen Paketierungsarbeitsbereich. Auch ersetzt PSDeployStudio kein Endpoint-Management, kein Testlabor und keine Rollout-Planung. Die Software erstellt und prüft Paketierungsprojekte; die kontrollierte Verteilung bleibt Aufgabe der vorhandenen Management-Plattform und des verantwortlichen IT-Teams.
Der Weg bis zum Release
Bis zum 15. September veröffentliche ich weitere Einblicke in die Entwicklung. Im nächsten Beitrag zeige ich, wie ein konsistenter PSAppDeployToolkit-Workflow vom Installer bis zum geprüften Projekt aussehen kann. Danach geht es um die Unterschiede zwischen den Exportzielen sowie um Snapshot- und KI-gestützte Review-Funktionen.
Der Release erfolgt zunächst nur in der DACH-Region. Dadurch kann ich Dokumentation, Kommunikation und Rückmeldungen in einem klar abgegrenzten Markt aufbauen, bevor später über weitere Regionen entschieden wird.
PSDeployStudio zum Release kennenlernen
Abonnieren Sie meinen Newsletter. Sie erhalten am 15. September die Verfügbarkeitsmeldung und 50 % Einführungsrabatt.
Weitere Informationen und aktuelle Screenshots finden Sie auf der PSDeployStudio-Produktseite. Die Anmeldung zum Newsletter ist freiwillig und jederzeit widerrufbar.