Author Archives: Stefan Hotan

How to clear a pending restart

In some rare cases a vendor setup checks for a pending restart.

During setup capture this will bring a lot of junk into a snap-shot, so the question will be, how can I clear a pending restart in order to install the vendor setup without doing a reboot.

The following registry will is the root of the problem. Renaming the key or clear out the value will solve this issue.

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetContro lSession ManagerPendingFileRenameOperations

Whats new in Java Runtime 7

What’s new in Java Runtime 7 – from a Software Packaging or Administrator point of view?

This can be answered quite short: Nothing as been changed, the new version is based on the previous installation technology with the same limitations as know.

Here are the most important details about Java Runtime Environment 7

1. A silent repair is still not supported (uninstall and install has to be done) see our bolg for more details.

2. The previous JRE 6 version will not be uninstalled when installing the new JRE 7 version, but version 7 will be the default runtime

3. The new features of Java 7 or read the change log that can be found in the internet

4. Use ‘java -version’ on a command prompt to display the default JRE version and build

5. At last but not least, this package is available as Direct Package Download, a service from Ontrex SPA. DPDs are fully automated software packages that can be deployed with any software deployment systems.

 

 

SPA Blog goes international

The Ontrex SPA Team is proud to announce that our future Blogs will be authored in English as the growing amount of visitors are from international destinations.

This is our first step to provide our technical know how to a wider audience.

We also would like to introduce our offical Ontrex SPA Twitter Account:

http://twitter.com/ontrexspa

Feel free to follow us. we are looking forward to interesting discussions about packaging, software virtualization and other related subjects in the twittersphere.

Yours Sincerely,

Ontrex SPA Team

 

 

 

 

The module failed to load

Neulich bei einem Regsvr32.exe /silent Aufruf einer DLL Datei wurde folgende Fehlermeldung (obwohl der Silent-Paramenter verwendet wurde) ausgegeben:

The module xyz.dll failed to load.
Make sure the binary is stored at the specified path or debug it to check for problems with the binary or dependent .DLL files.
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line systrace.exe tool for more detail.

Eigentlich dürfte dieses Fenster nicht erscheinen, da der /silent parameter verwendet wurde.

Man sollte sich auch nicht durch die side-by-side configuration in die Irre führen lassen und einfach den guten alten Dependency Walker verwenden.

Der Depency Walker zeigt die fehlenden Komponenten an, welche vor der Registration auf dem Rechner vorhanden sein müssen.

Es geht auch Stück für Stück mit dem Event-Log, der in einem Error Eintrag die benötigte DLL anzeigt.

Kurz gesagt, neue Meldung, altes Problem

64Bit Wise Setup Capture

Mit der folgenden Methode ist es mögich mit dem Wise Setup Capture 64Bit Bereiche des Betriebssystems mit in einen Snap-Shot aufzuzeichnen.

1. Der gewünschte Bereich kann mit dem subst Befehl zu einem neuen Laufwerk gebunden werden.

2. In den Setup Capture Einstellungen das erstellte Laufwerk im Directories to Watch einbeziehen

Durch diesen einfachen und sehr effektiven Weg lassen sich nun diese Bereiche aufzeichnen.

Dieser und weitere Windows 7 Tricks werden an unserem Jährlichen User Group Meeting präsentiert.
Sichern Sie noch heute Ihren Platz, unsere Kundenveranstaltung am 3. November ist kostenlos und kann unter folgender Adresse im Detail eingesehen werden:

http://www.ontrex.ch/de/70_events/10_ausblick/ausblick.htm?id=39

Plugin für verschiedene Office Versionen bereitstellen

Wenn immer eine neue Version von Microsoft Office verfügbar ist, kommt es vermehrt zur Situation, dass eine Installation Office Plugins sowohl für die Vorgängerversion wie auch für die aktuellste Version bereitstellen muss.

