Repaketier NIE ein Windows Installer Setup!

Melchior Joined: 29 May 2006 Posts: 29

Repaketier NIE ein Windows Installer Setup!
Für den Softwareverteilungsprozess geltende „Best practice“ Ansätze und Richtlinien im Handling von MSI-Dateien.

Kaum haben wir uns an das Repackaging gewohnt, werden wir nun vor allem durch die Verbreitung von Hersteller-Setups basierend auf Windows Installer Technologie vermehrt gezwungen, andere Mechanismen zur Paketerstellung zu verwenden. Dass es sich dabei nicht zwingend um unangenehme Paketiermechanismen handelt, soll hier aufgezeigt werden. Daneben werden wir auch verstehen lernen, warum es so immens wichtig ist, dass Herstellersetups, die die Windows Installer Technologie verwenden möglichst nicht aufgezeichnet werden sollten.

Im Paketier- und Verteilungsprozess gibt es verschiedene Ansätze zur effizienten Paketerstellung in Unternehmen, wovon aber nur drei wirklich sicheren Einsatz versprechen:

(über unattended Scripting Tools (autom. Steuerung der Dialogboxeingaben)) -> Nicht empfohlen
durch Parametrisierungen von Originalsetups
durch Snapshottechniken erstellte Setups
durch Customizing von Windows Installer Setups

Natürlich erlaubt uns das Repackaging ein einfaches und meist schnelles Erstellen von Setups mit benutzerdefiniertem Verhalten. Es darf aber nicht vergessen werden, dass ein repaketiertes Setup eine komplett andere Logik, als das Herstellersetup aufweist und auch nur eine eingefrorene Zustandsänderung von Registrykeys, Dateien, Services, etc. beinhaltet.
Windows Installer Setups sind meist viel komplexer aufgebaut, als dass sie nur eine Summe dieser besagten Ressourcen bilden würden.

Folgende Gründe sprechen dagegen, dass man Windows Installer Setups repaketiert (aufzeichnet):

CustomActions des Herstellers würden nicht auf dem zu installierenden Client zur Anwendung kommen.
Conditions und Abhängigkeiten würden durch das repaketierte Setup nicht geprüft.
Eine über Erweiterungen im MSI implementierte Installationslogik, wie sie vom Hersteller vorgesehen sein könnte, würde ignoriert.
Nur Installationsänderungen kämen zum tragen. Für Upgrades, Updates und Deinstallation würden die vom Entwickler erarbeitete und vorgesehene Installationsabfolge ignoriert. (Ein Snapshot zeichnet nur Installationsveränderungen auf.)
Zukünftige Herstellerpatches könnten nicht originalgetreu angewendet werden.
Anderes Verhalten bei einer Deinstallation aufgrund Verwendung neuer ComponentIds (GUID) im repaketierten Setup.
Das Zusammenspiel der Applikation mit eigenen Features oder mit anderen Elementen seines Windows Installer Setups funktioniert während dem Betrieb (nach der Installation) nicht mehr (Beispiel Acrobat Reader: „Open PDF in Browser“)
(Gefahr, dass Informationen des zum Aufzeichnungszeitpunkt aktuell angemeldeten Users, des Clientzustandes, der Zeit, der Netzwerkeinstellung, der Hardwareausstattung, etc. fix in das repaketierte Setup aufgenommen werden und dass diese Informationen auf einem anderen Client zu einer anderen Zeit und mit einer anderen Konfiguration zu fehlerhaften Auswirkungen führt. (Dieses Risiko besteht bei jeder repaketierten Software, nicht nur bei aufgezeichneten Windows Installer Setups))

Nun, was steht uns als Alternative zur Auswahl? Wir customizen MSI-Setups! Immer! Sofern es möglich ist. Dies wird üblicherweise über Transformationen erledigt, da viele Produkthersteller ein direktes Bearbeiten ihrer Setup MSI Dateien nicht unterstützen und so den Support verweigern würden. Daneben erlauben so erstellte MST-Dateien ein einfaches Erkennen und Manipulieren der eigenen Änderungen.

