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.

Funktionsumfang bekannter Packaging Technologien
Klassische Packaging Studios die im Endeffekt ein MSI-Paket erzeugen, implementieren im Grundsatz die Funktionen die zur Installation einer Software auf einem Computer wesentlich sind. Dazu gehört das Editieren der Registry, Kopieren von Dateien, Installieren von Diensten, usw. Darüber hinaus möchte der Designer eines Paketes aber vielleicht mehr, als nur eine Software auf ein System zu kopieren. Beispiele für solche Aufgaben können sein:

• Installation eines virtuellen Devices

• Installation eines Druckers

• Interaktion mit dem Benutzer (z.B. zum beenden eines Prozesses)

• Verwalten von Benutzerobjekten

• Aufbau einer Datenbankverbindung

• Publishen einer Anwendung auf einer XenApp Farm

• ... .

Je nach eingesetzter Lösung stehen aber solche Funktionen nicht zur Verfügung und müssen über zusätzliche Skripttechnologien eingebunden werden, was enormen Aufwand bedeutet. Die Hersteller großer Softwaremanagement Umgebungen haben aber zum Ziel, nicht nur Software zu verteilen, sondern Windows Systeme in allen Aspekten des Lebenszyklus eines Computers zu verwalten. Dies führt zu einer ständig wachsenden Anzahl von standardisierten Wizard-gestützten Befehlen für die Durchführung solcher Management Aufgaben.

Integrationsfähigkeit in die Softwaremanagement Umgebung

Eine Softwaremanagement Umgebung definiert die Randbedingungen eines Computers. So werden Standorte, Abteilungen, Partitionierungsdaten, Sprechsteuerung und viele Randparameter, die aus einem Standard-Windows ein spezielles Arbeitsgerät für diesen einen Benutzer machen, in der Datenbank des Softwaremanagement Systems abgelegt. Die Hersteller-eigenen Skript-Befehle können direkt mit diese Werten interagieren, das bedeutet, dass während der Skript Ausführung direkt auf diese Daten lesend und ggf. schreibend zugegriffen werden kann.

Sollen standardisierte Pakete/Skripte erstellt werden, müssen diese Werte über Kommandozeilenparameter übergeben werden. Zudem dürfen diese Variablen nicht direkt an den MSI Aufruf übergeben werden (da ja sonst wieder eine Abhängigkeit zur Softwaremanagement Suite entsteht), sondern müssen indirekt zur Verfügung gestellt werden, (z.B. über Systemvariablen auf dem Zielcomputer die über ein einem zentrales Paket zuvor definiert werden). Dies führt zu folgenden zusätzlichen Hürden:

• Erhöhter organisatorischer Aufwand in Form von Paketierungsvorgaben. Im Falle des Outsourcing der Paketierung, oder geografisch verteilter Packaging-Strukturen, müssen diese Eingabeparameter in Form eines Packaging Styleguides fix definiert werden. Dies erhöht die Komplexität des Design der Packaging Vorgaben und führt zu einer größeren Fehleranfälligkeit bei der Integration vorgefertigter Pakete in die bestehende Softwaremanagement Suite.

• Schachtelung von MSI Paketen. Mittlerweile liefern die meisten der Softwarehersteller Ihre Applikationen als MSI Pakete aus. Dieses verfügen i.d.R. aber nicht über die Eingabemöglichkeiten, die in einer speziellen Umgebung gefordert sind. Also wird ein neues MSI Paket geschnürt und das ursprüngliche MSI-Paket darin aufgerufen. Da aber auch schon die Hersteller selber oft zu diesem Kniff greifen um Ihre eigenen Systemvoraussetzungen zu erfüllen, wird diese Schachtelung immer tiefer, die Komplexität steigt.

