Unable to merge new configuration

Durch die Einführung des Dual-Token in Windows Vista müssen die Setup-Autoren bei der Erstellung von Custom Actions darauf achten, dass Aktionen, welche Änderungen an Per-Machine Ressoucen vornehmen, als In-Script (deferred) Aktionen unter dem System Kontext ausgeführt werden. Nur dadurch wird eine Aktion im Admin-Token durchgeführt.

Bei älteren Installationen kann es vorkommen, dass eine Aktion, welche mit Variablen (Properties) arbeitet, im Immediate Bereich der ExecuteSequence Tabellen ausgeführt wurden. Ab Vista werden diese zum Grösstenteil nicht mehr funktionieren, da diese nun im Standard LPU ausgeführt werden und dadurch zu wenig Rechte besitzen. Im Grunde genommen ist dies auch der richtige Ansatz, denn spätestens bei einem Self-Repair einer Installation mit Standard Benutzerrechten unter Windows XP hätte diese Aktionen das gleiche Problem wie in einem Dual-Token Umfeld.

Davon betroffen ist auch das Borland BDE Merge Module. Wenn diese Merge Module unter Windows Vista oder Windows 7 verwendet wird, so bleibt die Installation mit der Meldung ‘Unable to merge new configuration. Use BDE Amdinistrator to merge your new configuration.’ stehen. Das Fenster muss manuell geschlossen werden.

Unable to merge new configuration

Die Frage stellt sich nun, was muss getan werden, um dieses Problem zu lösen. Die Antwort jedoch fällt nicht so einfach aus.
Wenn man die Log-Datei der Installation ansieht

Doing action: BDEConfig.E966F0CB_76B3_11D3_945B_00C04FB1760A

dann wird dieses Fenster durch die BDEConfig Aktion verursacht. Die Aktion wird nach InstallFinalize im Immediate, sprich im Standard LPU ausgeführt, und dafür ist die Aktion nicht vorgesehen. Leider wurde der Support für die BDE Technologie schon seit einem Jahrzehnt eingestellt. Mittlerweile kann man sogar das Merge Module nicht mehr herunterladen, geschweige denn eine aktuelle, verbesserte Version von Borland beziehen.

Damit die Installation unter Vista ohne die Dialog-Box durchläuft, muss die Kondition in der InstallExecuteSequence Tabelle abgeändert werden. Dieser Eingriff sollte direkt im Merge Module vorgenommen werden (ModuleInstallExecuteSequence Tabelle).

BDE Config Image

Mit dem Zusatz ‘AND VersionNT < 600’ wird die Aktion nur noch unter Betriebssystemen vor Windows Vista durchgeführt.

Durch diesen Eingriff wird die BDEMERGE.INI nicht mehr abgearbeitet. Das lässt sich leider nicht verhindern. Diese Funktion muss nachgebaut, sollten Änderungen in der idapi32.cfg vorgenommen werden.

Eine Möglichkeit bietet das Wise Installation System 9, es beinhaltet Funktionen wie Add BDE Alias (Da der BDE Support eingestellt wurde, sind die BDE Funktionen in den aktuellen Versionen des Wise Installation System nicht mehr vorhanden).

Eine weitere Möglichkeit bietet die idapinst.dll. Diese DLL beinhaltet die Funktionen wie MergeCfg oder AddAlias. Die Dokumentation über diese Funktionen sind heute so gut wie unauffindbar. Mann spürt hier ganz klar, dass der Support von BDE schon lange eingestellt wurde.

Wenn nun alle Stricke reissen sollten, dann wäre eine weitere Möglichkeit das betroffene Programm zum Beispiel mit SVS oder APP-V zu virtualisieren, da dadurch eine eigenständige idapi32.cfg verwendet werden kann.

Stefan Hotan
A member of the Ontrex SPA Team

Folder Redirection

Vor allem im Corporate IT Umfeld ist es eine bekannte Gewohnheit gewisse „spezielle“ Verzeichnisse (Special Folders) via Group Policy auf Netzlaufwerke auszulagern (Folder Redirection).  Einige Beispiele hierfür sind:

MSI Property Bezeichnung Standardeinstellung englisches Windows XP
Beispiel Redirection Pfad
AppDataFolder Application Data C:Documents and SettingsUSERNAMEApplication Data myserveruserhomes$USERNAMEApplication Data
PersonalFolder My Documents C:Documents and SettingsUSERNAMEMy Documents myserveruserhomes$USERNAMEMy Documents

Diese werden dann je nach verwendeter Architektur mittels Offline-Folders Mechanismus mit dem Client synchronisiert.

Der Windows Installer mag diese Gegebenheit vom Design her nicht, insbesondere wenn diese Lokationen nicht zur Verfügung stehen.

Der Windows Installer initiiert nämlich während der CostFinalize Aktion die gesamte Directory Tabelle und überprüft dabei  die Verfügbarkeit sämtlicher dieser Verzeichnisse, d.h ob sie existieren, beschreibar sind etc.

