Für Administratoren die ein Office Plugin repaketieren, kommt erschwerend dazu, dass für jede Office Version die berücksichtigt werden muss, ein Snap-Shot von der Hersteller-Installation durchgeführt werden muss. Als wäre dies nicht schon genug, müssen Dateien die scheinbar die Gleichen sind auch noch Binär abgelichen werden, denn nicht selten kommt es vor, dass ein Plugin die gleiche Grösse und das gleiche Datum hat, jedoch Binär unterschiedlich sind.

Der folgende Weg beschreibt wie mann gleiche oder unterschiedliche Office Plugins mit einer Installation für verschiedene Office Versionen bereitstellt.

Sind die Dateien für die unterschiedlichen Office Versionen bekannt, dann wird für jede Office Version eine eigene Komponente erstellt. Das Verzeichnis steht nur als Beispiel, in der Praxis werden die Dateien in unterliegende Ordner wie STARTUP oder XLSTART installiert.

Beispiel Komponente für Office 12 (2007), erkennbar an der Kondition

Beispiel Komponente für Office 14 (2010), erkennbar an der Kondition

Der Haupteil der Installations-Logik, herauszufinden welche Office Version vorhanden ist, übernimmt eine CustomAction. Die CustomAction wird die auf dem Rechner vorhande Office Version anhand der Winword.exe Datei auslesen und den MajorRelease des Office Produktes in eine Public Property, in diesem Beispiel OFFICEVERSION, hinterlegen. Die OFFICEVERSION Property wird danach als Kondition weiter verwendet.

Da die Custom Action von keiner anderen Aktion abhänigig ist, wird diese im frühen Immediate Bereich der Installation ausgeführt. Zum InstallValidate Zeitpunkt wird anhand der Konditionen entschieden, welche Komponenten installiert werden.

Auszug aus dem Verbose-Log der Installation:

MSI (s) (20:44) [11:24:05:495]: Doing action: ONTXGetOfficeVersion
MSI (s) (20!44) [11:24:05:807]: PROPERTY CHANGE: Adding OFFICEVERSION property. Its value is ’14′.
(Die CustomAction erstellt die Public Property mit dem aktuellen Wert der Office Version)

MSI (s) (20:44) [11:24:07:885]: Doing action: InstallValidate
MSI (s) (20:44) [11:24:07:885]: Component: Office_Makros.dot_12; Installed: Absent;   Request: Local;   Action: Null
MSI (s) (20:44) [11:24:07:885]: Component: Office_Makros.dot_14; Installed: Absent;   Request: Local;   Action: Local
(Die InstallValidate Aktion wird mit der Action Null oder Local den Komponenten Status festlegen)

Nicht zu vergessen, die Public Property muss in die SecureCustomProperty aufgenommen werden.

Mit diesem Vorgehen steht nichts mehr im Wege die nächsten Office Plugin Installationen zu paketieren.

Wer zum Ersten Mal eine  Office 2007 oder 2010 MUL Installation automatisieren muss, dem sei mit einem Microsoft Technical Diagramm geholfen. Wohl reicht ein Ausdruck auf A3 nicht aus um alles darzustellen, jedoch gibt’s noch eine Zoom Funktion oder ein Drucker, der auf A1 oder A0 ausdrucken kann.

Mit dem ‘Deploy Language Packs for Microsoft Office 2010′ Diagramm erhält man auf einen Blick (oder auch zwei) eine Übersicht der Microsoft Office 2010 Sprachpaket-Integration.

Das Diagram zum Herunterladen

Weitere Tech-Diagramme von Microsoft die von Interesse sein können.

Ein ‘Reinstall’ wird jedoch nicht durchgeführt. Das Java Setup wird die bestehende Installation deinstallieren und die gleiche Intallationsrutine erneut aufstarten.

Der Grund dieses Vorgehens liegt im Design der Installation. Es handelt sich bei der Java Installation um keine echte Windows Installer Rutine, sondern die MSI Technologie wird verwendet um Basis Dateien zu installieren, welche durch Benutzerdefinierte Aktionen (Custom Actions) die Hauptinstallation durchführen.

Ein fataler Nebeneffekt besteht nun, wenn eine Repartur oder die Installation ein zweites mal im unbeaufsichtigten Modus  durchgeführt wird.
Anstelle einer Reparatur, wird eine fehlerhafte Neuinstallation durchgeführt.

Ein Blick hinter die Kulissen zeigt, das nicht alle Benutzerdefinierten Aktionen ausgeführt werden.

Fatal: Basis-Dateien wie java.exe werden aus dem System32 Verzeichnis gelöscht und die Java Runtime ist nicht mehr funktionsfähig.

Wir empfehlen daher, die Intallation mittels Transformationsdatei anzupassen, damit dieser unerwünschte Vorgang unterbunden wird.

Folgende Eintäge in der Custom Action Tabelle sind nötig:

 Die InstallExecuteSequence Tabelle mit der Kondition:

In diesem Beispiel sind die Plugins für den RealPlayer und Quicktime auf einem Rechner installiert.

Diese Plugins werden auf unterschiedliche Wege eingelesen. Das RealPlayer Plugin wird über die Registry eingelesen, dessen Weg viele Software Hersteller verwenden.

Die Registry-Einträge für ein Firefox Plugin können über Local Machine Keys bereit gestellt werden.

Das Quicktime Plugin wird über Dateien bereitgestellt. Diese werden in die von Firefox vorgesehenen Ordner (Components und Plugins) abgelegt. Dieser Weg der Plugin Bereitstellung ist seltener anzutreffen.

Im Ordner Components wird die XPT (XPCOM Type Library) Datei Abgelegt, im Ordner plugins werden die Plugins selber abgelegt.

Fazit:
Firefox Plugins sind einfach zu Installieren, da diese Per-Machine Ressourcen sind. Wenn Firefox Plugins repaketiert werden sollen, dann ist Firefox vor einem Snap-Shot zu installieren, da nicht alle Applikationsentwickler die Plugins ohne Firefox installieren.

Mehr über XPCOM kann in Wikipedia nachgeschlagen werden.
http://en.wikipedia.org/wiki/XPCOM