Für Administratoren die ein Office Plugin repaketieren, kommt erschwerend dazu, dass für jede Office Version die berücksichtigt werden muss, ein Snap-Shot von der Hersteller-Installation durchgeführt werden muss. Als wäre dies nicht schon genug, müssen Dateien die scheinbar die Gleichen sind auch noch Binär abgelichen werden, denn nicht selten kommt es vor, dass ein Plugin die gleiche Grösse und das gleiche Datum hat, jedoch Binär unterschiedlich sind.

Der folgende Weg beschreibt wie mann gleiche oder unterschiedliche Office Plugins mit einer Installation für verschiedene Office Versionen bereitstellt.

Sind die Dateien für die unterschiedlichen Office Versionen bekannt, dann wird für jede Office Version eine eigene Komponente erstellt. Das Verzeichnis steht nur als Beispiel, in der Praxis werden die Dateien in unterliegende Ordner wie STARTUP oder XLSTART installiert.


Beispiel Komponente für Office 12 (2007), erkennbar an der Kondition


Beispiel Komponente für Office 14 (2010), erkennbar an der Kondition

Der Haupteil der Installations-Logik, herauszufinden welche Office Version vorhanden ist, übernimmt eine CustomAction. Die CustomAction wird die auf dem Rechner vorhande Office Version anhand der Winword.exe Datei auslesen und den MajorRelease des Office Produktes in eine Public Property, in diesem Beispiel OFFICEVERSION, hinterlegen. Die OFFICEVERSION Property wird danach als Kondition weiter verwendet.

Da die Custom Action von keiner anderen Aktion abhänigig ist, wird diese im frühen Immediate Bereich der Installation ausgeführt. Zum InstallValidate Zeitpunkt wird anhand der Konditionen entschieden, welche Komponenten installiert werden.

Auszug aus dem Verbose-Log der Installation:

MSI (s) (20:44) [11:24:05:495]: Doing action: ONTXGetOfficeVersion
MSI (s) (20!44) [11:24:05:807]: PROPERTY CHANGE: Adding OFFICEVERSION property. Its value is ’14’.
(Die CustomAction erstellt die Public Property mit dem aktuellen Wert der Office Version)

MSI (s) (20:44) [11:24:07:885]: Doing action: InstallValidate
MSI (s) (20:44) [11:24:07:885]: Component: Office_Makros.dot_12; Installed: Absent;   Request: Local;   Action: Null
MSI (s) (20:44) [11:24:07:885]: Component: Office_Makros.dot_14; Installed: Absent;   Request: Local;   Action: Local
(Die InstallValidate Aktion wird mit der Action Null oder Local den Komponenten Status festlegen)

Nicht zu vergessen, die Public Property muss in die SecureCustomProperty aufgenommen werden.

Mit diesem Vorgehen steht nichts mehr im Wege die nächsten Office Plugin Installationen zu paketieren.

Install Microsoft Office 2010 Language Packs

Das Prinzip der Office 2010 Language Packs Installation wurde von der Vorgänger Version 2007 übernommen.

Wer zum Ersten Mal eine  Office 2007 oder 2010 MUL Installation automatisieren muss, dem sei mit einem Microsoft Technical Diagramm geholfen. Wohl reicht ein Ausdruck auf A3 nicht aus um alles darzustellen, jedoch gibt’s noch eine Zoom Funktion oder ein Drucker, der auf A1 oder A0 ausdrucken kann.

Mit dem ‘Deploy Language Packs for Microsoft Office 2010’ Diagramm erhält man auf einen Blick (oder auch zwei) eine Übersicht der Microsoft Office 2010 Sprachpaket-Integration.

Das Diagram zum Herunterladen

Weitere Tech-Diagramme von Microsoft die von Interesse sein können.

MSI-Logfileanalyzer 3.0 review

