Category Archives: Training

Ontrex Software Package Atelier Neuigkeiten

“Failed to set the archive file’s unique identifier” Fehler in Virtual Package Editor

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.



WisePathReplacement

Jedem der sich schon länger mit Wise Package Studio befasst wird sicher schon die WisePathReplacement Tabelle aufgefallen sein.

Was genau steckt hinter dieser nützlichen “Custom” Wise Tabelle?

Dank Ihr gibt es die Möglichkeit in der Registry Werte zu verändern, die der Windows Installer nicht direkt als Variablen unterstützt. Davon betroffen in der Repaketierung sind Verzeichnisse, die ohne Backslash enden und Pfade im 8.3 Format. Viele ersetzen diese einfach mit Windows Installer Verzeichnis-Variablen bzw. File-Keys, dies kann aber zu Problemen bei div. Applikationen führen. Dank der WisePathReplacement Tabelle und den dazugehörigen Custom Actions werden solche Information in der Registry Tabelle erkannt und mit dynamischen Werten modifiziert.

Die Erkennung der Werte in der Registry Tabelle geschieht nur während eines Setup-Capture Prozesses. Wenn Werte nachträglich ersetzt werden müssen, dann können Sie die WisePathReplacement Tabelle verwenden, müssen jedoch sicherstellen dass die benötigten Einträge in der CustomAction und InstallExecuteSequence Tabelle vorhanden sind.

Folgende Werte können Sie mit Hilfe der WisePathReplacement Tabelle modifizieren:

– Directory Properties ohne abschliessenden Backslash.
– Dynamische 8.3 Pfade

Die Konfiguration gestaltet sich sehr einfach (automatisch beim Setup-Capture):

In der WisePathReplacement Tabelle trägt man die Primär-Key‘s des gewünschten Registry Wertes ein und legt die gewünschte Funktion fest:

1 = Kein Backslash am Ende.
2 = Pfad in 8.3 Format konvertieren.
3 = Beide Funktionen vereint (1+2).

Das ganze führen wir natürlich mit einem praktischen Beispiel vor.

Wir haben ein Paket mit folgenden Registry Key‘s:

wpr_registry

Die Registry-Key Namen sollten jeweils selbsterklärend sein. Um den gewünschten Effekt zu erzeugen ergänzen wir die WisePathReplacement Tabelle:

wpr_wpr

Das Resultat nach der Installation ist wie folgt:

wpr_results

Während einem Setup Capture Prozess werden  die benötigten Custom Actions automatisch eingebaut. Bei einer manuellen Anpassung müssen die benötigten Custom Action nachgetragen werden:

  1. Wechseln Sie im “Installation Expert” auf die “Resources Ansicht”
  2. Klicken Sie auf “Add” um eine neue Resource hinzuzufügen.
    Die benötigte DLL für die Custom Actions befindet sich im Wise Package Studio Programmverzeichnis unter folgendem Pfad:
    [WisePath]StubWiseApi.dll
  3. Der Resource gibt man den Namen “Callwiseapi”.
  4. Im “Setup Editor” wechselt man nun auf die Tabellen Ansicht und springt zur CustomAction Tabelle.
    Erfassen Sie die folgenden Custom Actions wie ersichtlich:
    wpr_customaction
  5. Zum Schluss müssen noch die neu erfassten Custom Actions in der InstallExecuteSequence eingebaut werden. Fügen Sie folgende neue Zeilen hinzu:
    wpr_ies

Neue Komponenten Attribute in Wise Package Studio 8.0

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:

 

componenteAttribute

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.

Companion Files

Oft begegnet man in der Software Paketierung dem Problem, dass man eine unversionierte Datei ersetzen will, dies aber nicht immer auf Anhieb gelingt.

Der Grund ist meist schnell gefunden, die Datei wurde mittlerweile modifiziert oder aus anderen Gründen stimmt das Create/Modified Datum nicht mehr überein. Deshalb verhindern auch die Default File Versioning Rules das erfolgreiche Ersetzen der Datei.

Die Windows Installer Technologie bietet aber hierfür eine elegante Lösungsmöglichkeit an, welche leider oft in Vergessenheit gerät.

Companion Files, zu Deutsch: Begleit-Dateien, bezeichnet man Dateien in der Installation, bei denen man eine andere Datei als “Entscheidungsträger” definiert.

