Archive for the 'Wise Package Studio' Category

Wise Package Studio 8: Network Client Update umgehen.

Published on March 8, 2010 in Best Practices, TECH and Wise Package Studio by Fabio Di Lorenzo. 0 Comments

Nach der Migration des Wise Package Studio Servers auf die Version 8.0 ist es leider auch nötig die Netzwerk Client Installationen zu aktualisieren.

Je nach Packaging Umgebung kann dies jedoch enormen Aufwand bedeuten.

Mit folgendem Trick kann man sich diesen Aufwand allerdings sparen:

- Installiere den Network Client der 8.0 Version auf einer sauberen VM/Client

- Exportiere danach den “Wise Solutions” Registry key. In diesem Key sind die neuen Lizenzinformation drin. Ohne diese lässt sich WPS 8.0 nicht starten.

- Erstelle ein neues WiseScript und füge mittels “Edit Registry” Aktion diese Keys hinzu

- Als 2 Aktion füge eine “Run Executable” Aktion hinzu, und zeige dort auf die  “PackageStudio8.exe” Executable auf dem Wise Package Studio Share.

- Kompiliere ein neues Executable und lege dies im Wise Package Studio Programmverzeichnis als “PackageStudio7.exe” ab

Nun wird bei alten Netzwerk Client Installationen die PackageStudio7.exe gestartet, welche die benötigten Registrierungsschlüssel für das Wise Package Studio 8 ins Benutzerprofil schreibt und danach die aktuelle PackageStudio8.exe startet.

 

WisePathReplacement

Published on February 3, 2010 in TECH and Wise Package Studio by Fabio Di Lorenzo. 0 Comments

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]\Stub\WiseApi.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

Exclusion Liste für Windows 7

Published on November 19, 2009 in Best Practices and Wise Package Studio by Stefan Hotan. 0 Comments

Die Software Repaketierung unter Windows 7 baut grundsätzlich auf die gleichen Repackaging Best Practices wie bei Windows Vista auf.

Aus unseren Erfahrungen, die wir bei Windows 7 Migrationprojekten gesammelt haben, empfehlen wir die Ausschlussliste-Liste mit folgenden Einträgen zu erweitern, um eine bessere Qualität des Deltas eines Snap-Shots unter Windows 7 zu erreichen.

Verzeichnis C:\Boot excl. Sub-Directory
Verzeichnis C:\Users\All Users excl. Sub-Directory
Verzeichnis C:\Users\AppData\Local\Temp excl. Sub-Directory
Verzeichnis C:\Users\AppData\LocalLow\Microsoft\CryptnetUrlCache excl. Sub-Directory
Verzeichnis C:\Users\All Users\Microsoft\RAC excl. Sub-Directory
Verzeichnis C:\Users\All Users\Microsoft\Search excl. Sub-Directory
Verzeichnis C:\ProgramData\Microsoft\RAC excl. Sub-Directory
Verzeichnis C:\ProgramData\Microsoft\Search excl. Sub-Directory
Verzeichnis C:\Windows\ServiceProfiles excl. Sub-Directory
Verzeichnis C:\Windows\System32\LogFiles excl. Sub-Directory
Verzeichnis C:\Windows\System32\winevt\Logs excl. Sub-Directory
Datei ntuser.dat.LOG1 File/Wildcard
Datei UsrClass.dat File/Wildcard
Datei UsrClass.dat.LOG1 File/Wildcard
Registry HKCU Software\Classes\Local Settings\MuiCache Ignore entire subtree
Registry HKCU Software\Classes\Local Settings\Software\Microsoft\Windows\Shell Ignore entire subtree
Registry HKLM SOFTWARE\Microsoft\Windows Search Ignore entire subtree
Registry HKLM SOFTWARE\Microsoft\Reliability Analysis\RAC Ignore entire subtree
Registry HKLM SOFTWARE\Microsoft\Windows NT\CurrentVersion\SPP Ignore entire subtree
Registry HKLM SOFTWARE\Microsoft\Windows NT\CurrentVersion\SystemRestore Ignore entire subtree
Registry HKLM SYSTEM\CurrentControlSet\services\VSS Ignore entire subtree
Registry HKLM COMPONENTS Ignore entire subtree
Registry HKLM Schema Ignore entire subtree

