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"...

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.

Nach dem Dokument zur Paket-Anforderung und den Paketierungschecklisten folgt nun das dritte Dokument in der Reihe der Packaging.Docs: Das Package Approval. Nachdem das die Applikation nun fertig für die Freigabe ist, muss eine inhaltliche Prüfung des Dokumentes erfolgen. Der Paketierer kann allzu häufig leider nicht sagen, ob die Anwendung jetzt korrekt paketiert ist oder nicht. Aus diesem Grund wird das Paket nun die Prozedur der Fachabnahme überführt. Diese Fachabnahme kann durch völlig verschiedene Personen erfolgen. Das kann der Endanwender sein der die Anwendung letztendlich nutzen soll, oder es kann sich um den Entwickler der Anwendung (oder einer abhängigen Anwendung) handeln, oder den IT-Verantwortlichen der Anwendung. Bei sehr grossen Projekten (SAP GUI) kann die Rolle der Fachabnahme auch auf mehrere Personen verteilt sein. Bei all diesen Personen ist das subjekte Empfinden über die Aussage "die Anwendung funktioniert" sicherlich völlig unterschiedlich. Abhilfe soll hier das Package Approval Document schaffen.

Es werden alle wichtigen Daten über die Anwendung abgefragt und darüber sichergestellt, dass die Testperson in einer Umgebung arbeitet, die dem tatsächlichen Einsatzort bestmöglich nachempfunden ist. Wie auch schon zuvor, wurde darauf geachtet, das eine weniger technisch versierte Person den WOrtlaut des Dokumentes versteht und in der Lage ist, ein Maximum der Informationen zu hinterlegen. Letztendlich wird über dieses Dokument am Schluss die Abnahme erteilt, worauf die Anwendung nun in den Rollout übergeben werden kann.

Als Viewer empfehle ich einen alternativen freien PDF Reader, da der Adobe Reader nicht in der Lage ist, ein PDF Formular inklusive seiner Formularinhalte zu speichern (Adobe setzt hier die Nutzung der kostenpflichtigen Vollversion voraus). Persönlich habe ich sehr gute Erfahrungen mit dem Foxit Reader gemacht.
Änderungswünsche, Positive Kritik aber auch Auswirkungen beim Einsatz dieser Liste sind mir immer als Anhang an diesem Blogeintrag oder als Mail sehr willkommen. Neuere Versionen werden ebenfalls in Rahmen dieses Blogeintrags veröffentlicht.

Die Liste als PDF kann im Donwload-Bereich unter PDF-Pool -> Services -> Paketabnahme heruntergeladen werden. Eine Anmeldung ist notwendig.

Oft bringen virtuelle Devices (wie z.B. Slysoft Clone Drive), manchmal aber auch grosse Hardwarehersteller einen Treiber mit, der so erst einmal nicht auf einem Windows 7 System installiert werden kann, da das verwendnete Zertifikat nicht bekannt ist. Um hier Abhilfe zu schaffen, kann dass im Treiber enthaltende Zertifikat in die lokalen Trusted Publisher eingetragen werden und anschliessend erst die Installation der eigentlich Software/Treiber gestarten werden. Um an das Zertifikat zu kommen und dieses silent auf das System zu bringen, sind folgende Schritte durchzuführen:

Oft werden Pakete in die Paketierung gegeben, für die der Paketierer weder technisches noch fachliches KnowHow besitzt. Um die Paketierungszeit auf ein möglichstes zu verringern, wird speziell in grösseren Unternehmen eine fachlich verantwortliche Person definiert, die dafür zuständig ist, die Anwendung im Unternehmen zu betreuen (2nd/3th-Level Support).
Diese fachlich verantwortliche Personen sind Experten in dem Bereich der Anwendung. Sie kennen die grundsätzliche Konfiguration der Anwendungen, die verwendeten Backendserver und welche Unternehmensbezogenen Erweiterungen notwendig sind.