Vor einiger Zeit habe ich Checklisten (siehe Paketier-Anforderung, Paketierungsrichtlinien und Paketabnahme) veröffentlicht, die beim Prozess der Paketierung unterstützen sollen.

Nach und nach häufen sich aufgrund des Artikels einige zusätzliche Fragen in meinem Notizbuch, denen ich im Folgenden nachkommen will. Ich möchte erst auf einige allgemeine Fragen eingehen, um dann konkrete und sehr technische Details zu beschreiben.

Allgemeingültige Anmerkungen/ Fragen

Wie viel Zeit verwende ich auf die reine Paketierung?

Grundsätzlich ist es schwer, eine verlässliche Aussage zu treffen. Die Zeiten für die Paketierung liegen bei 1-2 Stunden für einfache Pakete wie 7-Zip bis hin zu mehreren Wochen für komplexe Anwendungen. Die Komplexität liegt dabei selten in den technischen Details der Anwendung, sondern vielmehr in der Vielfalt der Konfigurationseinstellungen. Aber auch Anwendungen, die vom ersten Gefühl her relativ einfach erscheinen, können sich zu wahren Zeitfressern entwickeln. Ein Beispiel ist der Adobe Reader, der zusammen mit einem weiteren PDF Editor (z.B. Nuance) auf einem System betrieben werden soll. Dann müssen Paketübergreifende Dinge wie die Verknüpfung von Dateien mit  behandelt werden. Speziell bei Adobe Reader sind zudem die häufigen Updates eine Ursache für gesteigerte Aufwände/Feheinschätzungen bei der Paketierung. 

Paketieren ist zudem Erfahrungssache und erfordert Zeit und Übung. Am Anfang sollte mit ca. 1 Paket alle 2 Tage gerechnet werden (für leichte bis mittelschwere Pakete). Dieser Durchsatz wird sich für Standard Pakete bei ca 1 PT einpendeln, wenn die reine Zeit der Paketierung berücksichtigt wird. Diese Abschätzung beinhaltet die Installation, Reperatur- und Deinstallationlogik von Paketen. Weiterhin ist hier nur die reine Zeit für die teschnische Implemnetierung gerechnet. Weitere Aufwände entstehen durch Paketvorbereitung, Reviews und Fachabnahme.  

Lohnt sich das outsourcing der Paketierung?

Ein Paket ist immer abhängig von seiner Infrastruktur. Ein Paket wird immer Variablen oder Informationen aus seiner Softwaremanagement Umgebung nutzen. Dies gilt sowohl für die technische Umgebung, als auch das menschliche / kollegiale / organisatorische Umfeld. Dies macht das Outsourcing (im Sinne der Paketierung außerhalb der Softwaremangement Umgebung) der Paketierung schwierig. Die Erfahrung zeigt, dass die dabei entstehenden Reibungseffekte das Einsparpotenzial nicht wettmachen. Folgende Dinge sollten berücksichtigt werden:

• Die Pakete werden nicht optimal in die Infrastruktur integriert.
• Es muss viel mehr Arbeit in die schriftliche Standardisierung und Beschreibung der Umgebung gesteckt werden um die Übergabe nach extern und wieder zurück in den Griff zu bekommen.
• Der Aufwand für die Qualitätssicherung steigt. Viel öfters als bei einer Inhouse Paketierung, stimmen die Pakete nicht mit den persönlichen Erwartungen überein. Die Folge: Häufiges hin-und-her-Senden der Pakete, oder die gewünschte Änderung wird letztendlich doch Inhouse eingebaut.
• Outsourcing werden durchgeführt gemacht, um Geld zu sparen. Dies erhöht natürlich den Reiz, die Paketierung in Niedriglohnländer zu verlegen. Leider wird dabei oft vergessen (viel zu oft auch auch ignoriert), dass sprachliche und kulturelle Barrieren durchaus messbare (und somit in Währung quantifizierbare) Aufwände erzeugen.

Wie viel bringt mir externe Unterstützung?

Unter der Voraussetzung, dass Ihr externer Dienstleister ins Haus kommt und langjährige Erfahrungen in der Paketierung mitbringt, ist i.d.R. mit maximal 1 Tag zusätzlicher Einarbeitungszeit zu rechnen. Dies gilt natürlich nur unter der Voraussetzung dass grundlegende Dinge, wie Zugang zum Haus und der Infrastruktur, Schreibtisch, Telefon, Ansprechpartner, Sourcen, Lizenzen, Paketiererarbeitsplätze, etc. geklärt sind.

Kann ich mit der Nutzung einer allgemeingültigen Technologie, eine Unabhängigkeit vom Softwaremanagement System erreichen?