• Verlust der Typsicherheit. Wird ein Datenwert in der Datenbank des Softwaremanagement Systems als Integer (Zahlen-) Wert abgelegt, wird dieser Wert auch bis zur Ausführung auf dem Zielcomputer als solcher behandelt. Wird der Wert über das Packaging System integriert, werden verwendeten Variablennamen als Drop-Down oder Wizard-gestützt angeboten. Beides reduziert die Fehleranfälligkeit und verbessert die Durchlaufzeit eines Paketes durch die Packaging Factory. Bei einer Übergabe aller Parameter mittels der Kommandozeile, geht diese Funktionalität verloren (alles wird als string übergeben), die Fehleranfälligkeit steigt.

Hoher Lernaufwand für allgemeingültige Skriptsprachen

Die integrierten Script-Befehle einer Softwaremanagement Suite sind darauf optimiert, die Komplexität möglichst zu reduzieren. Ein Befehl wird per Drag and Drop erzeugt, befüllt wird er per Wizard. Die Erstellung eines Paketes mit einer integrierten Skriptsprache kann innerhalb von 3 Tagen vermittelt werden. Tiefgreifendes Know-How in Powershell erfordert zwischen 1-3 Wochen, je nach bestehenden Know-How des Mitarbeiters in objektorientierten Systemen.

Ein „Copy“ ist mehr als das kopieren von Dateien

Der Befehl zum kopieren einer Dateien ist deutlich mehr, als nur dass eigentliche kopieren der Datei. Um dies zu verdeutlichen sind folgend die Fragen aufgelistet, die beachtet werden müssen, um eine einzelne Datei via Scriptsprache gesichert auf ein Windows System zu kopieren:

• ist die Zieldatei schon vorhanden?

• Soll die Zieldatei überschrieben werden?
  Soll die Versionsnummer und der Zeitstempel der Zieldatei vor überschreiben geprüft werden (Nur ältere Dateien überschreiben)?

• Soll die ursprüngliche Datei gesichert werden?

• Wie kann eine Datei überschrieben werden, die aufgrund eines offenen Prozesses blockiert ist?

• Muss ein Reboot ausgelöst werden, damit die Datei ggf. während des Reboots ausgetauscht wird (Systemdateien)?

• Handelt es sich um eine .NET Datei wo eine einfache Kopie nicht ausreicht, sondern die Registrierung im System notwendig wird (Assembly Cache)?

• Muss die UAC (= User Account Control, Sicherheitssystem das illegale Dateioperationen in administrativen Bereichen verhindert) benachrichtigt werden?

• Das Ergebnis der Operation muss für die Fehleranalyse in Form von Log-Dateien oder Datenbankeinträgen festgehalten werden.

Dieses einfaches Beispiel beschreibt sehr gut die Komplexität des Vorgangs. Die Hersteller von Softwaremanagement Umgebungen kümmern sich in Ihren spezifischen Skript-Befehlen genau um diese Dinge. Im Falle der Implementierung über eine allgemeine Skriptsprache, muss sich der Paketentwickler selber um die Aufgaben kümmern. Nicht selten entstehen auf diesem Wege sehr spezifische Skriptarchitekturen. Es wird nach und nach ein eigenes Packaging Studio geschaffen.

Auch die NWC-Services stellt für die Entkoppelung von Paket- und Infrastruktur entsprechende Powershell basierte CmdLet's (Scriptabschnitte, die jeweils exakte Aufgabe erledigen) zur Verfügung, die eine Teil der Packaging Workbench von DSM 7 abbilden.

Integrationsfähigkeit in Drittsysteme

Ein Softwaremanagement Umgebung ist mehr als nur eine Infrastruktur, die Pakete zur Verfügung stellt. Vielmehr bieten Sie eine einheitliche Schnittstelle für den Zugriff auf verschiedene Subsysteme. Eigenschaften des AD's, zusätzlicher Datenquellen wie Datenbanken oder Textdateien, oder Systemvariablen werden zentral in einheitlicher Form zur Verfügung gestellt. Der Zugriff auf diese Werte erfolgt über die integrierte Skriptsprache. Bei der Nutzung einer allgemeinen Skriptsprache müssen all diese Integrationen zusätzlich entwickelt werden. Auch dies führt nach und nach zum Aufbau einer eigenen, sehr spezifischen Skriptarchitektur.

