Category Archives: Training

Ontrex Software Package Atelier Neuigkeiten

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

Microsoft zieht Visual Studio Installer zurück

Wie Microsoft in einem Forumsmitteilung angekündigt hat (1), werden zukünftige Versionen von Visual Studio nicht mehr mit dem Visual Studio Installer ausgeliefert. Stattdessen wurde eine Partnerschaft mit Flexera Software geschlossen und man wird in Zukunft Visual Studio Kunden eine Limited Edition der InstallShield Software gratis zum Download anbieten.

Wir vom SPA Team empfehlen für Setup Authoring das Windows Installer XML Toolkit, welches sich ebenfalls ins Visual Studio integrieren lässt.

Gerne Unterstützen wir Kunden bei der Implementierung, Umsetzung & Schulung einer Windows Installer XML Toolkit Umgebung für die automatisierte Setup-Erstellung.

Via InstallSite

1) http://social.msdn.microsoft.com/Forums/en-US/winformssetup/threads

“the requested operation requires elevation” – Executionlevel mit App-V

Wer bereits viel “App-v”-isiert wird sicher schonmal folgende Fehlermeldung erhalten haben:

The requested operation requires elevation

Error Code: 4513CDC-1B40212C-000002E4

Das Problem tritt in der Regel auf wenn eine Applikation erhöhte Rechte anfordert, beispielsweise durch einen “requireAdministrator” Eintrag im Manifest.

In App-V kann man dieses Problem relativ einfach beheben in dem man die OSD der Applikation um folgenden Eintrag ergänzt:

<ENVLIST>
<ENVIRONMENT VARIABLE=”__COMPAT_LAYER”>RunAsInvoker</ENVIRONMENT>
</ENVLIST>
<DEPENDENCIES />

Die “CMD/Batch” Variable __COMPAT_LAYER kann man übrigens auch in Batch Files verwenden, wenn man nicht möchte das ein Prozess erweiterte Rechte anfordert, bzw. ein UAC Dialog erscheint.

Der Wert “RunAsInvoker” forciert das die Prozesse in der aktuellen Berechtigungsstufe bleiben sollen.

Quelle:
http://blogs.technet.com/b/virtualworld/archive/2010/04/13/the-requested-operation-requires-elevation-2c-000002e4.aspx

Weitergehende Informationen zur __COMPAT_LAYER Variable:
http://blogs.msdn.com/b/cjacks/archive/2009/09/13/how-to-run-applications-manifested-as-highestavailable-with-a-logon-script-without-elevation-for-members-of-the-administrators-group.aspx



Wise: Add/Remove Icon – Der korrekte Weg

Wer einige Pakete für ein x64 Betriebsystem mit Wise Package Studio repaketiert hat, dem wird sicher bereits aufgefallen sein das die Add/Remove Icons nicht mehr funktionieren.

Der Grund hierfür liegt daran das Wise Package Studio leider immer noch einen alten (legacy) Weg einschlägt um dieses Icon zu setzen (via Registry Key) welcher unter x64 nicht mehr funktioniert.

Mit folgendem Trick schlägt man den korrekten “Windows Installer” Weg ein welcher sowohl unter x86 & x64 Betriebsystemen funktioniert:

1. Falls man bereits ein “Shortcut” Element mit dem gewünschten Icon hat, kann man direkt zu Punkt 3.2 springen.

