Category Archives: Application Best Practices

Active Setup and Per-User/Per-Machine registry

The Windows Installer allows you to create a setup which will dynamically writes registry keys into either  HKCU or HKLM. This behaviour is then controlled by the “ALLUSERS” Property.

The Windows Installer Help describes this feature as follow:

 Constant  Hexadecimal  Decimal  Root key
 (none)  – 0x001  -1  If this is a per-user installation, the registry value is written under HKEY_CURRENT_USER.If this is a per-machine installation, the registry value is written under HKEY_LOCAL_MACHINE. Note that a per-machine installation is specified by setting the ALLUSERS property to 1.

We will now provide an example to illustrate this behaviour:

reg01

 

In this MSI I have chosen the “AppDataFolder” system property as Value  in order to check the resolved path. The path will be different for each user because its an per-user defined system property.

If you install this key with the ALLUSERS Property set to “1” the result will be as following:

[HKEY_LOCAL_MACHINE\SOFTWARE\Ontrex\Example]
"UserOrMachine"="C:\Users\Administrator\AppData\Roaming\"

The key will be installed into HKLM however the property will be resolved according to the current installing user.

If you install this application again with ALLUSER set to “2”  the result will look like this:

[HKEY_CURRENT_USER\Software\Ontrex\Example]
"UserOrMachine"="C:\Users\test\AppData\Roaming\"

More details about this behaviour/feature can be obtained from the following MSDN Article:

http://blogs.msdn.com/b/windows_installer_team/archive/2009/09/02/authoring-a-single-package-for-per-user-or-per-machine-installation-context-in-windows-7.aspx

Conclusion: The registry root parameter can be used to dynamically write the registry keys into HKCU or HKLM  based on the current installation context (Per-User <> Per-Machine)

But what happens if you have a per machine installation which contains an active setup mechanism?

Let’s have a deeper look into it:

We add all corresponding registry keys, features and components to the MSI  which are required  for a fully functional Active Setup.

Now let’s install the MSI under system account with ALLUSER=1 and check the example registry key.

The Result is:

[HKEY_LOCAL_MACHINE\SOFTWARE\Ontrex\Example]
"UserOrMachine"="C:\Windows\system32\config\systemprofile\AppData\Roaming\"

Now log off and log on with a standard user account and check the key again and something unexpected happened. As you see the key changed to:

[HKEY_LOCAL_MACHINE\SOFTWARE\Ontrex\Example]
"UserOrMachine"="C:\Users\test\AppData\Roaming\"

What happend?

The Property ALLUSERS sets the installation to a  machine installation and the Active Setup will be execute with the following option “/fu” (all required user-specific registry entries).

Answer:
During the active setup the windows installer will repair the MSI in User Context and only user-specific registry keys will be rewritten (“/fu” parameter). All “-1” however are simply considered as “user based keys” even the ALLUSERS property is set to “1”. Because the repair works with elevated priviliges this HKLM key will now be rewritten using the current users [AppDataFolder] value.

Our conclusion

We will kindly advice you not to use “-1” in the root column of the Registry table in a windows installer database in conjunction with active setup. Also bear that in mind when you are adding activesetup to an existing vendor msi (Transform).

Regards,

SPA Team

Plugin für verschiedene Office Versionen bereitstellen

Wenn immer eine neue Version von Microsoft Office verfügbar ist, kommt es vermehrt zur Situation, dass eine Installation Office Plugins sowohl für die Vorgängerversion wie auch für die aktuellste Version bereitstellen muss.

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.

Install Microsoft Office 2010 Language Packs

Das Prinzip der Office 2010 Language Packs Installation wurde von der Vorgänger Version 2007 übernommen.

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.

Java Runtime Silent Repair

Nicht überall wo MSI draufsteht, ist auch MSI drin. Ein Paketierer-Sprichwort, was sich bei der Sun Java Runtime bewahrheitet.
Ein aktuelles Problem der Java Runtime besteht bei einer unbeaufsichtigten Reparatur (Silent Repair), denn die Java Installation unterstützt keine Reparatur. Dies wird ersichtlich in der Systemsteuerung, es besteht nur die Möglichkeit das Produkt zu deinstallieren. Auch bei einer erneuten Installation bekommt der Endanwender über die Installationsdialoge eine Mitteilung:


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:

Firefox Plugins Repaketieren

Die Plugins von Firefox zu repaketieren ist im Grunde einfach. Wissenswert ist, dass es zwei verschiedene Möglichkeiten gibt, um Plugins bereitzustellen.

Firefox Plugins

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.

plugins2

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.

plugins4

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