Grundsätzlich kann mit der Repaketierung aller meiner Anwendungen in reines MSI/Virtualisierungsformat diese Unabhängigkeit nicht erreicht werden. Oft werden Informationen der Infrastruktur oder Datenbank des Softwaremanagementsystems direkt in Paketen verwendet und Abhängkeiten zwischen Paketen implementiert, die ausserhalb der Pakete abgebildet sind. Die Abhängigkeit zum eingesetzten System kann also bestenfalls reduziert, aber sicher nicht gelöst werden. Aufgrund des hohen Interesses zu diesem Thema, ist eine detaillierte Auseindersetzung hier nachzulesen.

Paketierung / best practices

In letzter Zeit habe ich mich fast bei jedem Kunden intensiv damit beschäftigt zu erläutern, wie Pakete aufgebaut werden müssen, um einen optimalen ROI zu erreichen. Leider war auch ein nicht ganz unbedeutender Teil Unternehmen darunter, deren Pakete fast vollständig neu geschrieben / überarbeitet werden mussten.

Das Ergebnis einer "unsauberen" Paketierung ist Frust, fehlendes Verständnis über Abläufe am Client und letztendlich das Gefühl, mit DSM eine falsche Produktwahl getroffen zu haben. Alles Dinge, die mit ein paar recht einfachen Kniffen hätten vermieden werden können. Also stellen wir die Kernfrage: was will ich mit meinen Paketen erreichen?

1) Anwendungen sollen installiert werden.
2) Anwendungen müssen aus Gründen der Compliance-Einhaltung und des Lizenzmanagement deinstalliert werden können.
3) Für den besseren Support der End-Kunden müssen Anwendungen reinstalliert / repariert werden.

Grundsätzlich sind (aktuell) 5 verschiedene Arten von Paketen zu betrachten:

• Virtualisierte Applikationspakete
• Spy Pakete
• MSI Pakete
• Silent Setup Pakete
• Treiber Pakete

Und welchen Pakettyp nehme ich wann?

Grundsätzlich ist es schon alleine aus Gründen des Supports empfehlenswert, die Hersteller-eigene Setup Routine zu verwenden. Liegt diese im MSI Format vor, wird ein MSI Paket gebaut, liegt eine Setup.exe vor, sollte untersucht werden, ob diese ein MSI Setup enthält, welches entpackt werden kann. Oft können die Setup Routinen auch mit 7Zip entpackt werden. Erst wenn das Original-Setup keine Silent parameter zur Verfügung stellt, oder dieses Silent Setup Fehler erzeugt (beispielsweise ist in Einzelfällen die Installation per Service im Hintergrund nicht möglich), wird auf den Spy zurückgegriffen.

Für alle Pakettypen gelten annähernd die Einstellungen, die in der Packaging-Checkliste beschrieben sind.

Virtualisierung

Virtualisierte Pakete will ich an dieser Stelle nicht intensiv behandeln. Ein Grossteil der Logik befindet sich dabei im virtuellen Paket, die Interaktion mit dem Softwaremanagement System beschränkt sich häufig nur auf den Transport der Massendaten und das Anlegen von Links. Zu gegebener Zeit, werde ich einmal in einem eigenen Blog Eintrag darauf zurückkommen.

Spy Pakete

Spy (oder Snapshot) haben (meiner Meinung nach völlig zu unrecht) einen recht schlechten Ruf. Oft höre ich Aussagen wie "Ich richte mich lieber nach der Setup Routine des Herstellers" oder "Bei einem Spy werden mir zuviel unnütze Daten auf die Maschine kopiert". Bei einem Spy gelten folgende Dinge, an die ich mich als Paketierer unbedingt halten sollte:

• Ein Spy wird immer auf einem frisch installierten Minimal-System vorgenommen. "Minimal" bedeutet an dieser Stelle, dass im Idealfall nur das OS und alle voraussetzenden Anwendungen installiert sind. Alle Voraussetzungen werden wiederum mit DSM installiert. Es sollte weder ein Virenscanner noch ein Spyware Scanner installiert sein.
• Als Arbeitsstation wird immer die "am meisten genutzte" Plattform verwendet. I.d.R. kann ein Spy auf einem Windows 7 x64 System aufgezeichnet werden und auf einem Windows Server 2008 R2 (z.B. für den Einsatz in einer Terminal Server Farm) installiert werden. Selbst ein auf einem x86 System erstellter Spy, funktioniert meistens mit keinen oder sehr wenig Modifikationen in einer x64 Umgebung.
• Die Registry Einträge, die mit dem Spy aufgenommen wurden, müssen explizit für die Deinstallation- und Reparatur markiert werden. Dabei sollte natürlich auch nur die Zweige markiert werden, die auch zu der jeweiligen Anwendung gehören.
• Alle Dateien und Registry-Einträge, die nicht zur Anwendung gehören, werden sowohl im Script, im Paketverzeichnis und in den NIR Dateien entfernt. Dieser Aufwand bleibt sehr überschaubar, wenn - wie im ersten Punkt beschrieben - auf einem Minimal-System paketiert wird.