Je nach Aufgabestellung bieten sich unterschiedliche Verfahren zur Erstellung der MST Datei an. Wenn Eingabeoptionen über Dialogfelder konfiguriert werden müssen, so empfiehlt sich der Einsatz von Tools namhafter MSI Authoring Softwares wie InstallTuner (macrovision) oder InstallTailor (Wise Package Studio).

Das direkte „Customizing an der Substanz“ lässt sich durch folgendes Verfahren bewerkstelligen:

Erstellen einer Kopie des Hersteller Setups.
Direktmodifikationen in den Tabellen mit ORCA (Microsoft Windows Installer SDK) an der Kopie erstellen.
Transformation durch Differenz zweier MSIs über MsiTrans.exe (Microsoft Windows Installer SDK). Beispiel: MsiTrans.exe –g <basedb> <newdb> <transform> oder durch andere Tools.

Was für Hauptaufgaben fallen alle unter den Begriff Customizing?

Featureselektion/deselektion
Konfiguration von Properties (die sonst durch Dialoge gesetzt würden)
Implementation eigener CustomActions für zu erledigende zusätzliche
betriebsspezifische Aufgaben und für die Konfiguration des Produktes.
Andere benutzerdefinierte Veränderungen, wie Löschen von Shortcuts, Umbenennen oder Verschieben von Shortcuts, eigene Propertys, etc..
Abändern des Setups, damit es sich für den Direktaufruf im Silentmode eignet.

Vorgehen in der Praxis:

Bootstrapper: Analysieren Sie jedes Setup! Auch Setup.exe’s! Wird ein Bootstrapper oder Setup Launcher verwendet, welcher „im Hintergrund“ eine MSI-Datei auspackt? Meistens werden Windows Installer Setups nicht als native MSI-Dateien angeboten, sondern sind in Bootstrapper eingepackt, welche eine allfällig fehlende Windows Installer Runtime oder noch andere zum Betrieb der Applikation erforderliche Abhängigkeiten installieren (Redistributables), bevor die effektive MSI-Datei abgearbeitet wird. Wenn sich die MSI Datei nicht über Parameter auspacken lässt, so findet man die extrahierte Source nach dem Starten des Setups mit UserInterface und nach Erscheinen des ersten Windows Installer Dialogs lokal auf dem Client. Der Initialisierungsteil des Client-Prozesses von Windows Installer, der während der Abarbeitung der Dialoge aktiv ist, kopiert diese Datei als eine der ersten Operationen vom Ausführungsverzeichnis in den %TEMP%-Folder. Lokalisieren Sie daher beim Erscheinen der ersten Windows Installer Dialogmaske auf dem Client die extrahierte MSI-Datei. Erweitern Sie ihre Suche aber auch auf die ganze Festplatte. Es kann sein, dass extern vorliegende Cabinett-Daten und andere zur Installation gehörende Ressourcen sich in einem anderen Verzeichnis befinden. Wenn Sie die MSI-Datei, samt ihren zusätzlich benötigten Daten gefunden haben, kopieren Sie diese in ein sicheres Arbeitsverzeichnis. Die Dateien im %TEMP%-Folder werden nach Beendigung des Setups automatisch gelöscht.
Achten Sie aber auch darauf, dass sie nur Dateien kopieren, die Sie zur Ausführung der MSI-Datei benötigen. Bootstrapper erstellen in der selben Struktur oft auch andere temporäre Dateien, die für das Customizing nicht nötig sind (InstMsi*.EXE, etc.). Zudem werden während der Ausführung des Setups auch Daten aus der Binary-Table ausgepackt, auf welche wir getrost auch verzichten können (CustomActions, Dateien der InstallScript Engine, etc.).
Stellen Sie sicher, dass in Ihrem produktiven Umfeld, die im Bootstrapper eingepackten erforderlichen Softwareabhängigkeiten (Redistributables) installiert werden (Beispielsweise über Ihr Softwareverteilungstool).
Um zu Erkennen, welche Propertys vom Wrapper/Bootstrapper an das MSI übergeben werden, können Sie die Logging Policy im Group Policy Editor verwenden (Computer Configuration > Administrative Templates > Windows Components > Windows Installer to activate Windows Installer Logging = „voicewarmup“), welche die Protokollierung aller Windows Installer Prozesse einschaltet. Dies geht auch, indem Sie das Logging über den folgenden korrespondierenden Key einschalten:
HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\Logging=voicewarmup
Diese Logging Policy erstellt eine Logdatei für alle Windows Installer Prozesse im %TEMP%-Verzeichnis. Öffnen Sie dann nach einer Installation via Setup.exe die dort erstellte Logdatei und suchen Sie ziemlich zu Beginn der Datei nach dem Vorkommen von „Command Line:“. Diese Zeile zeigt an, welche Properties durch den Wrapper übergeben wurden. Achtung: CURRENTDIRECTORY, CLIENTUILEVEL, CLIENTPROCESSID, %HOMEPATH, %HOMEDRIVE und %HOMESHARE können dabei ignoriert werden. Diese Properties sind in jeder Übergabezeile zu finden. Alle anderen zusätzlichen Properties notieren Sie sich für eine spätere Übernahme in das MSI/MST.

