Der Installation Wrapper

eine oft unterschätzte Komponente.

Flowchart - Installation Wrapper

Oft kann man eine einfache einzelne Befehlszeile verwenden, um eine Anwendung unbeaufsichtigt (automatisiert) zu installieren. Um z.B. 7-Zip mit einer grundlegenden msiexec-Benutzeroberfläche (UI) zu installieren, verwenden wir den Aufruf msiexec /i 7z920-x64.msi ALLUSERS=1 /norestart /qb!. Diese Befehlszeile wird in der Regel in Ihr Softwareverteilungswerkzeug (SCCM, Ivanti, etc.) eingefügt, um die Software auf Ihrem Windows-Client bereitzustellen. Was aber, wenn

  • Ihre unbeaufsichtigte Installation aus mehreren Abhängigkeiten besteht?
  • Vor und / oder nach der Installation noch weitere Aktionen notwendig sind?

Ein Installation-Wrapper ist bildlich vergleichbar mit einem (Brief-)Umschlag, das mit den notwendigen Parametern der Installation beschriftet ist. Die Installation (besser: die Sourcen) befinden sich im Umschlag. Die Sourcen selbst können entweder MSI, MSP, EXE, Skripte oder einzelne Dateien beinhalten. Der „Umschlag“ wird im Deployment-Tool (SCCM, DSM, u.a.) aufgerufen und dieser kümmert sich um die eigentliche Installation.

Ein Installations-Wrapper kann unter Verwendung einer beliebigen Skript- oder Programmiersprache erstellt werden. Das Ziel besteht im Allgemeinen darin, sicherzustellen, dass die Anwendung vollständig (und robust) auf dem Zielcomputer unbeaufsichtigt installiert werden kann. Bitte beachten Sie, dass ich das Wort "silent" in dieser Hinsicht nicht verwende; viele Softwarepaketierer verwenden die Wörter still (silent) und unbeaufsichtigt (unattended) in Bezug auf Anwendungsinstallationen. Dies kann verwirrend sein, da einige Switch-Implementierungen nur die Installation vollständig automatisieren, d.h. zwar unbeaufsichtigt (unattended) doch nicht immer unsichtbar (silent).

Durch Parametrisierung (call by [name][value][result]) können Installations-Wrapper in ihrer Anwendung flexibilisiert werden, ohne dass ein anderer erweiterte Skripting-Kenntnisse haben muss (Steuerdatei (.ini)). Welche Werte eingestellt werden können, muss bei der Erstellung von Installations-Wrappern festgelegt werden. Begrifflich wird unterschieden zwischen „formalen Parametern“ (= als Teil der Funktionsdefinition im Programmcode; Bsp.: ‹Funktionsname›(‹Par1›, ‹Par2›, ..)) und „tatsächlichen Parametern“, auch „Argumente“ genannt (= der jeweilige Wert für ‹Par1› oder ‹Par2› bei einzelnen Funktionsaufrufen).

Zusammengefasst ist ein Installations-Wrapper ein Programm oder Skript mit zusätzlicher programmierter Logik, einschließlich zusätzlicher Skriptaufgaben wie Datei- oder Registrierungsvorgängen.
Der Nachteil von Installation-Wrappern ist, dass je komplexer die Anwendungsanforderungen und Installationsphasen werden, desto geschickter der Software-Paketierer sein muss. Und das kann ein Problem werden, falls dieser nicht über die erforderlichen Fähigkeiten verfügt.

Anforderungen (Merkmale) eines Installations-Wrapper

Ein Installations-Wrapper sollte alle notwendigen Aktionen ausführen können, die ein Software-Verteilungstool nicht oder mit viel Aufwand erledigen kann. Andere Anwendungen oder Runtimes, die in direkter Abhängigkeit zur Anwendung selbst stehen, werden weiterhin mit dem Software Verteilungstool (i.S. Task-Sequenz) gehandled und nicht über einen Installations-Wrapper.

  • eine Pre- und/oder Postinstallation sind vorbereitende oder abschliessende Installationsabschnitte. So kann man Dienste oder Anwendungen vor der eigentlichen Installation aus- und einschalten oder etwas komplexer betrachtet, ein ActiveSetup vorbereiten (muss ja nicht immer ein MSI sein).
  • ein „einfaches“ Log schreiben: Eine komplexe Installation kann ohne weiteres ein Log in einer Grösse von 50 MB oder mehr schreiben. Ausschlaggebend ist lediglich nur eine einzige Zeile. Wenn die Installation fehlgeschlagen ist, erhalte ich einen Error-Code grösser 0.
  • Fehlercodes abfangen: unter „Best Practise“ versteht man, dass z.B. ein Neustart des Systems nach einer (De-)Installation grundsätzlich abgefangen wird (3010,1641 → 0). Manche eingesetzte Tools haben andere Returncodes als 0 (z.B. RoboCopy). Manchmal läuft einfach auch etwas schief (Syntax-, Parameterfehler, Permissions, abwesene Abhängigkeiten o.ä. (z.B. 1642 in Bezug mit SC).
    Man sollte unbedingt vermeiden, den Error-Code im Installations Wrapper abschliessend auf 0 zu setzen; als letzte Zeile im Code sozusagen.

Mögliche Konflikte bei "erfolgreichen" Installationen

Ein Konflikt kann eine Wechselwirkung zwischen verschiedenen Anwendungen verursachen und/oder die (De-)Installation der Anwendung verhindern. Beispiele:

  • Bei der Installation eines (auch PDF-) Druckers darf der Spooler-Dienst nicht aktiv sein. Der „neue“ Drucker darf sich nicht als Standard-Drucker einrichten.
  • Wenn mit einer Namensendung (Extension) einer Datei mehrere Anwendungen verbunden sind, dann kann nur eine von ihnen als Standard dienen. Gibt es keine zentrale Verwaltung per Group Policy Preferences (GPP), muss die Installation dies berücksichtigen.
  • Identischer PackageCode in unterschiedlichen MSIs führt zu unerwarteten Ergebnissen. Im „Idealfall“ bricht die Installation mit dem ErrorCode 1638 ab, doch unter Umständen kann man zwei oder mehrere MSI/MST mit demselben PackageCode fehlerfrei installieren. Sobald eines der betroffenen MSI jedoch aktuallisiert (update) wird, ist man zwangsläufig (eben zu einem anderen Zeitpunkt) mit dem Error 1638 konfrontiert.
  • Zwei oder mehrere Anwendungen „teilen" sich dieselben Resourcen, diese befinden sich aber an verschiedenen Orten oder es gibt Versionsunterschiede.

Man erhält unter Umständen eine fehlerfreie Installation, aber andere Anwendungen werden sich „etwas seltsam“ verhalten.