Aktualisierte Visual C++ 2005 SP1 Merge Module

Published on December 7, 2009 in Windows Installer by Fabio Di Lorenzo. 0 Comments

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

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.

Verzeichnisverfügbarkeit bei Custom Actions

Published on November 9, 2009 in Windows Installer by Stefan Hotan. 0 Comments

Nach den Regeln der alten Windows Installer Schule wird gelernt, das beim Einsatz von Custom Actions Verzeichnisse der Directory Tabelle erst nach der CostFinalize Aktion zur Verfügung stehen.
Demnach sollen Custom Actions, die mit Verzeichnis-Verweise arbeiten, erst nach der CostFinalize Aktion ausgeführt werden.

Die CostFinalize Aktion wird alle Verzeichnisse für die Windows Installer Session bereitstellen.
MSI (s) (F8:E8): Doing action: CostFinalize
MSI (s) (F8:E8): PROPERTY CHANGE: Adding TARGETDIR property. Its value is ‘C:\’.

Interessanterweise kann bei der AppSearch Aktion mit Verzeichnissen wie WindowsFolder und ProgramFilesFolder gearbeitet werden obwohl diese vor der CostFinalize Aktion ausgeführt wird. Dementsprechend gibt es Verzeichnisse die schon vor der CostFinalize Aktion verwendet werden können.

Bei der Analyse einer Log-Datei wird ersichtlich, das vor der INSTALL Session, also noch bevor überhaupt eine Aktion ausgeübt werden kann, alle SpecialFolders (Magic Folders) aufgelöst werden und danach sofort zur Verfügung stehen.

Mit dem APICall SHGetFolderPath werden SpecialFolders aufgelöst.
MSI (s) (F8:E8): SHELL32::SHGetFolderPath returned: C:\Documents and Settings\Administrator\Application Data

Bei der Analyse der Log-Datei, sieht man jedoch den WindowsFolder, SystemFolder und den ProgramFilesFolder nicht aufgelistet. Diese Verzeichnisse stehen wie die restlichen SpecialFolders bei Beginn der INSTALL Session zur Verfügung.

Somit lässt sich aussagen, das SpecialFolders von Beginn der Installation verwendet werden können und Verzeichnisse, welche die Installation selber erstellt, nach der CostFinalize Aktion.

Mit dieser Erkenntnis können viele Custom Actions, welche mit SpecialFolders arbeiten, schon vor der CostFinalize Aktion ausgeführt werden.

Wise Package Studio 8 Download

Published on November 2, 2009 in NEWS and Wise Package Studio by Stefan Hotan. 0 Comments

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.

Eine INI Datei nicht reparieren

Published on October 28, 2009 in Windows Installer by Stefan Hotan. 0 Comments

In dem heutigen Post geht es in der Windows Installer Technologie um die Situation, dass eine INI Datei während einer Reparatur nicht aktuallisiert werden soll.

Das Standard-Verhalten bei einer Reparatur ist wiefolgt: Der Inhalt einer INI-Datei wird mit den Werten aus der INIFile Tabelle verglichen und bei einer Differenz mit den ursprünglichen Werten überschrieben.
Sollte ein Endbenutzer Änderungen an einer INI-Datei vorgenommen haben, so gehen diese bei einer Reparatur des Produktes verloren.

Gemäss der Windows Installer SDK kann über die Aktions-Spalte mit dem Wert 1 festgelegt werden, dass ein Eintrag nur überschrieben wird, falls dieser nicht vorhanden sein sollte. In vielen Fällen wird die Änderung der Aktion die Situation entschärfen, da die Vorgabe auch bei einer Reparatur angewendet wird.

IniFileTable
Mit der Action-Spalte lassen sich zusätzliche Modifikations-Optionen für INI-Dateien einstellen

Betrachtet man die Situation genauer, so kann es sein, dass ein Endanwender Werte aus der INI-Datei löscht. Diese werden bei einer Reparatur wieder hergestellt und verwirft damit die Konfiguration des Endanwenders. Es gibt keine Modifikations-Option die diese Situation berücksichtigt. Eine Möglichkeit bietet die Verwendung einer Kondition in der InstallExecuteSequence Tablle bei der WriteIniValues Aktion. Die WriteIniValues Aktion schreibt die Werte einer INI-Datei anhand der Instruktionen der INIFile Tabelle. Mit der Kondition NOT REINSTALL kann die Aktion bei einer Reparatur ausgelassen werden. Damit geht die Reparaturfunktion aller INI-Dateien verloren, was an dieser Stelle zu erwähnen ist.

INIFile
Bei der Reparatur kann die Modifikation von INI-Dateien ausgeschaltet werden

Sollten die beschriebenen Möglichkeiten keine Alternative zur Situation sein, so stehen weitere Möglichkeiten über Benutzerdefinierte Aktionen (Custom Actions) zur Verfügung. Eine einfache Möglichkeit ohne viel Aufwand mit Scripting-Sprachen zu verbringen bietet der Wise Script Editor. Mit der Funktion Editet INI File kann eine INI-Datei erstellt werden. Die Custom Action ist mit der Kondition NOT Installed  zu versehen, dann wird die Datei nur erstellt jedoch nicht geändert bei einer Reparatur.

Edit
Mit dem WiseScript Editor lassen sich einfach INI-Dateien erstellen.

Wise Package Studio 8 Ankündigung

Published on October 8, 2009 in NEWS and Wise Package Studio by Stefan Hotan. 0 Comments

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.

MSI Patch – Feature Level 0 Effekt

Published on September 30, 2009 in Windows Installer by Stefan Hotan. 0 Comments

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.

Ontrex Best Practices Part I

Published on September 29, 2009 in Windows Installer by Fabio Di Lorenzo. 0 Comments

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

Published on September 3, 2009 in Windows Installer by Fabio Di Lorenzo. 0 Comments

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.