Category Archives: Windows Installer

Wer bereits viel “App-v”-isiert wird sicher schonmal folgende Fehlermeldung erhalten haben:

The requested operation requires elevation

Error Code: 4513CDC-1B40212C-000002E4

Das Problem tritt in der Regel auf wenn eine Applikation erhöhte Rechte anfordert, beispielsweise durch einen “requireAdministrator” Eintrag im Manifest.

In App-V kann man dieses Problem relativ einfach beheben in dem man die OSD der Applikation um folgenden Eintrag ergänzt:

<ENVLIST>
<ENVIRONMENT VARIABLE=”__COMPAT_LAYER”>RunAsInvoker</ENVIRONMENT>
</ENVLIST>
<DEPENDENCIES />

Die “CMD/Batch” Variable __COMPAT_LAYER kann man übrigens auch in Batch Files verwenden, wenn man nicht möchte das ein Prozess erweiterte Rechte anfordert, bzw. ein UAC Dialog erscheint.

Der Wert “RunAsInvoker” forciert das die Prozesse in der aktuellen Berechtigungsstufe bleiben sollen.

Quelle:
http://blogs.technet.com/b/virtualworld/archive/2010/04/13/the-requested-operation-requires-elevation-2c-000002e4.aspx

Weitergehende Informationen zur __COMPAT_LAYER Variable:
http://blogs.msdn.com/b/cjacks/archive/2009/09/13/how-to-run-applications-manifested-as-highestavailable-with-a-logon-script-without-elevation-for-members-of-the-administrators-group.aspx

Wer einige Pakete für ein x64 Betriebsystem mit Wise Package Studio repaketiert hat, dem wird sicher bereits aufgefallen sein das die Add/Remove Icons nicht mehr funktionieren.

Der Grund hierfür liegt daran das Wise Package Studio leider immer noch einen alten (legacy) Weg einschlägt um dieses Icon zu setzen (via Registry Key) welcher unter x64 nicht mehr funktioniert.

Mit folgendem Trick schlägt man den korrekten “Windows Installer” Weg ein welcher sowohl unter x86 & x64 Betriebsystemen funktioniert:

1. Falls man bereits ein “Shortcut” Element mit dem gewünschten Icon hat, kann man direkt zu Punkt 3.2 springen.