Weitere Informationen, was bei einer Windows 7 Migration zu beachten ist, können Sie an unserem User Group Meeting erfahren.
Nebst verschiedenen Keynotes zu aktuellen Themen erwarten Sie Technologie- und Produkte-News sowie Live Demos und Praxisberichte. Nutzen Sie die Gelegenheit sich effektiv zu informieren und mit Fachkollegen und Spezialisten zu diskutieren.

usergroup

Internal Error 2709

Published on November 11, 2009 in Best Practices and Windows Installer by Stefan Hotan. 0 Comments

Die Windows Installer 2709 Fehlermeldung ist eine Benachrichtigung, die bei einer Update Installation erscheinen kann. Wird eine betroffene Installation auf einer Clean Machine installiert, so sieht alles gut aus, keine Fehlermeldung erscheint. Sollte die gleiche Installation als Update Installation durchgeführt werden, so erscheint die 2709 Fehlermeldung. Interessant dabei ist, das der Test auf einer Clean Machine eigentlich das gleiche Problem haben sollte, das Problem aber aus internen Abläufen der Windows Installer Session automatisch korrigiert wird.

2709

Das Problem kann unter anderem durch ein Setup-Capture mit Wise Package Studio entstehen, wenn Dateien mit Merge Modulen ersetzt werden. Wie in diesem Beispiel wurde die Datei comdlg32.ocx durch ein Merge Module von Microsoft ersetzt. Dieser Vorgang löscht jedoch nicht die Verweise der bereits erstellten Componenten in der FeatureComponents Tabelle.

FeatureComponent
Komponenten die während einem Setup-Capture mit einem Merge-Module ersetzt wurden, bleiben in der FeatureComponents Tabelle zurück

Das etwas mit diesen Komponenten nicht stimmt, wird in der Tabellenansicht des Windows Installer Editors ersichtlich. Werden diese Einträge übersehen, so wird auf diesen Misstand während der Validierung darauf hingewiesen:
Not a valid foreign key; Table: FeatureComponents, Column: Component_, Key(s): Complete.comdlg32.ocx ice03.html FeatureComponents Component_ Complete comdlg32.ocx
Evaluation: ICE03

Diese Einträge sind aus der FeatureComponents Tabelle zu löschen. Es kann jedoch vorkommen, das die Validierung aus unbekannten Gründen bei dieser Überprüfung fehlschlägt und keine Probleme angezeigt werden. Bei einem anschliessenden Testdurchlauf der Installation wird keine Fehlermeldung erscheinen, da die Windows Installer Session diese fehlerhaften Einträge überspringt.

Doing action: InstallValidate
Feature: Complete; Installed: Absent;   Request: Local;   Action: Local
Component: CreateFolder; Installed: Absent;   Request: Local;   Action: Local
Component: registry44; Installed: Absent;   Request: Local;   Action: Local
Component: findmsm.exe; Installed: Absent;   Request: Local;   Action: Local

Während der InstallValidate Aktion werden die betroffenen Komponenten ausgewählt, die fehlerhaften Einträge werden einfach übergangen.

Soweit scheint alles zu funktionieren, bis zu dem Tag, an dem mit der gleichen Installation ein Update durchgeführt wird. Bei einer Update Installation wird zusätzlich die MigrateFeatureStates Aktion durchgeführt. Diese überprüft die Stati der bereits Installierten Features und vererbt die Feature States bei der Update Installation (Die Vererbung von Feature Stati kann mit der Upgrade Tabelle deaktiviert werden). Die Aktion  MigrateFeatureStates übergeht  die fehlerhaften Einträge in der FeatureComponents Tabelle jedoch nicht und wird mit der Fehlermeldung 2709 die Installation abbrechen.

DEBUG: Error 2709:  The specified Component name (‘comdlg32.ocx’) not found in Component Table.

In diesem Fall sind in der Installation die fehlerhaften Einträge in der FeatureComponents Tabelle zu beheben. Wir empfehlen diese Überprüfung in die Best-Practices von Software-Paketierungs Guidelines aufzunehmen, um diesem Problem zuvor zukommen.

%HOMEDRIVE%%HOMEPATH% – MSI Error 1324

Published on August 6, 2009 in Best Practices by Stefan Hotan. 0 Comments

Es muss nicht gleich zum Windows Installer Error 1324 kommen, doch woher kommt bei einer Installation die %HOMEDRIVE%%HOMEPATH% Information?

Diese Frage und deren Auswirkungen sind Imgrunde einfach zu verstehen.