2. Als erster Schritt muss man zur “Icon” Resource kommen. Hierfür gibt es mehrere Techniken, der einfachste Weg ist mittels dem Tool “IconsExtract” von NirSoft (Freeware, http://www.nirsoft.net/utils/iconsext.html). Am besten sucht man sich das Haupt-EXE heraus und extrahiert das Icon. Sofern man Glück hat ist vielleicht auch bereits ein ICO File im Installationsverzeichnis vorhanden. Auf jeden Fall sollte am Ende dieses Schrittes ein ICO File mit dem gewünschten Inhalt vorliegen.

3.1 In der Setup Editor Ansicht wechselt man auf die “Icon” Tabelle und erfasst eine neue Zeile (Rechtsklick auf Tabelle -> “New Row”). Den Namen kann man frei wählen. Mittels Doppelklick auf “{binary data}” kann man das ICO Resource in die Tabelle laden. Nun gehts weiter zu Punkt 4.

3.2 In der Setup Editor Ansicht wechselt man auf die “Shortcut” Tabelle. Dort sucht man den entsprechenden Shortcut und kopiert den Wert welcher in der “Icon_” Kolumne steht. Falls der Wert leer ist muss man zurück zu Punkt 2 springen. Ansonsten gehts weiter bei 4.

4. Nun erfasst man in der Property Tabelle ein Property namens “ARPPRODUCTICON” und erfasst als Value den Wert des “Binaries”. Sofern man die ICO Resource selber hinzugefügt hat, muss man natürlich den gewählten Namen wiederverwenden .

Wise Setup Capture – security restriction

Mit der aktuellen Version des Wise Package Studios erscheint ab Windows Vista beim Setup-Capture die Meldung ‘The operating system currently has a security restriction that interferes with Virtual Capture and SmartMonitor’.

Wenn der SmartMonitor und der Virtual Capture nicht verwendet werden, also nur das klassische Snap-Shot Verfahren gebraucht wird, dann kann diese Meldung mit ‘No’ ignoriert werden.
Mit folgendem Registry-Key kann diese Nachricht unterdrückt werden:
[HKCUSoftwareWise SolutionsWindows Installer EditorHideMessages]
“20153”=dword:00000006

Hinter dieser Option steht eine Sicherheitserweiterung, die mit der Vista Version von Windows eingeführt wurde. Wird der Hinweis mit ‘Yes’ beantwortet, so wird folgender Registry-Key geschrieben:
[HKLMSOFTWAREWow6432NodeMicrosoftWindows NTCurrentVersionWindows]
“LoadAppInit_DLLs”=dword:00000001

Die LoadAppInit DLLs ist eine Beriebsystem-Funktion, welche bei jedem Prozess zusätzliche DLL’s ladet. Wise Package Studio verwendet diese Funktion um die Datei HookDll.dll in den Speicher eines jeden Prozesses einzubinden. Damit wird es ermöglicht, einen Installationsprozess zu überwachen und dessen Vorgehen mit SmartMonitor oder VirtualCapture aufzuzeichnen.
HookDll.dll

Class IDs verification Test

Dieser Post geht auf den Test Expert ein, welcher mit einer Wise Package Studio Quality Assurance Erweiterung oder mit der Wise Package Studio Suite Edition zur Verfügung steht.
Im Wise Test Expert existiert unter ‘Application Verification Tests’ ein Class IDs  Test Case.  Mit diesem Test Case lassen sich Klassen, also Registry Einträge unter HKCRCLSID automatisch Testen, ohne die Applikation starten und alle Funktionen sowie Unterfunktionen testen zu müssen.

Dieser Test Case unterliegt  der ClassID Tabelle der ausgewählten Applikation und verwendet die CoCreateInstance Funktion um die Funktionalität der Klasse zu verifizieren. Natürlich erhofft man sich bei der Verwendung des Wise Test Expert ein Erfolgs-Resultat von 100%. Die Praxis zeigt uns jedoch, dass bei den Class IDs Tests ein Resultat von 20% schon eine voll funktionierende Applikation ausweissen kann.

Der Grund für diesen Beitrag besteht darin offen zu legen, warum im Test Expert bei den Class IDs Test ein Resultat von 20% schon gut genug sein kann.

Ich habe über die Jahre alle möglichen Resulate aus dem Test Experten analysiert und eine Liste erstellt, worin zu ersehen ist, bei welchen ‘Error Numbers’ eine Installation auf Fehler zu überprüfen ist und bei welchen Nummern die Klasse als funktionsfähig einzustufen ist.

Error Number Error Description Real Error
0x80040154 Class not registered maybe
0x80004002 No such interface supported no
0x80080005 Server execution failed no
0x80004005 Unspecified error no
0x80040111 cannot supply requested class no
0x8007007E The specified module could not be found yes
0x8000FFFF Catastrophic failure no
0x80040112 Class is not licensed for use no

Die Liste zeigt auf, es gibt verschiedene Gründe, warum ein Klassen-Test fehlschlagen kann.

Bei folgenden Fehler-Nummern kann die betroffene Klasse korrigiert werden:

Class not registered: Der Test kann nochmals durchgeführt werden, nach dem die betroffene Klassen-Datei (.DLL oder .OCX) mit dem Programm regsvr32.exe registriert wurde. Sollte nach einem erneuten Test die Klasse erfolgreich gestet werden können, so kann die fehlende Klasse in die Installation eingebaut werden.

The specified module could not be found: Verwenden Sie den Dependency Walker von Microsoft um die fehlende(n) Datei(en) in die Installation einzubauen.

Bei den restlichen Fehlermeldungen liegt fast sicher kein Problem vor, oder dieser lässt sich aus Sicht eines System-Administrator nur sehr selten verbessern.

Zusammenfassend muss ich festhalten, dass ein Klassen-Test mit der CoCreateInstance Funktion keine optimale Lösung ist, um eine verlässliche Aussage treffen zu können, ob eine Klasse wirklich funktioniert. Die Test-Resulate liefern viele Error Codes zurück, obwohl die Applikation funktionieren wird. Schlussendlich hat ein Software Hersteller verschiedene Möglichkeiten eine Klasse  für seine Applikation zu inizialisieren.

Zusätzliche Special Folders

Die Windows Installer Technologie bietet bereits von Haus aus diverse Directory Properties um auf  “Special Folders” Werte zugreifen zu können.

Leider gibt es jedoch immer wieder der Fall, dass man auf zusätzliche, nicht durch den Windows Installer bereits zu Verfügung gestellte Werte zugreifen muss.

Mit folgendem VBScript kann man sich diese Werte allerdings schaffen. In unserem folgenden Beispiel ermitteln wir den “Common Documents” Folder.

Folgendes Skript fügen wir als “CALL VBScript From Embedded Code”  Aktion im Immediate Bereich ein:

Const CSIDL_COMMON_DOCUMENTS = &h2e
Set objShell = CreateObject(“Shell.Application”)
Session.Property(“ONTX_COMMON_DOCUMENTS”) = objShell.Namespace(CSIDL_COMMON_DOCUMENTS).Self.Path
Set objShell = nothing

Zu beachten ist, das wir diese Aktion vor “CostFinalize” durchführen müssen.

Um den Wert auch für Komponenten verwenden zu können, sollte man noch einen Eintrag in der Directory Tabelle erfassen:

Danach kann man das Property/Directory  wie üblich verwenden.

Eine Liste aller Special Folders befindet sich im Anhang dieses Artikels.

Continue Reading

Wise Package Studio 8: Network Client Update umgehen.

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.

 

Microsoft APP-V 4.6 Verfügbar

Seit kurzem ist die Version 4.6 der Microsoft Software-Virtualisierungstechnologie (APP-V) verfügbar.

Mit der Version 4.6 findet nun auch native x64 Technologie Einzug in die Virtualisierungslösung von Microsoft.

Herunterladen lässt sich die neuste APP-V Version über die gängigen Seiten/Zugriffsmöglichkeiten:

  • Technet
  • MSDN
  • MVLS

Die Ontrex AG bietet umfangreiche Consulting und Paketierungs-Diensleistungen für diese Technologie an.
Weitere Informationen über unsere Dienstleistungen finden Sie auf unserer Homepage.

REMOVE Kondition – Die Wahrheit

Als ich kürzlich den Artikel Test your conditions von Heath Stewart gelesen habe, wusste ich sogleich, dass es nun an der Zeit ist die letzten technischen Details über die REMOVE Kondition preis zu geben.

Wie die REMOVE Kondition optimal eingesetzt wird entscheidet die Feature Struktur eines Produktes. Eine einfache Aussage wie REMOVE~=”ALL” zu verwenden, ist keine gute Idee, da es Situationen gibt, wo diese Kondition nicht greift.

Fact ist, dass die REMOVE Kondition im Falle einer Deinstallation verwendet werden kann.
Fact ist, dass bei einer repaketierten Applikation, im Generellen die Kondition REMOVE verwendet werden kann.

Der Ausdruck REMOVE~=”ALL” hat sich über ein Jahrzehnt stark verbreitet. Der Wert ALL bedeutet, dass alle Features eines Produktes deinstalliert werden, sprich die Installation wird komplett deinstalliert. Dies ist die allgemeine Annahme in der Software Paketierung.

REMOVE~=”ALL” wird jedoch nicht in allen Situationen funktionieren, wie es Heath Stewart schon angedeutet hat. Es gibt eine Situation, den Wartungsmodus um es genau zu benennen, wo diese Kondition nicht greift. Betroffen davon sind besonders Software-Entwickler, da dessen Deinstallationen öfters mit dem Wartungsmodus durchgeführt werden und von diesem Problem betroffen sind.

Ein Produkt  kann über folgende vier Wege deinstalliert werden.

Deinstallation mittels Befehlszeile (msiexec.exe -x <product code> /qb) wie gewöhnlich ein Produkt automatisch deinstalliert wird:
MSI (s) (28:5C): Command Line: REMOVE=ALL
Property(S): REMOVE = ALL

Deinstallation über Control Panel > Add or Remove Programs, wie es ein Endanwender eine Deinstallation durchführen wird:
MSI (s) (28:F8): Command Line: REMOVE=ALL
Property(S): REMOVE = ALL

Deinstallation über den Wartungsmodus einer MSI Installation (Modify, Repair oder Remove Option im Setup Wizard)
MSI (s) (28:5C): Command Line:
MSI (c) (28:1C): Switching to server: REMOVE=Complete
MSI (s) (28:10): PROPERTY CHANGE: Adding REMOVE property. Its value is ‘Complete’.
MSI (s) (28:10): PROPERTY CHANGE: Modifying REMOVE property. Its current value is ‘Complete’. Its new value: ‘ALL’.
Property(S): REMOVE = ALL

Deinstallation über die Windows Installer API
MSI (s) (28:EC): Command Line: REMOVE=ALL
Property(S): REMOVE = ALL

Es wird nun ersichtlich, das eine Deinstallation über den Wartungsmodus anders abläuft als die restlichen Deinstallationswege. Beim Wartungsmodus steht es von beginn an nicht fest, welche Windows Installer Aktion der Anwender ausüben wird. Daher kann die REMOVE Property nicht  von Beginn an definiert werden.
MSI (s) (28:5C): Command Line:

In der REMOVE Property stehen alle Feature Namen des aktuell installierten Produktes (Features werden mit ; getrennt falls mehrere installiert sein sollten).
MSI (c) (28:1C): Switching to server: REMOVE=Complete
MSI (s) (28:10): PROPERTY CHANGE: Adding REMOVE property. Its value is ‘Complete’.

Anhand der Windows Installer SDK steht fest, das der Remove Control Event das Argument ALL  dem REMOVE Property der Installations-Session weiter geben muss, damit das gesamte Produkt deinstalliert wird.
MSI (s) (28:10): PROPERTY CHANGE: Modifying REMOVE property. Its current value is ‘Complete’. Its new value: ‘ALL’.
Property(S): REMOVE = ALL

Entscheidend ist, die Action InstallValidate erkennt den Remove Control Event Eingriff  und ändert den Wert in der REMOVE Property auf ALL.

Dies bedeutet: Wird ein Produkt über den Wartungsmodus deinstalliert, so werden Konditionen mit dem Argument REMOVE~=”ALL” erst nach der InstallValidate Aktion funktionieren.

Sollte früher eine Aktion diese Kondition verwenden, so wird diese nicht ausgeführt.