Category Archives: Windows Installer

Die Ontrex AG hat mit der Windows Installer Schulung: Power-Workshop “Software Paketierung unter Windows Vista und Windows 7.0” am 28. Mai 2009 die ersten praktischen Beispiele der Windows Installer 5.0 Erweiterungen unter Windows 7 demonstriert.

Das Windows Installer Team hat nun einen Blog über die neuen Möglichkeiten für gemixte Per  User/Per Machine Installationen unter Windows 7 bzw. Windows Installer 5.0, welches eines der Themen unseres Power-Workshop war, veröffentlicht.

Es wird umfassend auf die neuen Möglichkeiten bezüglich MSIINSTALLPERUSER und ALLUSERS eingegangen, sowie den neuen Per-User Alternativen  für ProgramFilesFolder, ProgramFiles64Folder & CommonFilesFolder.

Link:

• Authoring a single package for Per-User or Per-Machine Installation context in Windows 7

Weitere Informationen zu unserer Wise Schulung und den Power-Workshops finden Sie auf unserer Homepage.

In der 64-Bit Welt stossen aktuelle Repaketierungsumgebungen wie Wise Package Studio 7.0 SP3 & AdminStudio 2009 an Ihre Grenzen.
Der Grund? 32-Bit Applikationen sehen nur den 32-Bit “Teil” der Registry und sind somit nicht in der Lage 64Bit Keys zu erkennen. Da keines der beiden Produkte derzeit 64Bit Binaries anbietet, ist es nicht möglich eine 64Bit Software korrekt zu repaketieren. Eine detaillierte Erklärung dieses Registry-Verhaltens kann im Microsoft KB896459 nachgelesen werden.

Abhilfe schaffen kann man derzeit nur durch die Verwendung von zusätzlichen Tools, z.B Regshot Unicode 2.0, welches auch als 64Bit Variante verfügbar ist.

D.h man macht parallel zum SetupCapture einen “Regshot” Vergleich und importiert diesen danach in das Wise Package Studio Projekt. Idealerweise exkludiert man beim SetupCapture natürlich bereits alle Registry Keys.

Aber ohne Fleiss kein Preis: Die Registry Keys müssen dann leider komplett von Hand an die entsprechenden Komponenten zugewiesen werden, sowie fixe Verweise durch die entsprechenden Properties/Filekeys ersetzt werden.

Regshot Unicode bietet aber zum Glück direkt nach dem Capture die Möglichkeit Registry Keys, auch auf permanenter Basis, auszuschliessen.

Die Software ist erhältlich auf folgender Website:

http://regshot.ru/20/

Weitergehende Lektüren bezüglich 64x Registry Verhalten bekommt man seitens Microsoft hier:

• Knowledgebase: KB896459
• MSDN: Registry Keys Affected by WOW64
• MSDN: Registry Redirector

Beim Automatisieren oder Repaketieren des Lotus Notes Clients in der Version 8.x, wird dem einen oder anderen bereits aufgefallen sein, dass Lotus Notes beim ersten Aufstarten mit  Administratorenrechten einen Shortuct auf dem “ALLUSERS” Desktop erstellt.

Je nach Konfigurationswunsch ist dies natürlich nicht gewollt und störend, insbesondere bei einer Installation auf einem Terminal-(Citrix) Server.

Abhilfe schafft hier das Setzen volgender Systemvariabel:

RCPIGNORELINKS = true

Bei einer repaketierten Installation baut man diese Systemvariable vorzugsweise direkt mit ins Paket ein.

Weitergehende Informationen seitens IBM bekommt man über den folgenden Artikel:
http://www-10.lotus.com/ldd/nd8forum.nsf/7570d1446ddf4cf085256bff00489f8d/72a31bcae693a34a85257578004280e5?OpenDocument

Bei der Abnahme oder dem Applikationtests der Java Runtime sollte man ein besonderes Augenmerk auf die verschiedenen Integrationsmöglichkeiten eines Java Applets legen.

Wer vorzugsweise seine repaketierte Runtime jeweils auf der offiziellen Java.com Seite testet kann schnell in eine Falle geraten. Der Test mag funktionieren, doch die Runtime ist nicht vollumfänglich funktionsfähig.

Der Grund hierfür  ist, das ein Java Applet  über drei verschiedene Wege initialisiert werden kann.
Bei Java.com wird nur eine Initzialisierung getestet, die über den <OBJECT> HTML Tag geht.

Ein schneller und zuverlässiger Test kann man auf folgender Seite durchführen:
http://browserspy.dk/java.php

Die Integration wird mittels <OBJECT> und <APPLET> Tag getestet und kann somit eine zuverlässige Aussage machen ob die Integration funktioniert.

Anfangs August hat Microsoft das neuste Windows 7 Driver SDK Kit veröffentlicht.

Dies beinhaltet unter anderem die neuste Version des difxapp.msm Merge Modules welches nun Unterstützung für folgende Betriebsysteme bietet:

• Windows 7
• Windows Vista
• Windows XP
• Windows Server 2008 R2
• Windows Server 2008
• Windows Server 2003

Downloadlink:

http://www.microsoft.com/downloads/details.aspx?FamilyID=2105564e-1a9a-4bf4-8d74-ec5b52da3d00&displaylang=en

Wir empfehlen das neuste difxapp.msm Merge Module bei der Installationserstellung zu verwenden.

Microsoft hat die RTM Version der Windows  7 SDK herausgegeben. Was bedeutet das die Windows Installer Programme wie Orca, Verbose Log Analyzer und die Validations-Dateien (.CUB) in der Version 5.0 erhältlich sind.

Die ISO Datei der Platform SDK kann per sofort herunter geladen werden.