Ursache:
Die System-Variablen im Shortcut werden vom Explorer aufgelöst und die Applikation, welche in der Regel Per-Machine installiert wurde und deren Shortcut sich ebenfalls im AllUsers Profil befindet, wird das aktuelles Arbeitsverzeichnis des Benuters genommen. Damit kann der Softwarehersteller ohne grosse Mühe eine Per-Machine Installation durchführen, ohne eigene Shortcuts für jeden Benutzer erstellen zu müssen.

Wirkung:
Bei einer standard Installation von Windows wird dieses Verzeichnis direkt ins Root des aktuellen Benutzerprofils zeigen. Dieser Umstand ist nicht optimal, da keine Dateien ins Root des Benutzerprofiles geschrieben werden sollen. Eine Alternative in diesem Fall wäre %APPDATA%, sofern die Daten Roamen dürfen.

Je nach AD und GP Umgebung werden diese beiden System-Variablen auf ein Verzeichnis eines Datei-Servers umgebogen, dann sind diese Variablen durchaus gebrauchtbar.

Umsetzung nach einem Snap-Shot:
Nach einem Snap-Shot mit Wise Package Studio befindet sich der Pfad in der Directory Tabelle.

HomeDirectory

Solange dieser nur als WorkingDir in der Shortcut Tabelle verwendet wird, besteht kein Anlas diesen zu änderen.

Wenn nun jedoch dieses Verzeichnis auch noch anderweitig in der Intallation verwendet wird, dann können grössere Probleme nicht ausgeschlossen werden. Ein bekanntes Problem zeichnet sich mit dem Windows Installer Error 1324 ab.

Bei diesem Fehler muss das Problem über die Directory Tabelle gesucht und gelöst werden. Die %HOMEDRIVE%%HOMEPATH% Variablen sind nichts anderes als der ProfilesFolder Eintrag in der Directory Tabelle, welcher seit Wise Package Studio SP3 auch dem Paketierer zur Verfügung steht.

Wer diese Variablen bei einem Shorcut aus der Diretory Tabelle bekommen möchte, kann folgender Weg einschlagen:

1. Den Eintrag in der Directory Tabelle löschen, sofern nur Abhängigkeiten zum WkDir in der MSI Datei besteht.

2. Das WkDir in der Shortcut Tabelle auf eine eigene (PublicProperty) Variable verweisen.
HomeShortcut

3. Diese Variable in der Property Tabelle einrichten.
HomeProperty

Das Endresultat ist wohl gleich, doch die Bereitstellung der Daten ist verfolgt einen schöneren Weg.

Stefan Hotan
A member of the Ontrex SPA Team

Schöner Wise-Scripten

Published on July 1, 2009 in Best Practices and Wise Package Studio by Tino John. 0 Comments

Neben der Erstellung von MSI-Paketen bietet Wise Package Studio noch nützliche andere Funktionen. Ich greife heute die vergleichsweise einfache Implementierung von mächtigen Scripts mittels Wise Script heraus.

Durch die Bedienung des Editors via Drag&Drop sind syntaktische Fehler im Quellcode fast unmöglich, einfacher kann man beispielsweise Änderungen an INI-Dateien, Registry-Einträge oder Pfadvariablen automatisiert kaum vornehmen.

Durch Kompilieren des Scripts wird dann eine EXE-Datei erstellt, die ohne weitere Runtimes auf Windows-System lauffähig ist.
Einen Schönheitsfehler hat ein kompiliertes Wise Script dennoch: Den blauen Hintergrund zur Laufzeit.

Kompiliertes Wise Script mit blauem Hintergrund

Dieses Problem lässt sich umgehen, indem man das WSE-Projekt in einem beliebigen Editor, beispielsweise Notepad, öffnet und folgendes Bit “kippt”:

Wise Script in Notepad

Nachdem die vorletzte “0″ in der Zeile “Windows Flags” in “1″ geändert wurde, muss das WSE-Projekt gespeichert und erneut mit dem Wise Script Editor kompiliert werden.
Nun läuft die EXE-Datei ohne störenden blauen Hintergrund ab.

Wise Script ohne blauen Hintergrund

Tino John
Member of the Ontrex SPA Team

This Windows Installer file contains upgrade information