Nachbau neuer Betriebssystemtechnologien

Werden neue Sicherheitssysteme in die zugrunde liegende Betriebssystemarchitektur integriert, müssen dies ggf. speziell behandelt werden. Ein gutes Beispiel hierfür ist die zuvor genannte UAC die mit Windows Vista eingeführt wurde. Im Falle eigener Skripte/ Pakete müssen diese alle auf die Funktionalität mit dieser neuen Technologie geprüft werden. Die Hersteller von Softwaremanagement Umgebungen führen aber genau dies mit jedem einzelnen Befehle Ihrer nativen Skriptsprachen ebenfalls durch und liefern meist schon zum Release des neuen Betriebssystems auch die entsprechende Unterstützung.

Updates von Anwendungen

Um mit einem klassischen Beispiel zu arbeiten, soll eine Aussage zitiert werden, die immer im Rahmen von Softwaremanagement Projekten zu hören ist: „Adobe Reader ist eine ganz einfache Anwendung, die haben wir in einem Tag integriert.“

Spontan ist man geneigt, dieser Aussage zuzustimmen, aber im Rahmen des Projektes stellt sich nach einiger Zeit nach und nach heraus:

• Es müssen zusätzliche Fonts integriert werden.

• Es wird ein alternativer PDF Editor eingesetzt, die Dateiverknüpfungen müssen nun passend verwaltet werden (Was geht auf, beim Doppelklick auf eine PDF Datei).

• Es müssen Sicherheitspatches eingespielt werden.

• Es existieren Formulare, die spezielle Adobe Reader Versionen voraussetzen.

Plötzlich liegt der Aufwand nicht mehr bei 1 Tag sondern bei 3-5 Personentagen (inklusive Test und Dokumentation). Ein Skript, was ursprünglich mal aus dem Aufruf eines einzelnen MSI Setups bestand, implementiert nun eine komplexe Logik zur Installation des richtigen Adobe Reader unter Berücksichtigung aller Randparameter. Jeder der oben genannten Punkte kann mit integrierten Mitteln einer Softwaremanagement Lösung wie DSM 7 gelöst werden.

• Fonts werden mit einem Befehl zur Installation von Schriften integriert.

• Dateiverknüpfungen werden mit einem Registry-Befehl passend gesetzt.

• Ein Sicherheitspatch wird mit einem passenden Befehl einfach integriert.

• Eine ältere Version des Adobe Reader kann direkt aus dem Paket heraus aufgerufen werden.

• Jede Änderung wird in einer dedizierten Revision abgelegt und dabei explizit dokumentiert.

Wird dies im Gegensatz dazu mit MSI Paketen implementiert, muss für jede Änderung ein neues MSI Paket generiert und ausgerollt werden. Dabei muss überlegt werden, wie mit den verschiedenen Schritten umgegangen wird. Wird je MSI Paket pro Änderung gebaut oder das vorhandene Paket immer wieder erweitert? Wie wird dann die Revisionssicherheit hergestellt? Vielleicht brauche ich ja noch die Vorgängerversion der Anwendung?

Die Dokumentation muss außerhalb des Paketes liegen, da MSI hierfür keine ausreichende Unterstützung bietet. Die Abbildung mit einer reinen Skripttechnologie bringt, wie schon zuvor erwähnt, die Notwendigkeit mit sich, vollständige Verfahren für jeden der einzelnen Punkte in einer eigenen spezifischen Skriptarchitektur aufzubauen.

Wie speziell ist eine Native Skriptumgebung eigentlich?