Mit der Veröffentlichung des Windows 7 RTM Betriebsystems, ist der Windows Installer 5.0 nun auch veröffentlicht.
Wann die Windows Installer 5.0 Redistributable erhältlich ist, wurde noch nicht bekannt gegeben.

In diesem Blog erkläre ich, welche Elemente beim Repaketieren einer MSI Installation auftauchen und wie mit diesen umzugehen ist.

Im Jahr 2004 habe ich ein Artikel auf myITforum.com mit dem Titel ‘The three biggest mistakes in Windows Installer repackaging ‘ veröffentlicht, der unter Punkt 3 beschreibt, dass es nicht falsch sein muss, eine MSI Installation zu repaketieren.

Beim Repaketieren einer MSI Datei sind auf folgende sechs Punkte Rücksicht zu nehmen:

1. Darwin Descriptoren
Diese Registry-Keys werden anhand der Advertising Tabellen erstellt und sollen nicht über die repaketierte MSI mit installiert werden, da die repaketierte MSI eigene Darwin Descriptoren generiert (sollte der Support des Advertisings gewünscht sein). Es gibt zwei Darwin Descriptoren in der Regsitry, die sich wie folgt identifizieren lassen:

In der CLSID Sektion des Classes Root Hive, erkennbar als InprocServer32 Wert

Oder als Command Verb in einem Programmatic Identifier (ProgID)

2. Windows Installer Datei Registrationen
Jede MSI Installation registriert sich am Ende des Installationsprozesses auf dem PC. Neben der lokalen Kopie der MSI Datei werden Transformdateien, Patch Dateien und Ikonen von Shortcuts im C:WindowsInstaller Verzeichnis niedergelegt. Diese sind aus der repaketierten MSI Installation zu löschen.

3. Windows Installer Registry Registrationen
Neben den Windows Installer Dateien werden in den folgenden Bereichen der Registry Einträge vorgenommen, die zu löschen sind:

Weitere Registry-Einträge wie Uninstall und SharedDlls Informationen sind anhand der Repackaging Best Practices zu verwalten.

4. Advertised Shortcuts
Sollte die Hersteller MSI Installation Advertised Shortcuts erstellen, so werden diese in der repaketierten MSI Installation nicht funktionieren, da diese Binär sind und nicht interpretiert werden können.
Die Shortcuts müssen entweder manuell nachgebaut werden, oder bei der Hersteller Installation kann über die Befehlszeile ein Argument mitgegeben werden, welches anstelle von advertised Shortcuts normale Shortcuts erstellen wird. Das Argument DISABLEADVTSHORTCUTS zwingt die MSI Installation normale Shortcuts zu erstellen, welche von einem Repaketierungs-Tool interpretiert werden können.

5. .NET Assemblies
Achten Sie auf Einträge in der MSIAssembly Tabelle des Hersteller MSIs, da diese aufwändig sind in CustomActions umzuschreiben. Es können alle Einträge vom Hersteller MSI kopiert und in die repaketierte MSI übernommen werden. Anpassungen sind in den meisten Fällen von Nöten, da die Komponenten-Namen und Datei-Einträge in der File Tabelle unterschiedlich ausfallen werden.
Beispiel: Die MSIAssembly Tabelle von einer Hersteller MSI

Die angepasste MSIAssembly Tabelle nach dem Repaketieren

Nicht zu vergessen ist danach das Gleiche mit der MsiAssemblyName Tabelle zu tun.

6. Update Funktionalität sicherstellen
Die Sicherstellung der Kompatibilität für Major Updates, die vom Hersteller bei zukünftigen MSI Installationen erwartet wird, kann über den Produkt Code (Property) und den UpgradeCode (Property) berücksichtigt werden. Beide Werte werden während dem Repaketierungsprozess neu generiert und sollten vom originalen MSI Paket übernommen werden.

Bei der Repaketierung einer Hersteller MSI wird die Unterstützung von Hersteller-Patches (MSP Dateien) verloren gehen. MSP Dateien müssen ebenfalls repaketiert werden und mit einem geeigneten Tool wie dem Wise PatchCreationWizard von Symantec manuell erstellt werden.

Unter Berücksichtigung dieser sechs Punkte steht nun nichts mehr im Wege, eine Hersteller MSI in eine eigene MSI zu repaketieren.

Stefan Hotan
A member of the Ontrex SPA Team

Mit der Einführung von Windows 7 kann über die MsiLockPermissionsExTabelle eine erweiterte Rechtevergabe auf Sicherheitsobjekte verwendet werden.

Diese Funktion macht auf den ersten Blick die Erstellung von Custom Actions für die Rechtevergabe, wie dies sich in den Jahren eingebürgert hat, überflüssig.

Jedoch kann die MsiLockPermissionsEx Tabelle erst ab Windows 7 verwendet werden. Bei älteren Betriebssystemen von Microsoft muss nach wie vor mit einer Custom Action die Rechte-Vergabe durchgeführt werden.

Der Einsatz beider Tabellen ist zu vermieden. Obwohl unter Windows XP oder Windows Vista von der LockPermissions Tabelle weiterhin gebrauch gemacht werden kann, wird es zu einem Windows Installer Error 1941 kommen, sobald eine MSI Installation mit beiden LockPermissions Tabellen unter Windows 7 eingesetzt wird.

Um eine MSI Installation auf Windows XP, Windows Vista und Windows 7 ohne Probleme mit erweiterten Rechtevergabe ausüben zu können, empfehlen wir nur die MsiLockPermissionsEx Tabelle zu verwenden. Für ältere Betriebsysteme ist nach wie vor eine CustomAction zu verwenden, welche anhand einer entsprechenden Kondition nicht unter Windows 7 ausgeführt wird.

Stefan Hotan
Member of the Ontrex SPA Team