Published on June 11, 2009 in Message Boxes and Wise Package Studio by Stefan Hotan. 0 Comments
Im zweiten Blog über die Wise Nachrichtenfenster, möchte ich auf das ‘This Windows Installer file contains upgrade information. Do you want to search your datasource for the packages to use when creating components?’ eingehen.
upgradeinformation
Die Ursache:
Dieses Fenster erscheint, wenn die Installation Einträge in der Upgrade Tabelle hat.
Warum:
Bei den Anfangszeiten der Windows Intaller Technologie stand die Performance einer Installation sowie deren weiteren Aktionen wie Repapartur, Deinstallation und Update im Vordergrund. Beim Update war das ursprüngliche Ziel, zuerst die neue Version einer Applikation zu installieren und erst danach die alte Version zu deinstallieren. Dies hat zwei Vorteile. Erstens würde bei einem Installationsproblem der neuen Version der Rollback die alte Version wieder herstellen, somit kann der Anwender noch mit der alten Version arbeiten. Zweitens würde bei der Deinstallation der alten Version Zeit gesparrt werden, da nicht alle Dateien deinstalliert werden müssen. Leider hat sich dieses Wunschdenken bis heute nicht durchgesetzt. Alte Installationen werden zuerst Deinstalliert und danach wird die neue Version einer Applikation installiert. Die vielen kleinen technischen Details verhindern oder verunmöglichen es den Applikationsentwickler nach Windows Installer Vorgabe den Update zu erstellen.
Der Wise Windows Installer Editor geht von der ursprünglichen Art des Updates von Microsoft aus (neue Version installieren, alte Version deinstallieren), daher finden wir in den Grundeinstellungen die RemoveExistingProducts Aktion am Ende der InstallExecuteSequence Tabelle.
removeexistingproducts
Die Nachrichten Box selber bedeutet, wenn bei einem Update eine Komponente erstellt wird, so wird der Windows Installer Editor versuchen in alten Installationen diese Komponente zu suchen und bei einem Treffer dessen KomponentenID zu übernehmen.
Best Practices:
Die Antwort zu dieser Frage können Sie mit der RemoveExistingProducts Aktion beantworten. Ist diese in der Installation am Ende der InstallExecuteSequence Tabelle dann können Sie die Frage mit ‘Ja‘ beantworten. Wenn Sie die RemoveExistingProducts Aktion zum Anfang der Installation verschoben haben, oder im Generellen alle alten Intallationen vor einem Update deinstallieren (dies ist die Best Practices), dann können Sie die Frage mit  ’Nein‘ beantworten.
Sollten Sie ausversehen auf ‘Ja‘ gedrückt haben, so passiert nicht besonders viel. Sie verlieren etwas Rechnerzeit, was sich jedoch bei heutigen Systemen nicht wirklich bemerkbar macht. 
Hide Message:
Erstellen Sie folgenden Registry-Key bei der Installation von Wise Package Studio oder Wise Installation Studio, damit diese Meldung nicht erscheint:
HKCUSoftwareWise SolutionsWindows Installer EditorHideMessages
Name: 405
Type: REG_DWORD
Value: 7
Stefan Hotan
Member of the Ontrex SPA Team

Einfacher Weg zum LocalLow Verzeichnis

Published on May 7, 2009 in Best Practices and Datei System by Stefan Hotan. 0 Comments

Mit der Einführung der Integrity Access Level (IL) Funktionalität unter Windows Vista und Windows 7, wurde ein neues Verzeichnis, das LocalLow Verzeichnis eingeführt.

Das LocalLow Verzeichnis wir für Prozesse verwendet, die als Low-Level Prozess ausgeübt werden. In der Regel betrifft dies Prozesse, welche unter dem Internet Explorer Prozess gestartet werden, wie das Apple Quicktime Plugin oder Sun Java Runtime Environment. Diese Prozesse können nur noch Dateien in diesem Ordner schreiben oder modifzieren.

Wird eine Applikation repaketiert, welche in diesem Ordner eine Datei erstellt, dann wird schnell klar, dass der Windows Installer Dienst dieses neue Verzeichnis nicht auflöst. Eigentlich gehört das LocalLow Verzeichnis wie die restlichen ‘Special-Folders’ aufgelöst. Das neue Verzeichnis jedoch ist weder in MSI 4.0, 4.5 noch 5.0 Bestandteil der Directory Tabelle.

Es gibt hierzu eine einfache Lösung, wenn Wise Package Studio 7 SP3 oder höher eingesetzt wird. Ab dieser Version von Wise Package Studio wird mit der CustiomAction WiseSetProfilesFolder das Root-Verzeichnis des aktuellen Benutzers aufgelöst (ebenfalls eine Schwachstelle des Windows Installer Dienstes). Aufbauend auf diesem Verzeichnis (ProfileFolder) kann nun mit zwei Einträgen in die Directory Tabelle das LocalLow Verzeichnis dynamisch aufgelöst werden.

 Das LocalLow Verzeichnis