Code:

Beispiel für eine Logdatei:
MSI (s) (AC:44) [14:04:47:500]: Command Line: NOEXPIRE=Yes CURRENTDIRECTORY=C:\Temp CLIENTUILEVEL=2 CLIENTPROCESSID=464 %HOMEPATH=\Documents and Settings\oberlind %HOMEDRIVE=C: %HOMESHARE=

Wirklich problematisch wird es erst, wenn im Setup-Launcher, ausser der Installation von Abhängigkeiten bereits die Installationslogik untergebracht sein sollte und die Ausführung der MSI-Datei über die Windows Installer API, nach Abhandlung der externen Logik erfolgen würde. Reine InstallScript MSIs verwenden diesen Mechanismus. Dort befindet sich die script-basierte Installationslogik im Setup.exe (Setup.inx) und wird von der InstallShield Engine verwaltet, statt dass diese via InstallExecuteSequence in CustomActions untergebracht wäre. Die MSI wird dort nur als Datenbank für zentrale Registrykeys und Dateien herangezogen. Ein Verfahren, welches bei Repaketierer & Softwareverteiler nicht beliebt ist. InstallScript MSIs sollten in solchen Fälllen via macrovisions Repackager in „reine MSIs“ konvertiert werden. Nur dadurch ist einigermassen gewährleistet, dass ein Grossteil der im Wrapper angesiedelten Logik, als auch die Komponenten samt ihren Eigenschaften aus der MSI-Datei in eine neue native MSI-Datei überführt werden, welche als Ausgangslage für ein weiteres Customizing dienen kann. Leider ist aber die Konvertierung nicht durchgängig. So werden beispielsweise weder KomponentenID, noch Package-, Product- und Upgradecodes übernommen und auch viele andere Eigenschaften gehen bei diesem Prozess verloren.
Eine Anleitung finden Sie hier
http://helpnet.installshield.com/robo/projects/adminstudio75/ISRTaskConvertISMSI.htm