Der MSI-Logfileanalyzer 3.0 geht in die dritte Runde. Der MSI Logfile Analyzer ist ein Werkzeug um Windows Installer Logfiles schnell, effizient, detailliert und gegliedert anzuzeigen. Nebst dem verbesserten Look and Feel gegenüber der alten Version wurden einige interessante Optionen hinzugefügt und Verbesserungen eingebraucht um mit dem Analyzer ein stabiles und robustes Programm zur Verfügung zu stellen.

 Die folgende Liste enthält eine Übersicht der neuen Funktionen:

  • Suchfunktion
  • Installation, Deinstallation von Features
  • Export von Tabellen
  • Gleichzeitige Anzeige der selekieren Ressource mit dem Inhalt der entsprechenden Tabelle aus dem MSI
  • Ausweisen ob eine Transformation angewandt wurde, inkl. Pafd zur MST
  • Uebersetzungsprogramm der gepackten GUID zur Standart GUID und umgekehrt
  • SID Uebersetzungsprogramm
  • Feedback Funktion
  • Export der Registry Einträge vom Logfile in eine .REG Datei
  • Speichern der analysierten Logfiles
  • Es können bis zu hundert Logfiles geöffnet werden

Die aktuelle Version kann unter www.hoschi.biz bezogen werden.

.NET Installation Repaketieren

Seit vielen Jahren gibt es Programme, welche auf das Microsoft .NET Framework aufbauen. Deren Anzahl wächst täglich und sind dabei die klassischen 32Bit Com Objekt orientieren Applikationen zu verdrängen. Dementsprechend kommt es häufiger vor, dass eine .NET Framework Applikation repaketiert wird.

Je nach Applikation kann das interpretieren der Ressourcen sehr komplex ausfallen. Speziell dann, wenn Assemblies ins Global Assembly Cache installiert, Interop Registrationen durchgeführt, Native Images erstellt, VC++ Runtimes bereitgestellt und vielleicht noch an den .NET Securities gedreht wird.

Wer .NET Applikationen repaketiert muss die Welt deren Ressourcen verstehen lernen. Eine einfache .NET Applikation aus Sicht der .NET Ressourcen ist einfach zu repaketieren, kommen jedoch weitere .NET Ressourcengebiete dazu, dann ist ohne Grundwissen ein Überblick schwer zu erhalten.

Die .NET Ressourcen können im Grossen und Ganzen in fünf Segmente unterteilt werden:

Nicht jede .NET Applikation benötigt zwangsweise eine komplexe Integration. Im besten Falle besteht die Applikation aus privaten Assemblies und benötigt keine der dargestellten .NET Ressourcen.

Die Herausforderung in der Repaketierung besteht darin, die Ressourcen anhand des Deltas dem richtigen Ressourcen-Typ zuzuordnen und die optimale Installationsmethode zu verwenden. Wir haben uns diesem Problem angenommen und diesen Teil in den ‘Wise – MSI Blackbelt III’ Kurs eingebunden. Diesen Eintageskurs führen wir 1-2 mal pro Jahr durch. Neben dem Thema .NET werden weitere interessante Themen für Fachkräfte im Bereich der Software Paketierung besprochen.

MSI Assembly Converter

Anlässlich unserer Schwarzgurt-Paketierungsausbildung haben wir ein Tool entwickelt, dass bei repaktierten Hersteller MSI Installationen die MsiAssembly und MsiAssemblyName Tabellen in die neue Installation konvertiert. Das Tool mit der Bezeichnung MSI Assembly converter ist nun für die Öffentlichkeit freigegeben.

Download: MSI Assembly converter

Unser Konverter wird aus der Quelleinstallation alle MsiAssembly und MsiAssemblyName Einträge auslesen und diese in die eigene Installation anhand der neuen Installations-Struktur aufbereiten. Es kommt gerne vor, das die Hersteller-Installation mit GUIDs arbeitet, dessen Umsetzung in eine neue Installation sich als sehr Aufwendig erweisen kann.

Beispiel einer Hersteller MSI mit .NET Assemblies

Das Ergebnis nach der Konvertierung in die eigene Installationsdatei. Der Konverter richtet sich nach der neuen Feature und Datei-Namen der Ziel-Installation aus.

Weitere Informationen zu unserem Schwarzgurt Training und weiteren Software Paketierungsausbildungen finden Sie auf unserer Homepage: http://www.ontrex.ch