Beispiel:

Für userdata.usr (unversioniert) konfiguriert man “MyVersioned.dll” (versioniert) als “Entscheidungsträger”. Sofern MyVersioned.dll installiert wird (Beispiel: Höhere Version als bestehende MyVersioned.dll), wird auch userdata.usr installiert.

Wise Package Studio kann dies wie folgt realisiert werden:

  1. Man wechselt auf folgende Ansicht:
    “Setup Editor -> Tables -> File”
  2. Als nächster Schritt sucht man sich die unversionierte Datei heraus.
  3. Sobald man diese gefunden hat, öffnet man das DropDown Menu bei der Spalte “Version”.
    companion_files
  4. Bei der Spalte trägt man nun die gewünschte “Entscheidungsträger” Datei ein, diese sollte natürlich optimaler weise eine versionierte Datei sein.

Den Mechanismus in Aktion sieht man entsprechend in der Logfile:

File: C:Program FilesMyProjectuserdata.usr;    Overwrite;    Won’t patch;    Existing file is of an equal version    (Checked using version of companion: C:Program FilesMyProjectMyVersioned.dll)

Weiterführende Information gibt es natürlich wie immer im Windows Installer SDK:

http://msdn.microsoft.com/en-us/library/aa367997%28VS.85%29.aspx

Aktualisierte Visual C++ 2005 SP1 Merge Module

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

TcRTime    TcRTime    128        1    TCRtime.sys
TcIo    TcIo    128        1    TcIo.sys
TcPlc    TcPlc    128        1    TcPlc.sys
TcCam    TcCam    128        1    TCCam.sys
TcRouter    TcRouter    128        1    TCRouter.sys
TcIoPNet    TcIoPNet    128        1    TcIoPNet.sys
TcIoEth    TcIoEth    128        1    TcIoEth.sys
TcIoECat    TcIoECat    128        1    TcIoECat.sys

Wise Package Studio 8 Download

Das Wise Package Studio 8 wurde wie angekündigt am 29. Oktober 2009 veröffentlicht.

Kunden mit einem laufenden ‘Annual Upgrade Protection’ (AUP) können, nach erhalt des Registrierungscodes der per Email zugestellt wird, die neue Version über das Altiris License Management Portal herunterladen.
Es wird ein neuer Lizenzschlüssel benötigt, dieser kann im License Management Portal mit dem neuen Registrierungscode freigeschalten werden.

Für Evaluationzwecke kann eine Trialversion des Wise Package Studio 8  über die Symantec Homepage bezogen werden:
www.symantec.com/business/package-studio

Als langjähriger Wise Produkte Partner und Wise Added Value Reseller können wir bei einer Evaluation oder Upgrade des neuen Wise Package Studio professionelle Dienstleistungen anbieten.

Das Wise Package Studio 8 Getting Started Guide ist eine hilfreiche Dokumentation zur Installation einer Professional Edition im Serverumfeld.

Wise Package Studio 8 Ankündigung

Wise Package Studio geht mit dem nächsten Upgrade in die Runde 8.

Mit Wise Package Studio 8 wird die Unterstützung von Windows 7 gewährleistest sowie die Datenbank Anbindung mit SQL Server 2008 für die Professional Edition bereit gestellt.
Weiter wurden zahlreiche kleinere Bug-Fixes behoben und am SVS Package Editor  sowie am SOE Snapshot wurde die Hand angelegt.

Das Freigabedatum wird mit Ende diesem Monat erwartet womit wir eine ausführliche Liste von den Verbesserungen sowie den Erweiterungen bekannt geben können.
Als langjähriger Wise Value Added Reseller (VAR) können wir Ihnen gerne nähere Auskunft über die neue Version von Wise Package Studio geben.

Unsere Wise Schulung ist bereits auf die neue Version angepasst und wird mit dem Tag der Veröffentlichung mit der neuen Version von Wise Package Studio durchgeführt.

Ontrex Best Practices Part I

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.
    emptycomponent
  2. “Ontrex Like”, eine eigene Windows Installer Validierung programmieren.
    ICE

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.

launchconditions

Per User / Per Machine Installationen unter Windows 7

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:

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

Software Repaketierung unter Windows x64/64Bit

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.

regshot

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: