Einleitung

Mittlerweile unterstützen alle namhaften Hersteller für Software-Paketierungswerkzeuge das neue Microsoft Paketformat MSIX. Microsoft selbst liefert ein Gratiswerkzeug, um bestehende Win32 Applikationen in das neue Paketformat zu konvertieren, genauer zu repaketieren. Folgende technische Voraussetzungen werden für das Werkzeug genannt:

• Windows 10 (mindestens Version 1809)
• Ein gültiges Microsoft Konto, um das Tool aus dem Windows Store zu beziehen
• Administrator-Berechtigungen auf dem zu installierenden System

Der folgende Artikel soll einen kurzen technischen Einstieg in die neue Version des Microsoft Installer liefern. In einem folgenden Artikel wird auf Werkzeuge und Methoden eingegangen, MSIX Pakete zu erzeugen oder bestehende Softwarepakete (MSI / Setup) in das neue Format zu migrieren.

Einführung

Microsoft hat auf dem Microsoft Developer Day im März 2018 die Zukunft der Softwareinstallation für Windows 10 basierte Geräte vorgestellt. MSIX ist eine vollständige „Containerisierungslösung“, welche alle großen Features von Universal Windows Plattform (UWP) übernimmt. Unterstützt werden Desktop, mobile und alle anderen Windows 10 – Geräte.

Technisch gesehen basiert MSIX auf dem AppX Paket Framework (ursprünglich lediglich für UWP Anwendungen verwendet) und wurde entwickelt, um klassische Windows Anwendungen besser zu unterstützen.

Bei der Paketierung in DSM gibt es ja verschiedene Möglichkeiten, dafür zu sorgen, dass Pakete nur unter bestimmten Bedingungen und Voraussetzungen auf den gemanagten Clients installiert werden. Zu nennen wären hier (ohne Anspruch auf Vollständigkeit):

• unterstützte Plattformen
• serverseitige Voraussetzungen
• clientseitige Voraussetzungen
• Bedingungen für vorhandene Installationen

Die Bedingungen für unterstützte Plattformen sollten klar sein: es werden nur für die Policy-Ziele auch Policy-Instanzen erzeugt, die eine der von dem Paket unterstützten Plattformen verwenden. Ebenso verhält es sich mit serverseitigen Voraussetzungen, auch hier wird eine Policy-Instanz nur dann erzeugt, wenn der Business Logic Server erkennt, dass die angegebenen Voraussetzungen von einem Policy-Ziel erfüllt sind.

Anders verhält es sich jedoch bei clientseitigen Voraussetzungen: für die Policy-Ziele werden auf jeden Fall Policy-Instanzen erzeugt (sofern die Plattform-Einstellungen und serverseitigen Voraussetzungen dem nicht widersprechen). Da DSM aber nicht alle erdenklichen Zustände über die verwalteten Clients in seiner Datenbank speichern kann, werden solche clientseitigen Voraussetzungen erst zur Laufzeit auf den Endgeräten geprüft und dann entschieden, ob die Installation ausgeführt wird oder nicht.

Ein naheliegender Anwendungsfall für die Verwendung von clientseitigen Voraussetzungen ist daher beispielsweise die Prüfung, ob genug freier Speicherplatz für die Installation eines Pakets zur Verfügung steht oder ob die Installation durch die Existenz eines Flags in der Registry oder im Dateisystem erlaubt ist. Bei diesem Vorgehen lauert jedoch "eine böse Falle"...

Viele Unternehmen scheuen das Update des Internet Explorer 8 auf eine neue Version, da viele (speziell unternehmensinterne) Websites genau auf die Version 8 zugeschnitten sind und damit ein erheblicher Aufwand beim Update des Browsers zu erwarten ist.

Mit Einführung des Enterprise Mode mit Internet Explorer 11 und der Verfügbarkeit des IE 11 auf Windows 7 hat Microsoft nun auf diese Problematik reagiert. Der Enterprise Mode gestattet es der zentralen IT, eine Liste von Websites zu pflegen, für die der Internet Explorer automatisch in einen IE 8 Kompatibilitätsmodus schaltet.

