Category Archives: Tools

MSI Patch – Feature Level 0 Effekt

September 30, 2009 08:47 ⋅ Leave a Comment ⋅

Die Anzahl von Programmupdates, die auf Microsoft Windows Installer Patch-Dateien (.MSP) aufbauen, nehmen kontinuierlich zu. Dabei können Patch-Dateien auf unterschiedliche Wege ein Produkt aktualisieren.

Die folgenden Details zu einer Administrativen-Installation (Netzwerk-Installation) sind ein Bestandteil aus unserer Windows Installer Schulung ‘Schwarzgurtpaketierung’, die wir ab nächstem Jahr in unser Kursprogram aufgenommen und kürzlich als Power-Workshop im grösseren Kundenumfeld präsentiert haben.

Eine Möglichkeit der Patch-Integration ist eine Admin-Installation durchzuführen und diese mit einer Patch-Datei zu aktualisieren. Die aktualisierte Windows Installer Installation kann sowohl auf neuen Rechnern installiert werden, sowie bestehende Installationen über einen Reparatur-Zyklus auf den neuen Stand bringen.

In den meisten Fällen muss von der Original-Installation eine Admin-Installation durchgeführt werden (msiexec.exe -a datei.msi). Obwohl dies eine ‘High-Level’ Aktion ist, also eine grundlegende Windows Installer Funktion, ist dies keine Garantie dafür, dass der Software-Hersteller diese vollumfänglich unterstützt.

Ein Seiteneffekt kann die Feature Level 0 Problematik sein. Diese führt dazu, dass nicht alle Dateien extrahiert werden, da die Condition Tabelle bei einer Admin-Installation nicht abgearbeitet werden.
Es ist also vor einer Admin-Installation darauf zu achten, ob in der Feature-Tabelle ein Feature mit dem Level 0 existiert. Sollte dieses Feature-Level während einer normalen Installation geändert werden, so ist vor der Admin-Installation der Wert des Features zu erhöhen und nach der Admin-Installation wieder zurück zu stellen. Danach kann die Patch-Datei integriert werden.

condition
Mit Hilfe der Condition Tabelle kann ein Software-Hersteller während der Installation ein Feature-Level anhand von Konditionen verändern. Dies geschieht jedoch nicht während einer Admin-Installation, was zu Dateiverlusten führen kann.

Weitere Informationen zu unseren Wise Kursen sind auf unserer Schulungsseite zu finden http://www.ontrex.ch.

Posted in: Windows Installer

%HOMEDRIVE%%HOMEPATH% – MSI Error 1324

August 6, 2009 16:25 ⋅ Leave a Comment ⋅

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

Posted in: Best Practices

Side-by-side configuration is incorrect

July 30, 2009 14:05 ⋅ Leave a Comment ⋅

In letzter Zeit ist die Meldung ‘The application has failed to start because its side-by-side configuration is incorrect’ anzutreffen. Dies bei Windows Vista ohne SP2.

VistaError

Wer versucht das Problem über die Ereignisanzeige zu lösen, wird sich in den Tiefen von .Net wohl verirren.

Ich möchte hier nicht wirklich tiefgründig werden, da dieses Problem mit SP2 oder Windows 7 behoben wurde, braucht man lediglich unter Windows Vista SP1 die folgenden zwei Hotfixes zu installieren:
Windows6.0-KB958481-x86
Windows6.0-KB958483-x86

Nach der Einspielung dieser Hotfixes wird die Applikation funktionieren.

Stefan Hotan
A member of the Ontrex SPA

Posted in: .NET Framework, Operating System

RegSvr32 failed – Invalid access to memory location

July 20, 2009 13:41 ⋅ Leave a Comment ⋅

Und auf einmal war sie da – Die Meldung ‘LoadLibrary .dll failed’ die nie zuvor gesehen war.

regsvr32

Das Analysieren mit dem Dependency Walker jedoch zeigt keinerlei Probleme mit dieser Datei, denn es handelt sich um eine Sicherheitserweiterung des Betriebssystemes. Die Data Execution Prevention (DEP) ist für diesen Umstand verantwortlich. DEP wurde gegen Viren und andere sicherheitsrelevanten Funktionen entwickelt. Unter anderem wird DEP die Registration von 16-bit COM Objekten verhindern.