Administrative Installation: Erstellen Sie eine Administrative Installation, falls dies die in Ihrem Unternehmen bevorzugte Installationsart ist.
(Bspl: msiexec.exe /a <msiname> TARGETDIR=<AdminPoint> /L*V <logdatei> /qb-)
Durch die Angabe von „/qb-“ erspart man sich Probleme, die durch Actions in der InstallUISequence entstehen könnten (bspl. Aufruf MSI ohne Setup.exe). Die InstallUISequence-Table wird dadurch nicht abgearbeitet.
Verwenden Sie unbedingt ein TARGETDIR, welches sich vom Verzeichnis von <msiname> unterscheidet, ansonsten wird die Administrative Installation mit einer Fehlermeldung quittiert.
Achtung: Ist das Attribut-Flag in der Components-Tabelle irgend einer Komponente auf „NeverOverwrite“ (128) gesetzt und sind diese so markierten Komponenten auf dem System registriert, wo die Administrative Installation ausgeführt wird, so entpackt der Parameter /a die damit verknüpften Dateien nicht. Bei späteren Zugriffen würde diese Datei fehlen und man könnte das Produkt auch nicht mehr fehlerfrei rekompillieren (erneutes Erstellen von Cabinetts).
Vorbereitungsarbeiten: Kopieren Sie die MSI und arbeiten Sie mit der Kopie weiter. Nun sind Sie im Besitz einer MSI Datei samt zugehörigen Daten, welche Sie durch Customizing verändern können.
Bootstrapperproperties: Integrieren Sie eventuelle Übergabepropertys die der Bootstrapper an das MSI weitergeben würde über die Propertytable. (siehe vorheriges Kapitel über Bootstrapper)
Featureselektion: Für einfachere Wahl/Abwahl von Features verwenden Sie die „INSTALLLEVEL“- Property:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/installlevel.asp
Level-Einträge in der Feature Table > dem INSTALLLEVEL-Property in der Property-Table deselektiert dieses Feature für zukünftige Installationen.
Propertyänderungen über Dialoge: Müssen Eingabeoptionen über Dialogfelder konfiguriert werden, so empfiehlt sich der Einsatz von Tools wie InstallTuner (macrovision) oder InstallTailor (WISE). Mit beiden Tools kann man über „Response Transforms“ eine sog. Antwortdatei erstellen. In dieser Betriebsart werden die Setupdialoge abgearbeitet und Property-Veränderungen aufgezeichnet.
Es geht aber auch, indem man eine Installation mit Logfile erstellt und dieses anschliessend analysiert: msiexec.exe /i <msidatei> /l*v <logfile> erstellt eine Logdatei, woraus alle Propertyänderungen ersichtlich sind, ausser solche, die über „MsiHiddenProperties“ in der Propertytable der MSI-Datei vermerkt sind. „MsiHiddenProperties“ gegebenenfalls aus der Property-Table löschen.
Auch ein Fehler im Installationsverhalten lässt sich am einfachsten und effektivsten mit der Logging-Option /L*V oder der Logging Policy „voicewarmup“ (siehe oben) analysieren.
InstallScript: Liegt Ihnen ein MSI mit InstallScript Komponenten vor, welche Sie verteilen möchten, so fügen Sie bei Vorliegen der Actions „ISVerifyScriptingRuntime“ und „OnCheckSilentInstall“ die Property „ISSETUPDRIVEN=1“ ein oder setzen Sie bei diesen Actions eine Condition, die immer False ergibt (Beispielsweise Setzen einer Condition „NEVER“, wenn es diese Property nicht gibt).
http://support.installshield.com/kb/view.asp?articleid=Q108166
Diese Actions würden dazu dienen, eine Fehlermeldung anzuzeigen und das Setup abzubrechen, wenn Sie es silent und ohne Setup.exe ausführen sollten.
Zudem installieren Sie vorgängig die benötigte Version von ISScriptxx.msi. Die benötigte Version ersehen Sie aus der Property Table (ISSCRIPT_ENGINE_VERSION). Des Weiteren definieren Sie in Ihrem Softwareverteilungstool eine Abhängigkeit auf Ihre InstallScript Engine.
per-machine Installation: Setzen Sie nötigenfalls die Properety „ALLUSERS“ auf 1, wenn Sie „per-machine“ Installationen in Ihrem Unternehmen bevorzugen (empfohlen).
Benutzerressourcen: Machen Sie sich bei „per-machine „ Installationen Gedanken darüber, wie Sie eventuell vorliegende Benutzerressourcen integrieren, so dass diese für alle Benutzer verfügbar sind! (wird in einem eigenen, späteren Thema beschrieben) und machen Sie sich Gedanken darüber, ob ein möglicher späterer Reparaturmodus im Benutzerkontext ausgeführt werden könnte. Wo befinden sich dann die Ressourcen? Muss die SOURCELIST-Property erweitert werden?
Upgrade: Machen Sie sich darüber Gedanken, ob Sie die Upgradetable des Herstellers 1:1 übernehmen wollen oder ob Sie weitere durch Sie paketierte und repaketierte Anwendungen für einen Upgrade integrieren wollen.
Default-Properties: Definieren Sie (Einheits) Propertys, welche in Ihren Paketen immer Anwendung finden (Bspl. alle ARPxxxxx-Propertys zum Definieren des Paketverhaltens über Add/Remove Software.
Handling eines Reboots: Setzen Sie die Property REBOOT auf „ReallySuppress“ und steuern Sie allfällige Neustarts über Ihr Softwareverteilungstool.
Konfiguration: Integrieren Sie falls nötig eigene CustomActions für eine spezifischere Konfiguration des Produktes. Achten Sie dabei darauf, dass Sie bestehende Sequenzen in der InstallexecuteSequence-Table möglichst nicht oder nur wenig verändern.
Die Integration von Registrykeys und anderen Ressourcen direkt in die MSI ist hier ausnahmsweise nicht empfohlen, da durch diese Massnahme und durch diese Erweiterungen das Risiko besteht, dass zukünftige Patches (MSP) des Herstellers nicht mehr fehlerfrei angewendet werden könnten.
betriebsspezifische CustomActions: Integrieren Sie falls nötig betriebsspezifische CustomActions, um die in Ihrem Unternehmen für den Softwareverteilungsprozess nötigen zusätzlichen Aufgaben zu erledigen (bspl. spezielle Logdatei, Abschlussstatus in Protokolldatei für späteren Support, Einlesen und Verarbeiten variabler Daten, etc.). Achten Sie auch hier darauf, dass Sie bestehende Sequenzen in der InstallexecuteSequence-Table nicht oder nur wenig verändern.
Shortcuts: Löschen und oder Verändern Sie die durch das Setup zu erstellenden Verknüpfungen (Bezeichnungen) nach Ihren Vorgaben oder Ihrem Geschmack.
Installationsanalyse: Lösen Sie Installationsprobleme durch Auswerten der Logdatei (siehe Logging Policy weiter oben), indem Sie nach den massgeblich verantwortlichen Actions suchen. Löschen Sie solche Übeltäter nicht einfach aus der InstallExecuteSequence, sondern setzen Sie eine Condition, welche in Ihrem Umfeld False ergibt.
Probleme mit der Silentinstallation: Sollten sich betriebsauswirkende Unterschiede im Installationsablauf ergeben, je nachdem, ob die Ausführung über msiexec.exe silent mit /q <n|b <+|-|!-> > initiiert oder das Setup mit UserInterface gestartet wurde, dann müssen sie sich Gedanken darüber machen, was denn nun mit UI anders läuft als ohne:
Überprüfen Sie die Conditions in der LaunchCondition-, Condition-, Component- und InstallExecuteSequence-Table nach Verweisen auf den UILevel oder auf Properties, die in der ControlEvent-Table gesetzt werden.
Überprüfen Sie vor allem auch die ControlEvent-Table nach “DoAction”-Ereignissen, welche auf Controls in ihren ausgewählten Dialogen folgen. Überprüfen Sie so ermittelte CustomActions auf Existenz in der InstallExecuteSequence und fügen Sie diese falls erforderlich dort ein. Überlegen Sie sich gut, in welcher Sequenz sie diese einfügen. Wenn es sich um Actions aus Dialogen vor der effektiven Installation handelt, so sind diese Actions am besten vor der Scripterstellung, vor InstallInitalize einzufügen. Andere CustomActions die erst über einen Abschlussdialog zur Ausführung kämen, wären nach InstallFinalize einzutragen.
Erhöhen Sie zudem das Attribut-Flag in der CustomAction Table um 256 (msidbCustomActionTypeFirstSequence), sofern dieses Attribut nicht bereits gesetzt war. Dieses Attribut bewirkt, dass die Action nur einmal (UserInterface oder InstallExecuteSequence) ausgeführt würde.
Transformdatei erstellen: Schliessen Sie die Arbeiten ab, indem Sie mittels MsiTrans.exe (weiter oben erklärt) oder über ein Authoringtool eine MST-Datei mittels Differenz aus diesen MSI-Erweiterungen bilden. Sie verwenden dazu die ursprüngliche MSI-Datei, verglichen mit der bearbeiteten MSI-Datei. Löschen Sie anschliessend die zweite, durch Sie modifizierte MSI-Datei, damit spätere Verwechslungen mit dem Hersteller-MSI ausgeschlossen sind.
Test: Testen Sie Ihr neues Setup mit der Transformation.
Msiexec.exe /i <msidb> TRANSFORMS=<transform> /L*V <logfile> /qb

Einige der oben skizzierten Aufgaben lassen sich natürlich auch über das Windows Installer API automatisieren. Dies ist vor allem bei grösseren Unternehmen, wo viele Applikationen customized werden, in Erwägung zu ziehen.

Weiterführende Informationen zu diesen Empfehlungen finden sich auch auf Microsofts Windows Installer Team Blog http://blogs.msdn.com/windows_installer_team/archive/2006/05/12/595950.aspx (Rule 11) und auf http://support.microsoft.com/kb/264478/en-us

Dominik Oberlin

Dominik Oberlin wrote:

Repaketier NIE ein Windows Installer Setup!

erstmal danke fuer den ausfuehrlichen artikel. ich wuenschte mehr leute wuerde hier so ausfuehrlich schreiben (ich eingeschlossen Wink

)

generell hast du schon recht, allerdings gilt auch hier das beliebte "it depends..."

ich hab schon so viele hersteller-msi-setups gesehen, die einfach nicht brauchbar waren und somit repaketiert werden mussten. das beste war ein fall, bei dem das msi nicht mehr silent installiert werden konnte... Shocked

Melchior Joined: 29 May 2006 Posts: 29

Du hast nicht unrecht. Auch in meinem Thread habe ich mir ein Hintertürchen offen gelassen:

Quote:

"...Wir customizen MSI-Setups! Immer! Sofern es möglich ist...."

Trotzdem möchte ich an den Mut des Repaketierers zum Customizing appellieren! Viele Hürden lassen sich bei genauer Analyse lösen. Auch ich hatte schon diverse Hersteller-MSIs in den Händen, wo es zunächst so aussah, dass man es aufzeichnen müsste. Erst eine Analyse des Verbose-Logfiles und manchmal das Disablen spezieller CustomActions, welche das Ausführungsverhalten im silent-mode steuern und/oder das Abändern von Conditions verhalf dann zum Ziel.
Oft findet man auch beim Hersteller oder im Internet Hilfe zur silent-Installation ihrer Setups. (Bspl: Spezialbehandlung der Datei ABCPY.INI bei Adobeprodukten www.adobe.com/support/techdocs/331261.html Eine saubere Implementation der Registrationsinformationen bei Photoshop ist anders beispielsweise kaum möglich.)

einige Probleme bei customizen, die immer wieder vorkommen:

MSI versucht CustomActions aus SOURCEDIR zu starten, welche im jetzigen Setup fehlen
CustomActions greifen auf weitere externe Steuerungsdaten (bspl. INI-Datei) in speziellen Folders zu. (siehe ABCPY.INI)
Conditions über den UILevel verhindern die korrekte Ausführung ohne UserInterface
Bei InstallScript MSIs Verweis auf die Property SETUPEXEDIR, welche durch das Setup.exe erstellt würde. http://helpnet.installshield.com/robo/projects/installshieldxhelplib/SETUPEXEDIR.htm

Aber trotzdem, Dein Einwand ist berechtigt: Keine Regel ohne Ausnahme. Manchmal wird der Aufwand beim Reingeneering und der Analyse schlicht zu gross. Dass man in solchen Fällen aus Überlegungen des Kosten/Nutzen-Faktors auf ein traditionelles Repaketieren zurückgreift, kann ich gut verstehen.

Imperial Joined: 15 Jun 2004 Posts: 20

Hallo Dominik,

ein wirklich guter und umfassender Artikel. Ich stimme da in den meisten Punkten zu. Eines jedoch kann ich so nicht ganz stehen lassen:

Quote:

(über unattended Scripting Tools (autom. Steuerung der Dialogboxeingaben)) -> Nicht empfohlen

Sicher ist das Steuern der Eingabeboxen nicht die Methode der Wahl, wenn ich ein anderweitig nativ automatisierbares Setip habe. Dennoch würde ich diesen Weg einer Repaketierung in der Regel vorziehen. Denn auch hier geht die Logik des Original Setup icht verloren.

Sicherlich muss man unterscheiden, ob man einen simplen Makro Rekorder verwendet, oder ein mächtiges Skripting Tool zur Verfügung hat. Ist letzteres der Fall, und ist man sich der möglichen Fallstricke bei der Oberflächenskriptierung bewusst, kann man sicherlich auch ohne schlechtes Gewissen diese Automatisierungsmethode wählen.

Bernd Holz