Ein praxisbezogenes Beispiel: Ein Notebook Benutzer ruft im Hotel zum ersten mal den VPN Client auf, welches ein Self-Repair verursacht damit die Benutzerkonfiguration per-User installiert wird.

Während dieses Self-Healings (gilt auch für ActiveSetup oder Repair) wird diese Überprüfung der „umgeleiteten“ Lokationen in einem Fehler enden, da er nicht auf das Netzlaufwerk  zugreifen kann und somit diese “special folders” überprüfen kann. Folgende Fehlermeldung erscheint:

untitled

Das Programm lässt sich dann überhaupt nicht mehr über die advertised Shortcuts aufstarten.

Lösung

Falls die „Special Folders“ nicht dringend benötigt  werden, also z.B keine Dateien in diesen Ordnern platziert werden müssen, sollte man diese aus der Directory Table löschen.
Der Windows Installer wird dann beim Self-Healing/Active Setup nicht mehr versuchen diese zu überprüfen.

Fabio Di Lorenzo
Member of the Ontrex SPA Team

This Windows Installer file contains upgrade information

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

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

Windows Installer Error 1941

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.

Windows Installer Error 1941

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

ALLUSERS Profile Auflösung

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

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

Obsolete default merge module directory

Wer kennt diese Meldungen von Wise Produkten schon nicht? Immer wieder kommt es vor, dass Produkte von Symantec Wise Package Studio oder Wise Installation Studio mit einem Nachrichtenfenster daherkommt, wo man die Nachricht zweimal lesen muss, aber nicht wirklich den Sinn dieser Nachricht versteht.
Ich möchte an dieser Stelle in unserem SPA-Teamblog, alle Nachrichtenfenster, die von Wise Produkten erstellt werden, und deren Bedeutung nicht ohne Hintergrundwissen zu verstehen sind, aufgreiffen und den Grund der Meldung, sowie die Best Practices aufzeigen.
Im ersten Blog über die Wise Nachrichtenfenster, möchte ich auf das ‘This installation contains references to an obsolete default merge module directory. Do you want to automatically change these references to the new default directory?’ eingehen.
obsoltemergemodule1
Die Ursache:
Dieses Fenster erscheint, wenn die Installation Dateien in ein ‘Modules’ Verzeichnis kopiert.
Warum:
Der Wise Windows Installer Editor geht davon aus, das die WSI Projekt Datei mit einer alten Version erstellt wurde, wo die Referenz in das Merge Module Verzeichnis noch ‘Modules’ genannt wurde.
Die Auswirkung:
Sollten Sie diese Frage mit ‘Ja’ beantworten, so werden in der WiseSourcePath Tabelle alle Dateien, die in das Modules Verzeichnis zeigen, in das Merge Module Verzeichnis des Windows Installer Editors umgebogen.
module1
Diese Änderung ist fatal, Sie können danach die Installation nicht mehr kompilieren, da die Quelldateien im Merge Module Verzeichnis gesucht werden.
Best Practices:
Wenn Sie mit einer aktuellen Version des Windows Installer Editors arbeiten, so können Sie die Frage mit ‘Nein‘ beantworten. Sie müssten eine schon sehr alte Wise Projekt Datei öffnen, wo dieses Problem nach einem Update des Windows Intaller Editors bestehen könnte.
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: 34650
Type: REG_DWORD
Value: 7
Stefan Hotan
Member of the Ontrex SPA Team

Applikation startet nicht nach .NET Installation

Seit im Jahr 2006 das Microsoft .NET Framework 2.0 installierbar ist, können ältere Programme, die mit dem .NET Framework 1.0 oder 1.1 entwickelt wurden, nach der .NET Framework 2.0 installation, auf einmal nicht mehr starten.

Der Grund liegt in der Programmierung selber. Da das .NET Framwork die Side-by-Side Technologie unterstütz, werden Programme in der .NET Version ausgeführt, worin diese entwickelt worden sind. Nach Microsoft Richtlinien, ist der Applikation anzugeben, mit welchem .NET Framework diese ausgeführt werden kann. Leider gibt es fehlbare Applikationen, die diese Information nicht beinhalten (sogenannte Unmanaged Applications) und diese Applikationen bekommen Probleme, sobald eine neuere Version von einem .NET Framework auf den PC installiert wird.

Um dieses Problem zu lösen, empfiehlt es sich, eine aktuelle Version der Applikation zu verwenden. Dieses Problem tritt vorallem bei Applikationen die vor der Veröffentlichung des .NET Framework 2.0 herausgegeben wurden.

Ist keine neuere Version erhältlich, so kann eine .Config Datei erstellt werden, welche dem Betriebsystem angibt, mit welchen .NET Framework die Applikation zu laufen hat.

Beispiel LiveLink 9.5:

Dateiname: alviewer.exe.config
Inhalt der Textdatei:

<configuration>
<startup>
   <supportedRuntime version=”v1.1.4322″ />
   <supportedRuntime version=”v1.0.3705″ />
</startup>
</configuration>

Mit diesem einfachen Trick, lassen sich ältere Unmanaged .NET Applikationen in einer Multi .NET Framework Umgebung betreiben.