In der Repaketierung kann dieses Problem behoben werden, indem die Self-Registration über die Registry-Tabelle durchgeführt wird.
Um die DLL oder OCX Datei wieder registrieren zu können, muss DEP konfiguriert werden. Die Konfiguration zu DEP findet man unter ‘System Properties’ – ‘Performance’.
Unter ‘Data Execution Prevention’ ist die Option ‘Turn on DEP for all programs and services except those I select:’ anzuwählen und die RegSvr32.exe im System32 Ordner zu wählen.

DataExecution Prevention

Mit dieser Einstellung kann nun die Self-Register Information ausgelesen werden und die entsprechende Registration über die Windows Installer Tabellen erfolgen. Auf diese Weise muss bei den Endanwendern keine DEP Konfiguration durchgeführt werden.

Stefan Hotan
A member of the Ontrex SPA

Posted in: Operating System

Schöner Wise-Scripten

July 1, 2009 07:44 ⋅ Leave a Comment ⋅

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

Posted in: Best Practices, Wise Package Studio

Verzögerter Start eines Dienstes dank MsiServiceConfig Tabelle

June 25, 2009 14:04 ⋅ Leave a Comment ⋅

Ab Microsoft Windows Installer 5.0 kann die MsiServiceConfig Tabelle verwendet werden, um einen Dienst verzögert zu starten.
Der Service Control Manager (SCM) wurde mit dieser Option in Windows Vista erweitert.
Mit der MsiServiceConfig Tabelle können diese neuen Funktionalitäten des SCM für einen Dienst konfiguriert werden.

Einen Dienst verzögert zu starten soll helfen die Zeitspanne eines Systemstartes zu optimieren. Wenn ein Dienst nicht unmittelbar zum Zeitpunkt des System Start benötigt wird, so kann dieser zu einem späteren Zeitpunkt  gestartet werden. Ein Dienst der verzögert gestartet wird, wird innerhalb von 2 Minuten nach dem System Start gestartet. Ein Setup Autor kann nun bei einem Dienst entscheiden, ob dieser sofort zur Verfügung stehen muss, oder ob es sich um einen Dienst einer Anwendung handelt, welcher auch zu einem späteren Zeitpunkt gestartet werden kann.

Der Dienst selber wird wie gewohnt über die ServiceInstall Tabelle installiert und über die ServiceControl Tabelle gestartet, ggf. gestoppt oder gelöscht.

Sollte die MsiServiceConfig Tabelle nicht im Schema der Installation sein, so kann die Tabelle mit Orca 5.0 oder einem Setup Authoring Tool (welches die Windows Installer 5.0 Technologie unterstützt) erstellt werden.

MsiServiceConfig

Die Felder sind für einen verzögerten Start wie folgt auszufüllen:

ServiceConfigure: ist ein Identifier
Name: Name des Dienstes der in der ServiceInstall Tabelle steht, oder der Name eines bereits installierten Dienstes.
Event: 1
ConfigType: 3
Argument: 1
Component_: Name einer Komponente aus der Installation

Der nächste und auch der letzte Punkt ist dem Windows Installer mit der MsiConfigureServices Aktion mitzuteilen, dass ein Service mit den neuen Optionen zu konfigurieren ist.

MsiConfigureServices

Die MsiConfigureServices Aktion wird zwischen der InstallServices und der StartServices gestellt.

Weitere Informationen zu den neuen SCM Funktionen:
http://msdn.microsoft.com/en-us/library/bb203962(VS.85).aspx

Stefan Hotan
Member of the Ontrex SPA Team

Posted in: Operating System, Services

Unable to merge new configuration

June 15, 2009 10:45 ⋅ Leave a Comment ⋅

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

Posted in: Merge Module, Windows Installer

Folder Redirection

June 11, 2009 10:56 ⋅ Leave a Comment ⋅

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

Posted in: Windows Installer

This Windows Installer file contains upgrade information

June 11, 2009 08:34 ⋅ Leave a Comment ⋅
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
Posted in: Message Boxes, Wise Package Studio

Einfacher Weg zum LocalLow Verzeichnis

May 7, 2009 10:08 ⋅ Leave a Comment ⋅

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

Posted in: Best Practices, File System