In den beiden letzten Teilen der Serie (Hier geht’s zu Teil 1 und Teil 2) haben wir uns mit der Natur von MSIX-Paketen auseinandergesetzt und grundlegende Interaktionen kennen gelernt.
Im heutigen Teil der Serie werde ich versuchen, die
Titelfrage zu klären oder wenigstens meine persönlichen Eindrücke kundzutun: Was
heisst MSIX für mein Team?
Die Frage wird sich nicht abschliessend klären lassen, da wir bislang nur über einen überschaubaren Informationsstand verfügen. Für meinen Erklärungsversuch werden wir uns an folgender Grafik orientieren, sie stammt aus der MSIX-Dokumentation von Microsoft selbst:
Was heisst MSIX für einen Paketierer oder Developer?
Wir wissen derzeit noch nicht, wie eine Firma ein MSIX-Paket
genau erhalten wird. Kommen die Applikationen, wie unsere aktuellen MSI-Päckli,
vom Hersteller? Oder werden wir zukünftig alle Pakete über Microsoft beziehen?
In letzterem Fall ist davon auszugehen, dass das Paket
bereits getestet ist. Der Prozess dafür ist bereits implementiert und schon
heute in Aktion: Für die Bereitstellung von UWP-Applikationen im Appx-Format.
Falls die Pakete aber, wie wir das heute auch schon von MSI kennen, direkt vom
Hersteller geliefert wird, wissen wir grundsätzlich nicht, ob ein Paket
vertrauenswürdig ist. Stichwort: Microsoft Zertifikat (Zertifikate sind übrigens ebenfalls ein Thema, welches ich schon bald
in einem Blogbeitrag näher beleuchten werde – stay tuned!).
Meiner Ansicht nach sollten sich sowohl Entwickler wie auch Paketierer mit den Richtlinien und Normen vertraut machen, die MSIX- und Appx-Pakete betreffen. Man sollte sich etwa Wissen aneignen, wo MSIX-Packages überhaupt schreiben dürfen und was man mit den Registry-Infos machen kann. Das Web bietet hierbei entsprechende Ressourcen, wie dieser Artikel von Microsoft über die Anwendung von Runtime Fixes auf MSIX Paketen mit dem Package Support Framework.
Was heisst MSIX für einen IT-Pro?
Laut Microsoft sollten Pakete im Allgemeinen schon seit
längerem kategorisch signiert sein. In der Praxis geschieht das jedoch bisher
einzig bei den Store-Applikationen. Solche Pakete hätten, wie oben schon
angemerkt, das notwendige Zertifikat also bereits und können sofort installiert
werden. Wenn ein MSIX-Paket jedoch beim (oder für den) Kunden paketiert wird,
müssen IT-Pros den entsprechenden Prozess zum Signieren von Applikationen
etablieren. Unternehmen sind somit gezwungen, ihre PKI-Umgebung genauer
anzusehen und entsprechende (SelfSign) Code Sign Zertifikate ausstellen zu
können oder einzukaufen.
Fun Fact: Microsoft ist damit mittlerweile übrigens so gut wie allein – auf den Mobile-Plattformen und MacOS sind bereits heute alle Apps kategorisch signiert.
Ähm, und SCCM…?
Bezüglich Deployment gibt es besonders viele Fragen und offenen Punkte, die bisher unklar sind. In der Grafik spricht Microsoft von «Microsoft Store for Business» und «Intune», aber wo bleibt dabei SCCM? Die nächste Version von SCCM wird sicher MSIX-Pakete verteilen können, so viel wissen wir (und das dürfte auch selbsterklärend sein…). Aber wie es mit den Deployment Reports aussieht, wissen wir bisher beispielsweise noch nicht. Oder die Frage, ob eine Applikation auch wieder deinstalliert wird oder eben nicht – bei App-V hatte sich Microsoft bekanntermassen gegen eine Deinstallationsroutine entschieden. Die Vermutung, dass mit MSIX auch Änderungen in den bekannten Deinstallations-Praktiken auf uns zukommen, liegt also auf der Hand.
Update aus aktuellen Anlass: Wie Microsoft soeben bekannt gab, können MSIX-Pakete nun auf den Windows-10-Versionen 1709 und 1803 direkt installiert werden, auf Version 1809 zusätzlich über den Windows App Store.
Wird alles besser?
Microsoft hat ebenfalls eine Folie zu den «MSIX Benefits»,
also den Vorteilen, die uns MSIX bringen wird, veröffentlicht. An dieser Stelle
möchte ich noch kurz auf einzelne Punkte eingehen:
Spannend finde ich hier besonders «Disk Space Optimization».
Wenn also beispielsweise .Net Framework (ein «Ressource Package») teil eines
MSIX-Paketes ist und auch für das nächste Paket benötigt wird, wird es zwischen
den MSIX-Paketen geteilt. Somit muss es nur einmal heruntergeladen werden und
spart Platz. Praktisch! Der Punkt «Tamper Protection» ist ebenfalls
interessant, da weder Programmordner noch Registry Informationen über ein MSIX
Paket bekanntgeben. Einzig während der Laufzeit der Applikation ist die
Registry für das Betriebssystem sichtbar.
Was die IT nun tun muss…
Timothy Mangan, seines Zeichens bekannter App-V Guru sagte
kürzlich in einem Tweet, dass MSIX «der grösste Wechsel für Windows-Apps seit
dem INI-File» sei. Wow.
Mit dem Laden des Tweets akzeptieren Sie die Datenschutzerklärung von Twitter.
Mehr erfahren
In der Folge heisst das, dass sich IT-Verantwortliche
zwingend mit der neuen Technologie auseinandersetzen müssen, wenn man am Puls der
Software-Bereitstellung bleiben will. Bisher sind die Informationen eher
spärlich und werden im Laufe der nächsten Monate Stück für Stück folgen.
Meine Empfehlung: Schlaft nicht und macht euch schlau!
Abschliessend noch einige Inputs wie das am besten geht:
- clearByte Blog lesen (ich werde weiterhin Updates liefern…)
- Meine MSIX-Kurse besuchen (Infos auf clearbyte.ch oder kontaktiert uns bei Interesse via Mail)
- clearByte Twitter oder LinkedIn folgen
- Microsoft Blogs lesen
- Experimentieren!
Happy Packaging!
– Peter