2. Als erster Schritt muss man zur “Icon” Resource kommen. Hierfür gibt es mehrere Techniken, der einfachste Weg ist mittels dem Tool “IconsExtract” von NirSoft (Freeware, http://www.nirsoft.net/utils/iconsext.html). Am besten sucht man sich das Haupt-EXE heraus und extrahiert das Icon. Sofern man Glück hat ist vielleicht auch bereits ein ICO File im Installationsverzeichnis vorhanden. Auf jeden Fall sollte am Ende dieses Schrittes ein ICO File mit dem gewünschten Inhalt vorliegen.

3.1 In der Setup Editor Ansicht wechselt man auf die “Icon” Tabelle und erfasst eine neue Zeile (Rechtsklick auf Tabelle -> “New Row”). Den Namen kann man frei wählen. Mittels Doppelklick auf “{binary data}” kann man das ICO Resource in die Tabelle laden. Nun gehts weiter zu Punkt 4.

3.2 In der Setup Editor Ansicht wechselt man auf die “Shortcut” Tabelle. Dort sucht man den entsprechenden Shortcut und kopiert den Wert welcher in der “Icon_” Kolumne steht. Falls der Wert leer ist muss man zurück zu Punkt 2 springen. Ansonsten gehts weiter bei 4.

4. Nun erfasst man in der Property Tabelle ein Property namens “ARPPRODUCTICON” und erfasst als Value den Wert des “Binaries”. Sofern man die ICO Resource selber hinzugefügt hat, muss man natürlich den gewählten Namen wiederverwenden .

Mit der aktuellen Version des Wise Package Studios erscheint ab Windows Vista beim Setup-Capture die Meldung ‘The operating system currently has a security restriction that interferes with Virtual Capture and SmartMonitor’.

Wenn der SmartMonitor und der Virtual Capture nicht verwendet werden, also nur das klassische Snap-Shot Verfahren gebraucht wird, dann kann diese Meldung mit ‘No’ ignoriert werden.
Mit folgendem Registry-Key kann diese Nachricht unterdrückt werden:
[HKCUSoftwareWise SolutionsWindows Installer EditorHideMessages]
“20153”=dword:00000006

Hinter dieser Option steht eine Sicherheitserweiterung, die mit der Vista Version von Windows eingeführt wurde. Wird der Hinweis mit ‘Yes’ beantwortet, so wird folgender Registry-Key geschrieben:
[HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionWindows]
“LoadAppInit_DLLs”=dword:00000001

Die LoadAppInit DLLs ist eine Beriebsystem-Funktion, welche bei jedem Prozess zusätzliche DLL’s ladet. Wise Package Studio verwendet diese Funktion um die Datei HookDll.dll in den Speicher eines jeden Prozesses einzubinden. Damit wird es ermöglicht, einen Installationsprozess zu überwachen und dessen Vorgehen mit SmartMonitor oder VirtualCapture aufzuzeichnen.
HookDll.dll

Seit kurzem ist die Version 4.6 der Microsoft Software-Virtualisierungstechnologie (APP-V) verfügbar.

Mit der Version 4.6 findet nun auch native x64 Technologie Einzug in die Virtualisierungslösung von Microsoft.

Herunterladen lässt sich die neuste APP-V Version über die gängigen Seiten/Zugriffsmöglichkeiten:

• Technet
• MSDN
• MVLS

Die Ontrex AG bietet umfangreiche Consulting und Paketierungs-Diensleistungen für diese Technologie an.
Weitere Informationen über unsere Dienstleistungen finden Sie auf unserer Homepage.

Problem:

Sie erhalten in  Wise Package Studio beim kompilieren von virtuellen Projekten (WVP) im “Virtual Package Editor” nachfolgende Fehlermeldung:

Das erstellte VSA Paket an sich funktioniert, allerdings wird die Package GUID nicht korrekt gesetzt.

Lösung:

Das Problem taucht nur auf wenn der Wise Package Studio Server auf einem x64 OS installiert wurde.

Die “VPE_SVSZip.dll” Komponente, welche die Datei SVSZip.dll beinhaltet,  wird nur auf 32-Bit  Systemen installiert da diese mit “NOT VersionNT64” konditioniert ist.

32-Bit Network Clients, welche nahezu sämtliche Programme vom Server aus abrufen, benötigen aber diese DLL um das VSA korrekt abschliessen zu können.

Am einfachsten installieren Sie einen Testserver auf ein 32-Bit OS und kopieren danach die “SVSzip.dll” ins “Virtual Package Editor” Verzeichnis.

Mit Wise Package Studio 8 wurden 3 Komponenten Attribute der neueren Windows Installer Versionen hinzugefügt, welche wir in diesem Artikel genauer unter die Lupe nehmen:

msidbComponentAttributesDisableRegistryReflection  (Disable registry reflection)

(Betrifft nur x64 Betriebssysteme)
Dieses Komponenten Attribut deaktiviert die Registry Reflection für alle Registrey Keys der betroffenen Komponente.

Vereinfacht erklärt:

Auf 64-Bit Windows Systemen gibt es 2 Registry Ansichten, eine für 32-Bit und eine für 64-Bit Applikationen.

Dabei unterscheidet man zwischen folgenden 3 Redirection Typen:

• Shared
  • Gemeinsam verwendeter Registry Key.
• Redirected
  • 32-Bit / 64-Bit Registry Schlüssel sind separat.
• Reflection
  • Aus Interoperabilitätsgründen synchronisiert das Betriebssystem gewisse Keys zwischen den Ansichten.

Letztere Methode kann man mit diesem Attribut deaktiviert werden, da dieses Verhalten nicht immer erwünscht sein muss.

Ab Windows 7 / 2008 R2 wurde das Registry Reflection Feature entfernt. Damit wird diese Option für diese Betriebsysteme überflüssig.

Weiterführende Information zum Thema Registry Reflection im Microsoft Developer Network

msidbComponentAttributesUninstallOnSupersedence (Uninstall on supercedence)

Dieses Attribut ist lediglich für  die „Small Patch“ Thematik relevant.

Wir erläutern das ganze einfachheitshalber mit einem praktischen Beispiel:

Wir installieren das Produkt A welches die Komponente Y beinhaltet.

Wir installieren den Patch 1 für das Produkt A, welches als Neuerung eine neue Komponente namens Komponente Z mitliefert. Das Produkt A besteht nun aus Komponente Y & Z

Nun kommen wir zu Patch 2, welcher Patch 1 „superseded“ also ersetzt bzw. überflüssig macht.
Komponente Y wurde in dieser Version aktualisiert und machte dadurch Komponente Z welche in Patch 1 hinzugefügt wurde überflüssig.

Installiert man Patch 2 über das Produkt mit Patch 1 ergibt sich folgendes Resultat:

Aktualisierte Komponente Y.
Komponente Z ist physisch (Files) immer noch vorhanden.

Installiert man hingegen Patch 2 direkt über das Produkt ohne vorher Patch 1 zu installieren ergibt sich folgendes Resultat:

Aktualisierte Komponente Y.
Komponente Z wurde NIE installiert.

Aktiviert man nun bei einer Komponente das „Uninstall on supercedence“ Attribut, überprüft Windows Installer jeweils ob dieser noch notwendig ist & entfernt ihn gegebenen falls.

Bei unserem Beispiel würde das wie folgt aussehen:

In Patch 1 ist für Komponente Z das Attribut gesetzt.

Nun Installieren wir wieder Patch 2, allerdings schaut des Resultat nun anders aus:

Aktualisierte Komponente Y
Komponente Z wurde entfernt

Um das ganze besser veranschaulichen zu können haben wir ein Test-Set mit MSI & Patches realisiert, damit man das Attribut auch in Aktion erleben kann.

Download supersedence.zip

msidbComponentAttributesShared (Shared)

Dieses Komponenten Attribut stellt sicher, dass jeweils die aktuellste Version der Komponente zur Verfügung steht.
Wir erläutern das ganze einfachheitshalber mit einem praktischen Beispiel:

Zuerst wird Produkt A installiert, welches den gemeinsam verwendeten Komponenten Z in der Version 1.0 installiert.

Als nächstes Installieren wir Produkt B mit dem gemeinsam verwendeten Komponenten Z in der Version 1.1.

Nun Installieren wir für Produkt A den Patch X welches den gemeinsam verwendeten Komponenten Z auf die Version 1.2 hebt.

Aufgrund diverser Probleme entscheidet man sich Patch X für Produkt A wieder zu deinstallieren: Während diesem Vorgang wird wieder die alte Version von Komponent Z in der Version 1.0 wiederhergestellt.

Da Produkt B aber explizit auf die Version 1.1 setzt funktioniert dieses nun nicht mehr.

Sobald dieses Attribut bei einer Komponente aktiv ist, stellt Windows Installer jeweils sicher, dass die aktuellste Version eines gemeinsam verwendeten Komponenten auf dem System bleibt.

Wir empfehlen deshalb den Einsatz dieses Attributes für gemeinsam verwendete Komponenten, neben den üblichen “Always Increment shared .DLL Count” & “Leave installed on uninstall” Attributen.

Bei der Repaketierung von Applikationen welche die Visual C++ 2005 SP1  Runtimes benötigen sollte ein Augenmerk darauf gelegt werden, welche Version exakt benötigt wird.

Denn seit dem 28. Juli existiert eine aktualisierte Variante der “Visual C++ 2005 Sp1 Redistributable” (8.0.50727.4053) unter folgendem Link zum Download:

http://www.microsoft.com/downloads/details.aspx?familyid=766a6af7-ec73-40ff-b072-9112bab119c2&displaylang=en

Die aktuellste Version von Quicktime (7.6.5) verlangt beispielsweise explizit diese Runtime-Version.
Im Repaketierungsprozess darf man deshalb diese nicht einfach durch die normalen SP1 Merge Module (8.0.50727.762) ersetzen.

Die neuen Merge Module erhält man durch aktualisieren der Visual C++ 2005 Entwicklungsumgebung. Bei diesem Prozess werden die Merge Module im Verzeichnis” %CommonProgramFiles%Merge Modules” auf den neusten Stand gebracht.
Diese können dann ins repaketierte Projekt hinzugefügt werden und somit entfällt das Redistributable MSI als Installations-Voraussetzung.

Den Patch für die Visual Studio 2005 SP1 Entwicklungsumgebung steht hier zum herunterladen bereit:

http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=7c8729dc-06a2-4538-a90d-ff9464dc0197

Mehr Hintergrundinformationen zur aktualisierten Version gibt es unter folgendem Link:

http://www.microsoft.com/technet/security/bulletin/MS09-035.mspx

In unsere Serie “Ontrex Best Practices” präsentieren wir regelmässig Packaging Best Practices aus dem Hause Ontrex.

Die ersten “Best Practices”,  die wir erläutern werden, sind:

• Nach leeren Komponenten überprüfen
• Launch Conditions

Nach leeren Komponenten überprüfen

Leere Komponenten können ein Software Paket in Teufels Küche bringen und je nach Konstellation sogar einen Endlos Selfrepair verursachen.

Das Vorhanden sein solcher Komponenten kann man durch 2 Methoden überprüfen:

1. Auf der Komponentenansicht ( alle Komponenten durchklicken, das heisst: erste Komponente anwählen und danach mit “Pfeil Unten” durch die gesamte Komponentenliste blättern. Verschwindet ein Plus, deutet dies auf eine leere Komponente hin und diese sollte somit gelöscht werden.
   
2. “Ontrex Like”, eine eigene Windows Installer Validierung programmieren.
   

Launch Conditions

Die LaunchCondition-Tabelle, sowie die zugehörige LaunchConditions Aktion,  dienen zur Überprüfung von Vorraussetzungen für die Installation. Falls die Conditions nicht erfüllt werden, bricht die Installation mit einer definierten Fehlermeldung ab.

Ein Beispiel hierfür: Ein “Office Plugin”-MSI überprüft zuerst, ob die Office Suite überhaupt installiert ist und gibt ansonsten eine Fehlermeldung aus, da es sonst keinen Sinn macht das Produkt zu installieren.

Leider vergessen viele beim Einsatz dieser Tabelle, das die Aktion LaunchConditions unkonditioniert ist und somit auch bei einer Reparatur oder Deinstallation durchgeführt wird.

Um das vorherige Beispiel weiterzuführen: Nach einer späteren Deinstallation des Office Paketes bemerkt man, dass noch das Plugin installiert ist und will dieses  mit deinstallieren. Die Deinstallation schlägt aber fehl mit der Begründung das Microsoft Office nicht installiert ist.

Doch wie begegnet man diesem Problem?

Unserer Meinung nach ist eine Konditionierung der LaunchConditions-Aktion mit “Not Installed” (Case Sensitive) am sinnvollsten.
Man sollte aber nicht vergessen, dies in der InstallSequence sowie in der InstallUISequence Tabelle anzupassen.