Stefan Hotan
Member of the Ontrex SPA Team

ALLUSERS Profile Auflösung

Published on April 24, 2009 in Best Practices and Wise Package Studio by Fabio Di Lorenzo. 0 Comments

Das Wise Package Studio bzw. das SetupCapture Tool scheint Files/Ordner welche ins ALLUSERS Profile geschrieben werden nicht richtig aufzulösen (Eine Ausnahme bildet natürlich der CommonAppDataFolder Wert).

Bei einer Installation der repaketierten Applikation werden ohne Änderungen diese ins aktuelle Benutzerprofil des installierenden Users kopiert.

Um diesem Bug entgegen zu wirken baut man am besten folgende CustomAction im Immediate Bereich vor der CostFinalize Aktion ein:

screenie1

Diese „biegt“ den entsprechenden Directory-Table Eintrag auf die Envirenmontvariable %ALLUSERSPROFILE%, welches in den meisten Fällen ein zufriedenstellendes Resultat produziert.

Doch wieso existiert dieser Bug?

WPS scheint es gut zu meinen, und kreiert ein entsprechenden Eintrag in der Directory Table namens „ALL_USERS“, dieser basiert auf den Werten “ProfilesFolder” & “All Users”.
ProfilesFolder wird aber zur Laufzeit auf das Userprofiles des Benutzers aufgelöst, was natürlich nicht das gewünsche Resultat ist.

Fabio Di Lorenzo
Member of the Ontrex SPA Team

Type 1 Fonts Registration mit Windows Installer

Published on February 27, 2009 in Fonts and Wise Package Studio by Stefan Hotan. 0 Comments

Die Windows Installer (MSI) Datei hält eine Font Tabelle für die Installation von Schriften bereit. Diese ermöglicht den manuellen Registrationsprozess für eine Schrift zu automatisieren. Der manuelle Weg ist bestens bekannt, einfach mit drag-and-drop die Schriften-Dateien ins Fonts Verzeichnis verschieben und gut ist.

Wenn man das gleiche mit einer Postscript Schrift (PFM und PFB Datei) durchführt,  so ist dies bei einer manuellen Registration kein Problem. Will man diesen Vorgang jedoch repaketieren, also über das Snap-Shot Verfahren aufzeichnen, so wird die Schriftart erst nach einem Neustart des Rechners ansprechbar.

Der Grund für dieses Verhalten liegt in der Tatsache, dass die Font Tabelle nur für TrueType Schriften (.TTF Dateien) gedacht ist. Diese Tabelle ist nicht mit Postscript Schriften kompatibel.

Der Snap-Shot der Registration wird pro Schriftart einen Registry-Key erstellen:
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionType 1 InstallerType 1 Fonts
Name der Schrift, T[~]<Datei>.PFM[~]<Datei>.PFB
Dieser Eintrag in der Registry ist soweit in Ordnung, nach der Installation ist die Schrift registriert, jedoch nicht aktiviert. Ein Reboot wäre in diesem Fall nötig.

Was aber, wenn man nach der Installation direkt auf die neue Schriftart ohne Reboot zugreiffen will?
Dies ist technisch möglich, benötigt jedoch einen API-Call auf die Datei atmlib.dll, sprich eine Custom Action muss her.

Eine Möglichkeit diesen API-Call durchzuführen ist die verwendung des Wise Script Editors.
Folgender Print-Screen zeigt die benötigte ‘Call DLL function’:

 

wisescript3

Das erste Argument übergibt den Schriften-Namen, der zweite definiert den Schrift-Typ, der dritte und vierter die Schrift. Die benötigten Informationen kann man beim Snap-Shot aus der Registry entnehmen.
Die kompilierte .EXE Datei ist danach im Deferred Context der Installation durchzuführen. Nach der Installation steht die Postscript Schriftart sofort dem Endanwender zur Verfügung.

Die Dateierweiterung PFM steht für Postscript Font Metrich und die PFB Datei steht für Postscript Font Binary. Beide Dateien müssen ins Fonts Verzeichnis kopiert werden, bevor der API-Call durchgeführt wird. Bei Postscript Schriften können auch noch AFM (Adobe Font Metric) und INF (Type I LaserJet font information) beiliegen, welche nicht benötigt, oder einfach mit ins Fonts Verzeichnis kopiert werden können.

Stefan Hotan
Member of the Ontrex SPA Team