Ein ausführbarer Installer ist noch kein Deployment-Paket. Für eine kontrollierte Softwareverteilung müssen Quelle, Installationsbefehl, Deinstallation, Erkennung und Fehlerverhalten zusammenpassen. In der Praxis werden diese Informationen trotzdem häufig erst während des Paketierens zusammengesucht. Das kostet Zeit und macht Übergaben unnötig schwer.
Ein belastbarer PSAppDeployToolkit-Workflow trennt deshalb klar zwischen Recherche, Umsetzung, technischer Prüfung und produktiver Freigabe. In diesem Beitrag zeige ich einen Ablauf, der sich für interne IT-Teams und Managed-Service-Provider eignet. Er ist unabhängig davon sinnvoll, ob das Ergebnis später mit Microsoft Intune, SCCM oder einer anderen Management-Lösung verteilt wird.
PSDeployStudio, meine derzeit in Entwicklung befindliche Windows-Anwendung, bildet genau diesen Ablauf als strukturierten Arbeitsbereich ab. Der DACH-Release ist für den 15. September 2026 vorgesehen. Bei Fragen zum Verkaufsstart oder zum Einführungsrabatt können Sie mich über das Kontaktformular erreichen.
1. Paketierungsauftrag und Quelle klären
Der erste Schritt beginnt vor PowerShell. Ein Paketierungsauftrag braucht einen klaren Umfang: Welche Anwendung und Version sollen verteilt werden? Handelt es sich um eine Neuinstallation, ein Update oder den Ersatz einer bestehenden Anwendung? Welche Windows-Versionen und Architekturen werden unterstützt? Gibt es Abhängigkeiten, Lizenzbedingungen oder einen Neustartbedarf?
Ebenso wichtig ist eine vertrauenswürdige Quelle. Installer sollten möglichst direkt vom Hersteller oder aus einem kontrollierten internen Repository stammen. Der ursprüngliche Dateiname allein ist kein ausreichender Nachweis. Halten Sie Downloadquelle, Abrufdatum, Version und idealerweise einen Hashwert fest. So lässt sich später nachvollziehen, ob zwei gleich benannte Dateien tatsächlich identisch sind.
Für Dienstleister gehört außerdem der Kundenkontext in den Auftrag. Manche Anwendungen brauchen kundenspezifische Konfigurationen, Mandanten-URLs oder Zertifikate. Diese Informationen sollten nicht unkontrolliert in ein generisches Basispaket geraten. Definieren Sie, welche Bestandteile wiederverwendbar und welche kundenspezifisch sind.
2. Installer technisch untersuchen
MSI-Pakete liefern häufig strukturierte Produktinformationen und standardisierte Kommandozeilenoptionen. Trotzdem sollte nicht automatisch davon ausgegangen werden, dass /qn alle Anforderungen löst. Prüfen Sie Properties, Transform-Dateien, Rückgabecodes und das Upgrade-Verhalten. Bei EXE-Installern ist die Recherche oft aufwendiger. Herstellerdokumentation, integrierte Hilfen und kontrollierte Tests sind verlässlicher als eine zufällige Parameterliste aus einem Forum.
Für Installation und Deinstallation müssen mindestens folgende Punkte feststehen:
- exakter Silent-Installationsbefehl,
- exakter Silent-Deinstallationsbefehl,
- erwartete Erfolgs- und Neustartcodes,
- Ausführungskontext – System oder Benutzer,
- Verhalten bei bereits installierter oder neuerer Version,
- laufende Prozesse, die eine Installation verhindern,
- Dateien oder Einstellungen, die nach der Installation ergänzt werden müssen.
Dokumentieren Sie Unsicherheiten sichtbar. Ein ungeprüfter Parameter darf nicht unbemerkt zu einer vermeintlich fertigen Paketdefinition werden.
3. Metadaten konsistent erfassen
Metadaten wirken nebensächlich, werden aber an vielen Stellen wiederverwendet. Hersteller, Produktname, Version, Sprache, Architektur, Autor und Beschreibung sollten deshalb einheitlich geschrieben werden. Abweichungen wie 7-Zip, 7zip und 7 Zip erschweren Suche, Reporting und automatisierte Vergleiche.
Legen Sie außerdem eine interne Namenskonvention fest. Ein Projektname kann beispielsweise Hersteller, Produkt und Version enthalten, während die technische Paket-ID stabiler aufgebaut wird. Wichtig ist weniger die konkrete Syntax als ihre konsequente Verwendung.
In PSDeployStudio werden diese Angaben zentral im Projekt geführt. Daraus können Projektstruktur und Exportinformationen abgeleitet werden. Der Administrator behält dennoch die Möglichkeit, Sonderfälle bewusst anzupassen.
4. PSAppDeployToolkit-Projekt erstellen
Nun entsteht das eigentliche Deployment-Projekt. PSAppDeployToolkit bietet eine wiedererkennbare Struktur für Vorbereitungs-, Installations- und Abschlussaktionen. Nutzen Sie diese Struktur, statt alle Befehle in einen unkommentierten Block zu schreiben.
Ein gutes Projekt macht beim Lesen deutlich:
- welche Voraussetzungen geprüft werden,
- welche Prozesse vor der Installation geschlossen werden müssen,
- wie der Installer aufgerufen wird,
- welche Konfiguration anschließend erfolgt,
- wie Fehler behandelt und protokolliert werden,
- wie der vollständige Rückweg bei einer Deinstallation aussieht.
Vermeiden Sie unnötige Speziallogik. Jede zusätzliche Abzweigung erhöht die Zahl der Testfälle. Wenn ein Standard-MSI-Aufruf ausreicht, ist ein kompliziertes Wrapper-Skript kein Qualitätsmerkmal. Ergänzen Sie nur Logik, die einen konkreten betrieblichen Zweck erfüllt.
PSDeployStudio kann neue Projekte als leeres Projekt oder über einen Wizard anlegen. Nach dem Erstellen lässt sich die Projektdatei direkt in PowerShell ISE, Visual Studio Code oder Notepad++ öffnen. Damit bleibt die eigentliche Skriptlogik transparent und editierbar.
5. Detection nicht erst am Ende erfinden
Ein Installationsbefehl beantwortet nicht die Frage, ob eine Anwendung auf einem Gerät in der erwarteten Version vorhanden ist. Genau dafür braucht es eine belastbare Detection-Strategie. Diese sollte schon beim Paketdesign feststehen.
Bei MSI-Paketen kann ein Product Code hilfreich sein. Er ist aber nicht automatisch für jede Upgrade-Strategie geeignet. Datei-Versionen eignen sich nur, wenn die gewählte Datei stabil mit der Produktversion korreliert. Registry-Werte können verlässlich sein, sofern der Hersteller sie konsistent pflegt. Komplexere Produkte benötigen eventuell ein Detection-Skript, das mehrere Merkmale kombiniert.
Die Detection muss zum gewünschten Zustand passen. Soll jede Version ab einem Mindeststand akzeptiert werden, ist ein exakter Versionsvergleich möglicherweise zu streng. Soll eine alte Version gezielt ersetzt werden, darf die Erkennung nicht schon bei deren Vorhandensein Erfolg melden.
PSDeployStudio führt Detection-Hinweise in den Readiness-Checks. Das Tool entscheidet nicht pauschal, welche Regel fachlich korrekt ist. Es verhindert aber, dass dieser wichtige Punkt im Projektstatus unsichtbar bleibt.
6. Installation, Update und Deinstallation testen
Ein einzelner erfolgreicher Installationslauf reicht nicht. Prüfen Sie mindestens folgende Szenarien auf einem sauberen oder zuverlässig zurückgesetzten Testsystem:
- Neuinstallation ohne vorhandene Version,
- erneute Ausführung bei bereits installiertem Zielstand,
- Update von einer realistisch vorhandenen Vorgängerversion,
- Deinstallation nach erfolgreicher Installation,
- Verhalten bei laufender Anwendung,
- erforderlicher Neustart und dessen Rückgabecode,
- Installation im tatsächlichen Ausführungskontext der Verteilplattform.
Kontrollieren Sie danach nicht nur den Exit Code. Startet die Anwendung? Sind Dienste korrekt eingerichtet? Bleiben unerwünschte Autostarts oder temporäre Dateien zurück? Funktioniert die Deinstallation auch dann, wenn Benutzer das Programm bereits verwendet haben?
Für MSPs lohnt sich eine standardisierte Testdokumentation. Sie macht gegenüber Kunden sichtbar, was geprüft wurde, und erleichtert die erneute Bewertung bei einer neuen Version.
7. Readiness vor dem Export bewerten
Bevor ein Projekt für Intune oder SCCM exportiert wird, sollte eine definierte Mindestprüfung erfolgen. Dazu gehören das zentrale Deployment-Skript, die Installerquelle, vollständige Metadaten, Silent-Parameter und Detection-Konzept. Optional können Prüfsummen, Testprotokolle oder Freigabevermerke ergänzt werden.
PSDeployStudio fasst solche Voraussetzungen in einer Projektübersicht zusammen. Dadurch ist auf einen Blick erkennbar, ob ein Paket grundsätzlich exportierbar ist oder noch Informationen fehlen. Das ist vor allem in Teams nützlich: Eine Vertretung muss nicht jedes Verzeichnis manuell öffnen, um den Stand zu verstehen.
Readiness ist dennoch nicht gleich Produktionsfreigabe. Die technische Vollständigkeit des Projekts und die betriebliche Entscheidung zum Rollout bleiben zwei getrennte Zustände.
8. Zielsystemspezifisch exportieren
Erst jetzt wird aus der gemeinsamen Paketquelle ein Ergebnis für das gewünschte Zielsystem. Microsoft Intune benötigt für Win32-Anwendungen typischerweise ein .intunewin-Paket und zusätzliche Angaben in der Management-Oberfläche. SCCM arbeitet mit einer anderen Anwendungs- und Inhaltsstruktur. Chocolatey, WinGet und NSIS haben wiederum eigene Metadaten und Build-Schritte.
PSDeployStudio bereitet diese Exporte zielsystemspezifisch vor. Das bedeutet nicht, dass jeder Export sofort ohne Kontrolle veröffentlicht werden kann. Beim WinGet-Manifest muss beispielsweise eine reale Downloadquelle stimmen. Bei Intune und SCCM bleiben Zuweisung, Anforderungen, Detection und Rollout-Ringe Teil der jeweiligen Plattformkonfiguration.
Der Vorteil ist eine klare Trennung: Das gemeinsame Paketierungswissen bleibt im Projekt; der Export ergänzt die Anforderungen des jeweiligen Zielsystems.
9. Freigabe und Betrieb dokumentieren
Nach den technischen Tests folgt die betriebliche Freigabe. Legen Sie fest, wer das Paket geprüft hat, wann es freigegeben wurde und für welche Umgebung es gilt. Ein gestaffelter Rollout über Test-, Pilot- und Produktivgruppen reduziert Risiken. Monitoring und Rückmeldungen aus dem Endpoint-Management gehören ebenfalls zum Prozess.
Planen Sie schon jetzt den nächsten Versionswechsel. Ein Paket ist kein einmaliges Artefakt, sondern Teil des Application Lifecycle. Wenn Quellnachweis, Projektstruktur und Testfälle sauber dokumentiert sind, beginnt die nächste Version nicht wieder bei null.
Ein Werkzeug für den Prozess, nicht gegen ihn
PSDeployStudio wurde aus genau dieser Perspektive entwickelt: Gute Paketierung braucht nachvollziehbare Entscheidungen, aber nicht jede Entscheidung muss durch wiederkehrende Handarbeit vorbereitet werden. Projektanlage, Metadatenerfassung, Statusprüfung und Export können konsistenter werden, während Tests und fachliche Freigabe bewusst beim Administrator bleiben.
Am 15. September startet PSDeployStudio
Der erste Release ist für Deutschland, Österreich und die Schweiz geplant. Fragen Sie über das Kontaktformular nach dem Verkaufsstart und dem Einführungsrabatt.
Auf der PSDeployStudio-Landingpage finden Sie den Funktionsumfang, Screenshots und den vollständigen Veröffentlichungsplan.