Hält man sich als Paketierer an diese Vorgaben, spricht überhaupt nichts gegen die Nutzung des Spy. Die Reinstallation eines Spy Pakets ohne weitgehende Modifikation ist direkt gegeben, ebenso kann DSM alle im Spy verwendeten Befehle negieren, um das betroffene Paket zu deinstallieren. Werden weitere Befehle verwendet, können diese ohne weiteren Aufwand in der $BeginUninstallScript Sektion explizit verwendet werden.

Im Falle einer Deinstallation wird erst im Install-Teil des Scriptes versucht, alle Befehle zu negieren. If-Abfragen werden dabei ignoriert, sofern nicht die Abfrage auf den InstallMode verwendet wird. So kann verhindert werden, dass Befehle im Falle einer Deinstallation negiert werden, indem auf "CheckInstallMode(ImUninstall)" geprüft wird. Im Anschluss wird die Uninstall-Script Sektion abgearbeitet.

Folgende DSM Befehle können durch den Installer automatisch negiert werden:

• Copy -> Delete
• CopyFileList -> DeleteFileList
• InstallFile -> DeleteFileList
• InstalliFileList -> DeleteFileList
• InstallAssembly -> UninstallAssembly
• MakeDir -> RemoveDir
• CreateFolder -> RemoveFolder
• CreateLink -> RemoveLink
• InstallService -> UninstallService
• MSIInstallProduct -> MSIUninstallProduct
• AddPrinterConnection -> RemovePrinterConnection
• RegLoad -> Nimmt Registry Werte automatisch wieder zurück, wenn diese entsprechend markiert sind.

MSI Pakete

Grundsätzlich ist es ausreichend, das MSI Paket mit Hilfe des Wizard in ein DSM Paket aufzunehmen. Dabei kann das administrative Setup genutzt werden, wenn der Hersteller entsprechende Optionen darin verbaut hat. Sollen Teile des MSI Paketes aus der Softwaremanagemenet Infrasktuktur gesteuert werden, sind diese mit Hilfe von eScript Befehlen zu steuern. Es kann zudem mit unterschiedlichen Transforms und MSI Parametern gearbeitet werden.

Werden weitere eScript Befehle in den Paketen verwendet, werden diese im Falle eines Uninstalls wie im normalen Spy Paket behandelt. Für den Repair eines MSI-basierten Befehls sind normalerweise ebenfalls keine besonderen Aktionen notwendig, da MSI selber die Reperatur einer Anwendung unterstützt und DSM den Repair-Mode an das zugrundeliegende MSI Paket weiterreicht.

Silent Setup

Im Falle eines Silent-Setups sind alle Modi explizit zu behandeln. Folgend ist ein Beispielscript für die Behandlung eines Silent-Setups mit Installation-, Repair und Deinstallation aufgezeigt.

If CheckInstallMode(imReinstall) or CheckInstallMode(imAppRepair)

!- Wenn die setup Routine einen Repair Modus hat, ist der Aufruf der Installation des programms
!- nicht mehr notnwendig. Die Integration der folgenden IF Abfrage ist also von Fall zu Fall zu entscheiden.
If CheckInstallMode(imWkStaPart)

: $BeginUninstallScript
ExecuteEx('.\extern$\setup.exe -uninstall','_return','10')/?
If not %_return%='0'
  ExitProcEx(Failed,'Uninstall failed with returncode %_return%.')

Mit diesem Script steht das Grundgerüst einer Silent-Setup Routine. Der Returncode jedes Executables wird überprüft und das Script mit einem Fehler verlassen. Über CheckInstallMode wird der jeweilige Installationsmodus abegfragt. Stellt die Hersteller-eigene Setuproutine einen Repair-Modus zur Verfügung, wird dieser genutzt und vor dem Install-Teil der Anwendung geprüft, ob der normale Installationsmodus aktiv ist. Stellt das Original Setup keinen Repair-Modus zur Verfügung, wird das Paket in einem Schritt deinstalliert und sofort wieder installiert. 

Treiber

Für die Paketierung von Treibern existieren verschiedene Ansätze. Treiber können aus dem Windows System extrahiert werden, das seitens des Herstellers auf einem Computer vorinstalliert ist. Oft sind diese Treiber allerdings veraltet. Möchte ich exakt diese Plattform verteilen, ist dieser Ansatz aber der Weg des geringsten Widerstandes.

Alternativ bieten sich die Treiber von den Websiten der Hersteller an. Dies kann sowohl der Hersteller des Systems als solches sein (Dell, HP, Fujitsu, Lenovo,...) oder der Hersteller des einzelnen Devices (Intel, Broadcom, ATI,...). Letztendlich werden alle PnP Geräte mit den entsprechenden DSM-Wizards erstellt.

Hardwarenahe Software (z.B. zum Steuern der Bluetooth Funktionalität) wird als normales Softwarepaket zur Verfügung gestellt. Bei ziemlich allen Treibern und hardwarenahen Paketen ist es wichtig, dass die Installation der benutzerbezogenen Teile deaktiviert wird. 

Historie:

2012-11-08 Generelle Überarbeitung