Was ist MSIX?
Wer unter Windows Software installiert, begegnet normalerweise Installationsdateien wie .exe oder .msi. Seit einigen Jahren gibt es mit MSIX ein weiteres Paketformat, das insbesondere für eine kontrollierte und moderne Bereitstellung von Windows-Anwendungen entwickelt wurde.
Eine entsprechende Installationsdatei kann beispielsweise so aussehen:
MeineAnwendung.msix
Neben einzelnen MSIX-Paketen existieren auch Bundles:
MeineAnwendung.msixbundle
Ein Bundle kann unterschiedliche Varianten einer Anwendung enthalten, beispielsweise für verschiedene Prozessorarchitekturen.
MSIX kombiniert Konzepte verschiedener älterer Microsoft-Technologien. Dazu gehören insbesondere MSI, AppX und App-V. Technisch basiert MSIX stark auf der bereits von AppX bekannten Paket-Infrastruktur von Windows.
Das erklärt auch, weshalb viele PowerShell-Befehle zur Verwaltung von MSIX-Paketen weiterhin Appx im Namen tragen.
Warum wurde MSIX entwickelt?
Klassische Windows-Installationen sind äußerst flexibel. Genau diese Flexibilität kann allerdings zum Problem werden.
Ein traditioneller EXE-Installer kann beispielsweise Dateien in verschiedene Verzeichnisse kopieren, Registry-Einträge erzeugen, Komponenten registrieren und weitere Änderungen am Betriebssystem durchführen.
Nach einigen Jahren intensiver Softwareinstallation können sich deshalb zahlreiche Überbleibsel auf einem Windows-System befinden.
Typische Kandidaten sind:
C:\Program Files\ C:\Program Files (x86)\ C:\ProgramData\ C:\Users\<Benutzer>\AppData\
Dazu kommen Einträge in der Windows-Registry.
Selbst wenn eine Anwendung wieder deinstalliert wird, bedeutet das nicht zwangsläufig, dass sämtliche Änderungen vollständig rückgängig gemacht werden.
MSIX verfolgt deshalb einen stärker paketorientierten Ansatz. Windows besitzt wesentlich genauere Informationen darüber, welche Bestandteile zu einem bestimmten Paket gehören.
Das erleichtert unter anderem Installation, Aktualisierung und Deinstallation.
Wie ist ein MSIX-Paket aufgebaut?
Eine MSIX-Datei ist im Grunde ein Paket, das verschiedene Bestandteile einer Anwendung zusammenfasst.
Dazu gehören beispielsweise:
- Programmdateien
- Bibliotheken
- Grafiken und andere Ressourcen
- Konfigurationsinformationen
- Informationen über Abhängigkeiten
- Paket-Metadaten
- digitales Zertifikat beziehungsweise Signaturinformationen
Besonders wichtig ist das Manifest.
Bei MSIX beziehungsweise AppX begegnet uns beispielsweise:
AppxManifest.xml
Das Manifest beschreibt die Anwendung und enthält wichtige Informationen wie Paketidentität, Version, Herausgeber, Prozessorarchitektur, Abhängigkeiten, Einstiegspunkte und benötigte Fähigkeiten.
Windows muss deshalb nicht erst einen beliebigen Installationsprozess ausführen, um herauszufinden, was mit dem System geschehen soll. Wesentliche Eigenschaften des Pakets sind bereits definiert.
Digitale Signaturen und Sicherheit
Ein zentraler Bestandteil des MSIX-Konzepts ist die digitale Signierung.
Ein MSIX-Paket muss für eine reguläre Installation entsprechend signiert sein. Windows kann dadurch unter anderem überprüfen, ob das Paket nach seiner Signierung verändert wurde und ob die Paketidentität zur Signatur passt.
Das bedeutet allerdings nicht automatisch, dass jede signierte Anwendung vertrauenswürdig oder sicher ist.
Eine digitale Signatur bestätigt primär die Integrität und Identität innerhalb des Signaturmodells. Sie ersetzt keine Prüfung der Software selbst.
Gerade in Unternehmensumgebungen bietet die Signierung dennoch einen erheblichen Vorteil: Administratoren können wesentlich kontrollierter festlegen, welche Softwarepakete verteilt und installiert werden dürfen.
MSIX und die saubere Deinstallation
Ein wichtiger Vorteil des Paketmodells zeigt sich bei der Deinstallation.
Klassische Installer können Änderungen an vielen verschiedenen Stellen des Systems durchführen. Die Deinstallationsroutine muss später versuchen, diese Änderungen wieder rückgängig zu machen.
MSIX arbeitet stärker mit einem verwalteten Paketmodell und entsprechenden Mechanismen zur Isolation beziehungsweise Umleitung bestimmter Schreibzugriffe.
Dadurch kann Windows Paketbestandteile besser einer bestimmten Anwendung zuordnen.
Wird das Paket entfernt, lassen sich die verwalteten Komponenten entsprechend kontrollierter entfernen.
Das reduziert die Gefahr der bekannten Situation:
„Die Anwendung wurde erfolgreich deinstalliert.“
… während im Hintergrund noch drei Verzeichnisse, diverse Registry-Einträge und eine Sammlung digitaler Erinnerungsstücke weiterexistieren.
MSIX, MSI und EXE – wo liegen die Unterschiede?
Eine EXE-Datei ist zunächst lediglich eine ausführbare Datei. Ein Setup-Programm im EXE-Format kann nahezu beliebige Installationslogik implementieren.
Das macht EXE-Installer sehr flexibel, gleichzeitig aber weniger standardisiert.
MSI verwendet dagegen den Windows Installer und arbeitet bereits mit einem strukturierten Installationsmodell. MSI ist seit Jahrzehnten ein wichtiger Standard insbesondere in Unternehmensumgebungen.
MSIX geht beim Paketmodell und der kontrollierten Bereitstellung noch einen Schritt weiter.
Vereinfacht lässt sich sagen:
EXE: maximale Flexibilität des Installationsprogramms.
MSI: standardisierte Installation über Windows Installer.
MSIX: stärker paketbasierte, signierte und kontrollierte Bereitstellung moderner Windows-Anwendungen.
Das bedeutet allerdings nicht, dass MSIX MSI und EXE in jedem Szenario ersetzen kann.
MSIX und AppX
Wer MSIX administriert, stößt sehr schnell auf den Begriff AppX.
Das liegt daran, dass MSIX auf Technologien aufbaut, die Microsoft bereits für AppX entwickelt hatte.
Deshalb heißen wichtige PowerShell-Cmdlets weiterhin beispielsweise:
Get-AppxPackage
und:
Add-AppxPackage
Obwohl wir mit einem .msix-Paket arbeiten, verwenden wir also häufig Cmdlets mit Appx im Namen.
Installierte Pakete mit PowerShell anzeigen
Eine der einfachsten Möglichkeiten, sich mit der Paketverwaltung vertraut zu machen, ist PowerShell.
Mit folgendem Befehl können Pakete des aktuellen Benutzers angezeigt werden:
Get-AppxPackage
Die Ausgabe enthält verschiedene Informationen über die installierten Pakete.
Interessante Eigenschaften sind beispielsweise:
Name Publisher Architecture Version PackageFullName InstallLocation
Möchten wir nur ausgewählte Informationen sehen, können wir die Ausgabe einschränken:
Get-AppxPackage |
Select-Object Name, Version, Architecture
Das ist insbesondere bei längeren Paketlisten deutlich übersichtlicher.
Nach einem bestimmten Paket suchen
Kennt man einen Teil des Paketnamens, kann die Suche beispielsweise so erfolgen:
Get-AppxPackage -Name "*Terminal*"
Alternativ lässt sich die PowerShell-Pipeline verwenden:
Get-AppxPackage |
Where-Object Name -like "*Terminal*"
Für die Administration größerer Systeme ist insbesondere die Kombination mit Select-Object praktisch:
Get-AppxPackage -Name "*Terminal*" |
Select-Object Name, Version, PackageFullName, InstallLocation
MSIX-Paket mit PowerShell installieren
Liegt ein MSIX-Paket lokal vor, kann es mit Add-AppxPackage installiert werden.
Beispiel:
Add-AppxPackage -Path "C:\Software\MeineAnwendung.msix"
Für ein MSIX-Bundle funktioniert das entsprechend:
Add-AppxPackage -Path "C:\Software\MeineAnwendung.msixbundle"
Voraussetzung ist natürlich, dass das Paket gültig ist und alle notwendigen Anforderungen wie Signatur und Abhängigkeiten erfüllt sind.
Paket entfernen
Ein installiertes Paket kann ebenfalls über PowerShell entfernt werden.
Zunächst können wir das gewünschte Paket suchen:
Get-AppxPackage -Name "*MeineAnwendung*"
Anschließend lässt es sich über die Pipeline an Remove-AppxPackage übergeben:
Get-AppxPackage -Name "*MeineAnwendung*" |
Remove-AppxPackage
Bei administrativen Skripten sollte vorher unbedingt geprüft werden, ob der verwendete Filter tatsächlich nur das gewünschte Paket erfasst.
Ein zu großzügiges Wildcard-Muster kann ansonsten mehr Anwendungen erwischen als beabsichtigt.
Installationsverzeichnis eines Pakets ermitteln
Auch der Installationsort lässt sich mit PowerShell anzeigen:
Get-AppxPackage -Name "*Terminal*" |
Select-Object Name, InstallLocation
Paketierte Anwendungen befinden sich typischerweise unter:
C:\Program Files\WindowsApps
Dieses Verzeichnis ist besonders geschützt. Die dortigen Berechtigungen sollten nicht einfach verändert werden, nur um komfortabler auf die Dateien zugreifen zu können.
Paketversion ermitteln
Für Inventarisierung und Fehlersuche ist häufig die installierte Version interessant:
Get-AppxPackage -Name "*Terminal*" |
Select-Object Name, Version
Eine kompakte Ausgabe kann beispielsweise mit Format-Table erzeugt werden:
Get-AppxPackage |
Select-Object Name, Version |
Format-Table -AutoSize
Damit lässt sich schnell feststellen, welche Paketversion auf einem System installiert ist.
Alle Benutzer berücksichtigen
Bei administrativen Aufgaben kann es notwendig sein, Pakete nicht nur für den aktuell angemeldeten Benutzer zu betrachten.
Dafür existiert beispielsweise:
Get-AppxPackage -AllUsers
Dieser Aufruf kann erhöhte Rechte beziehungsweise eine administrative PowerShell-Sitzung erfordern.
Anschließend können wir die Ausgabe wieder filtern:
Get-AppxPackage -AllUsers |
Select-Object Name, Version, PackageFullName
Gerade bei Mehrbenutzersystemen ist die Unterscheidung zwischen Paketen des aktuellen Benutzers und Paketen anderer Benutzer wichtig.
Installierte Pakete exportieren
Für Dokumentation oder Inventarisierung kann eine Paketliste beispielsweise als CSV-Datei gespeichert werden:
Get-AppxPackage |
Select-Object Name, Version, Publisher, Architecture |
Export-Csv -Path "C:\Temp\AppxPackages.csv" -NoTypeInformation
Damit erhalten wir eine Datei:
C:\Temp\AppxPackages.csv
Diese kann anschließend beispielsweise mit Excel, LibreOffice Calc oder einem anderen Werkzeug ausgewertet werden.
Ein kleines Inventarisierungsskript
Mehrere Schritte lassen sich natürlich miteinander kombinieren.
Beispiel:
$Packages = Get-AppxPackage
$Packages |
Select-Object Name, Version, Architecture, Publisher |
Sort-Object Name |
Export-Csv `
-Path "C:\Temp\Windows-Pakete.csv" `
-NoTypeInformation
Damit werden die Pakete ermittelt, ausgewählte Eigenschaften übernommen, alphabetisch sortiert und anschließend als CSV-Datei gespeichert.
Solche kleinen Skripte können bei Inventarisierungen oder bei der Fehlersuche hilfreich sein.
Abhängigkeiten von MSIX-Paketen
Nicht jede Anwendung besteht ausschließlich aus einem einzelnen MSIX-Paket.
Ein Paket kann zusätzliche Frameworks oder andere Pakete benötigen. Fehlt eine erforderliche Abhängigkeit, kann die Installation fehlschlagen.
Bei einer manuellen Installation sollte deshalb geprüft werden, ob der Hersteller zusätzliche Pakete bereitstellt.
PowerShell unterstützt die Angabe von Abhängigkeiten beispielsweise über Parameter von Add-AppxPackage. Je nach Bereitstellungsszenario kann die Installation deshalb umfangreicher sein als ein einzelner Aufruf mit -Path.
Was ist ein MSIXBundle?
Ein .msixbundle fasst mehrere Pakete zusammen.
Das ist beispielsweise sinnvoll, wenn eine Anwendung für unterschiedliche Architekturen bereitgestellt wird.
Denkbar sind unter anderem:
x64 x86 ARM64
Windows kann anhand des Bundles die für das jeweilige System geeigneten Bestandteile auswählen.
Für Anwender und Administratoren vereinfacht dies die Bereitstellung, weil nicht für jede Architektur eine separate Installationsdatei ausgewählt werden muss.
Updates mit MSIX
Auch Aktualisierungen gehören zu den Stärken des Paketmodells.
Pakete besitzen eine definierte Identität und Versionsinformationen. Dadurch kann Windows erkennen, welche Version einer Anwendung installiert ist und welche Version bereitgestellt werden soll.
Das erleichtert kontrollierte Updates und verhindert einige der Probleme, die bei individuell programmierten Update-Routinen klassischer Anwendungen auftreten können.
Je nach Bereitstellungsmodell können Aktualisierungen beispielsweise über Unternehmensverwaltung, einen Store oder andere definierte Quellen erfolgen.
MSIX in Unternehmensumgebungen
Besonders interessant wird MSIX bei der zentralen Softwareverwaltung.
Administratoren benötigen reproduzierbare Installationen. Eine Anwendung soll auf Rechner A möglichst genauso bereitgestellt werden wie auf Rechner B.
MSIX bietet hierfür verschiedene Vorteile:
- standardisiertes Paketformat
- digitale Signierung
- Paketidentität
- Versionsverwaltung
- kontrolliertere Installation
- kontrolliertere Deinstallation
- Unterstützung verschiedener Bereitstellungsmöglichkeiten
- bessere Voraussetzungen für automatisierte Softwareverteilung
MSIX kann deshalb unter anderem in Verbindung mit modernen Endpoint-Management-Lösungen interessant sein.
MSIX App Attach
In größeren virtualisierten Umgebungen begegnet Administratoren möglicherweise außerdem MSIX App Attach.
Dabei werden Anwendungen nicht unbedingt klassisch dauerhaft in das Betriebssystem-Image eingebaut. Stattdessen können paketierte Anwendungen dynamischer für Benutzer beziehungsweise Sitzungen bereitgestellt werden.
Das ist insbesondere für virtuelle Desktop-Infrastrukturen interessant, weil Basisbetriebssystem und Anwendungen stärker voneinander getrennt verwaltet werden können.
Für einen normalen Windows-Arbeitsplatz ist dieses Verfahren nicht zwingend relevant, zeigt aber, dass MSIX weit mehr als nur eine neue Dateiendung für Setup-Dateien ist.
Kann jede Anwendung als MSIX bereitgestellt werden?
Nein.
MSIX besitzt bewusst Einschränkungen gegenüber völlig frei arbeitenden klassischen Installern. Genau diese Einschränkungen ermöglichen viele Sicherheits-, Zuverlässigkeits- und Wartungsvorteile.
Anwendungen mit sehr speziellen Anforderungen an Treiber, Dienste, tiefgreifende Systemänderungen oder ungewöhnliche Installationsmechanismen können deshalb schwieriger zu paketieren sein.
Vor einer Migration bestehender Anwendungen sollte daher geprüft werden, ob sie für MSIX geeignet sind.
Bestehende Anwendungen in MSIX umwandeln
Microsoft stellt beziehungsweise stellte für entsprechende Paketierungsszenarien Werkzeuge rund um die MSIX-Technologie bereit. Damit können klassische Installationsvorgänge analysiert und in ein Paket überführt werden.
Dabei sollte eine Konvertierung allerdings nicht als simples „EXE rein, MSIX raus“ betrachtet werden.
Das erzeugte Paket muss anschließend getestet werden.
Besonders wichtig sind unter anderem:
- Programmstart
- Benutzerprofile
- Registry-Zugriffe
- Dateizugriffe
- Updates
- Kommunikation mit anderen Anwendungen
- benötigte Dienste
- Abhängigkeiten
- Deinstallation
Gerade ältere Windows-Anwendungen können Annahmen über das Betriebssystem treffen, die nicht ohne Weiteres zum moderneren Paketmodell passen.
Wann lohnt sich MSIX?
MSIX ist besonders interessant, wenn Anwendungen standardisiert, reproduzierbar und kontrolliert bereitgestellt werden sollen.
Typische Einsatzbereiche sind moderne Windows-Arbeitsplätze, zentral verwaltete Unternehmensgeräte, virtuelle Desktopumgebungen und Anwendungen, bei denen zuverlässige Installation und Aktualisierung besonders wichtig sind.
Für Administratoren lohnt es sich daher, MSIX zumindest grundsätzlich zu verstehen.
Denn selbst wenn im eigenen Unternehmen weiterhin zahlreiche MSI- und EXE-Installer verwendet werden, begegnen einem MSIX und die zugrunde liegende AppX-Paketverwaltung bereits an vielen Stellen moderner Windows-Systeme.
Fazit
MSIX ist wesentlich mehr als eine weitere Dateiendung für Windows-Installer.
Microsoft verbindet damit ein modernes Paketmodell, das Anwendungen strukturierter und kontrollierter bereitstellen soll. Digitale Signaturen, Paketidentitäten, Versionsinformationen und eine sauberere Trennung zwischen Anwendung und Betriebssystem verbessern insbesondere Installation, Aktualisierung und Deinstallation.
Für Administratoren ist außerdem wichtig zu verstehen, dass MSIX eng mit der bestehenden AppX-Infrastruktur verbunden ist. Deshalb spielen PowerShell-Cmdlets wie Get-AppxPackage, Add-AppxPackage und Remove-AppxPackage weiterhin eine zentrale Rolle.
MSI und klassische EXE-Installer werden dadurch nicht automatisch überflüssig. Für moderne Windows-Umgebungen ist MSIX jedoch eine wichtige Technologie – insbesondere dort, wo Software zentral verwaltet, automatisiert verteilt und möglichst reproduzierbar betrieben werden soll.