Es kann festgehalten werden, dass in einem durchschnittlichen Softwaremanagement Projekt mind. 60% aller Windows-basierten Software auf MSI basiert. Von diesen 60% funktioniert ca. die Hälfte der Setups, ohne dass extreme Modifikationen notwendig sind. Diese Softwareanwendungen werden genauso als MSI Setup auf dem Zielclient aufgerufen, wie Sie der Hersteller der Software ausliefert. Soll ein Vergleich des Aufwandes zwischen der Nutzung einer nativen Skriptumgebung und einer allgemeinen Lösung gezogen werden, dürfen diese Softwareanwendungen nicht mit einbezogen werden.

Paketierungsaufwand vs. Migrationsaufwand

Nach alle diesen Punkten stellt sich nun die Frage, lohnt sich der Aufwand für die Standardisierung von Paketen in eine einheitliche Technologie?

Der Aufwand für die Paketierung eines einzelnen Paketes mittels MSI/VBScript/ PSX Technologie ist faktisch deutlich höher, als die Nutzung einer nativen Skriptsprache die speziell für die Softwareverteilung entwickelt wurde.

Dies begründet sich in...

• ...dem geringeren Funktionsumfang (MSI)...

• …der fehlenden Integrationsfähigkeit (MSI) ...

• ...dem größeren Lernaufwand (MSI, VBScript/PS)...

• ...höheren Aufwands für die Integration von Standardaufgaben (VBScript/PS) …

• … der ständigen notwendigen Pflege der eigenen Skripte aufgrund neuer Basis (Windows) Technologien (VBScript/PS)...

• … der geforderten höheren Disziplin, eine vollständige Entkoppelung der Technologien zu erreichen (MSI, VBScript/PS)...

...bei Standard Methoden zur Erstellung von Paketen. Dem gegenüber steht der erhöhte Aufwand bei der Migration von Paketen, von einer nativen Skriptsprache in eine andere oder in eine Standardtechnologie.

Um die Aufwände zu verdeutlichen, wurden diese folgend in einer Bewertungsmatrix gegenübergestellt. Jeder einzelne Punkt wurde in einer Skala von 1-3 (1 niedriger Aufwand, 3 hoher Aufwand) bewertet, woraus sich ein Gesamtsumme in Form von Aufwandspunkten errechnet.

Diese Tabelle begründet sich auf Projekterfahrungen der letzten 10 Jahre verschiedener Consulting Einsätze und Mitarbeiter der NWC-Services vom Mittelstand bis hin zum Enterprise Umfeld. Diese Bewertungsmatrix soll keinen Marktstandard definieren und wird sicher von einem Kundenszenario zum andern immer etwas abweichen. Sie zeigt aber sehr gut die verschiedenen zu erwartenden Aufwende und gibt einen ersten Eindruck darüber, wie die Aufwende für die Umstellung zu einem allgemeinen Paketierungsverfahren den Aufwenden im Falle einer Migration der Softwaremanagement Anwendung gegenübergestellt werden können.

Fazit

Ein allgemeingültige Aussage zum Kosten/Nutzen Faktor für die Standardisierung der Packaging Technologie lässt sich weder in die eine, noch in die andere Richtung pauschal festlegen. Die vorstehenden Ausführungen zeigen, dass eben pauschalisierte Aussagen wie

„die Standardisierung der Packaging Technologie bietet die Möglichkeit

• ...zum schnellen Wechsel der Softwaremanagement Infrastruktur

• …zum problemlosen Outsourcing der Packaging Factory“

...nicht haltbar sind. Native Skripttechnologien haben nach wie vor Ihre Berechtigung, unterstützen die Paketierung bei der Lieferung schneller Ergebnisse und sorgen für deutlich höhere Qualität bei der Installation von Softwareanwendungen.

Die Überlegungen zur Umstellung auf eine standardisierte Skriptsprache/ Technologie sollten, wenn dann nur bei der Einführung einer Softwaremanagement Lösung stattfinden. Ist einmal eine vollständige Softwaremanagement Struktur vorhanden, ist deren Umbau auf eine standardisierte Lösung zu kostenintensiv um sicherzustellen, dass diese Ausgaben durch die Einsparungen bei einer Migration wieder gedeckt werden.