Nach der erfoglreichen Paketierung eines Paketes erfolgt der Rollout eines Paketes. Genau wie der Paketierung, sind beim Rollout in einem Unternehmen viele verschiedene Einstellungen und organisatorische Tätigkeiten zu beachten. Um die Steuerung des Rollout möglichst effizient zu gestalten steht unter Services -> Downloads -> pdfpool -> services ein neues Dokument zur Verfügung, welches in Form einer Checkliste den Rollout-Manager dabei unterstützt eine Anwendung in den produktiven Betrieb zu überführen. 

In der Vergangenheit habe ich die drei folgenden Formulare vorgestellt, die dabei helfen den Paketierungsprozess zu optimieren:

• Packaging Preperation
• Packaging Checkliste
• Packaging Approval

Neben den Checklisten, die die Qualität der einzelnen Schitte in einem Paketierungsprozess sicherstellen, ist es wichtig den Überlick über alle Pakete, die an diesem Prozess beteiligt sind, zu behalten.

Einige Hersteller von Softwaremanagement Systemen (mitunter eben auch Frontrange mit DSM 7) stellen eine eigene Packaging Workbench und einen Satz von Skript-Befehlen zur Verfügung, die sich auf die Anforderung für die Verteilung von Software spezialisiert haben. Ein Nachteil dieser Lösungen ist, dass sie nicht portierbar sind, da die Skript-Befehle nicht in einer bekannten Sprache (MSI, VB-Script, Powershell, etc.) implementiert sind, sondern jeweils individuelle Lösungen darstellen. Daher werden immer wieder Empfehlungen von verschiedenen Seiten ausgesprochen, alle Softwarepakete doch zu standardisieren und die Softwaremanagement Umgebung nur noch für die reine Verteilung im Unternehmen zu nutzen. Dies ist auch der Ansatz, den Microsoft mit seinem hauseigenen Produkt SCCM verfolgt. So sinnvoll diese Aussage auf den ersten Blick auch zu sein scheint, gibt es oft gute Gründe, die nativen Skript-Systeme der Hersteller einzusetzen.

Die UMTS Karten in HP Laptops (mein aktuelles Beispiel ist ein HP Elitebook 2540p mit einer Qualcomm un2420 Karte) haben einige Besonderheiten, die die Integration in DSM besonders erschweren.

• Das "unbekannte Gerät" im Gerätemanager hat eine andere Hardware-Id als das Gerät nach der manuellen Installation des Treibers. Dadurch kann nicht einfach der Treiber via DSM vom Gerät abegzogen werden, da dann im DSM Paket andere Hardware-Ids referenziert sind, als das "unknown device" auf einem frisch installierten Win7 Client hat.
• Das Gerät ist während der Installation eines Laptop ggfs. ausgeschaltet (Hardware-Schalter).
• Das Treiberpaket liegt nur als MSI File vor. Dieses MSI Setup lässt sich aber nur installieren, wenn das Gerät eingeschaltet ist.

Nun kann aber wie folgt vorgegangen werden, um dieses Device trotzdem sauber einzubinden:

Allgemein

Unter Windows XP mussten Anwendungen, die während der Laufzeit auf Windows Systemordner oder auf die LOCAL_MACHINE/Software-Bereiche der Registry schreibend zugegriffen haben, mit administrativen Rechten laufen. Alternativ musste der Zugriff auf den entsprechenden Ordner (meist der Programmordner) oder Registrykey mit schreibenden Rechten für die User ausgestattet werden.

In Windows 7 (streng genommen seit Windows Vista) existiert nun die Datei- und Registry Virtualisierung, die es ermöglicht auch solche schlecht programmierten Anwendungen (also Anwendungen die sich nicht nach MS-Entwicklungsrichtlinien richten) ohne Eingriff in die Berechtigungsverwaltung ans Laufen zu bringen. Realisiert wird dies über den Kernel-Mode Treiber luafv.sys.