ActiveSetup unter x64 Betriebsystem

Ein in der Repaketierung sehr beliebtes Instrument um “Per-User” Resourcen zu installieren stellt das ActiveSetup dar.

Wer erwägt seine MSI-Pakete ebenfalls auf einem x64 OS zu installieren muss diesen allerdings doppelt erfassen.  Wieso fragen Sie sich sicher?

Das Problem liegt im Detail: Die Windows Shell auf einem x64 Betriebsystem ist natürlich, überraschung ein 64-Bit Prozess,  und der Active-Setup Registry Bereich ist gemäss Microsoft kein “gesharter” Key Bereich. Daher wird beim Logon-Prozess nur der x64 Bereich “abgearbeitet”.

Eine saubere und TerminalServer-Aware Lösung für dieses Problem sieht wie folgt aus:

Die Komponente für das ActiveSetup wird doppelt implementiert, und einmal mit aktivierten “64-Bit Component” Flag, damit die Registry Keys auch definitiv im 64-Bit Bereich geschrieben werden.

Da Registry Keys jeweils nur zu einer Komponente gehören dürfen, müssen diese natürlich doppelt erfasst werden:

Ansonsten gelten natürlich die üblichen ActiveSetup Best Practices. Und um es nochmals definitiv klarzustellen: Diese Implementation wird auch bei x86-Paketen benötigt.

 

 

Microsoft APP-V 4.6 SP1 – Web Artikel

Mit dem Release des Service Packs 1 für Microsoft Application Virtualization 4.6 sind auch einige neue technische Artikel im Web erschienen.

In diesem Artikel fassen wir die wichtigsten zusammen:

Das offizielle “Changelog” von Microsoft kann sich unter folgendem Link ansehen:

 

Generelle App-V Troubleshooting Techniken

Wie viele vielleicht bereits wissen ist das SPA Atelier auch in der Software-Virtualisierung tätig.

Aufgrund den Erfahrungen aus diversen Kundenprojekten mit APP-V haben sich gewisse “grundlegende” Troubleshooting-Techniken bei uns eingebürgert, welche wir auch unseren Kunden empfehlen.

Wichtig ist jedoch zu wissen, das diese Techniken nur für Virtualisierungs-”Kandidaten” funktionieren. Bekannte technische Einschränkungen wie System-Treiber etc. können hiermit nicht umgangen werden.

Installation in default Path

Auch im Jahr 2010 gibt es leider immer noch Applikationen mit “hardcodierten” Pfäden. Nach einer Installation auf das Asset-Drive verweigern diese Programme dann natürlich jegliche Dienste.
Eine Installation in den default Path ist die Lösung für dieses Problem.

Enforce Security Descriptors

Ist seit APP-V 4.5 standardmässig aktiv. Bedeudet nichts anderes als das “Berechtigungen” auch innerhalb der APP-V Bubble gelten.

Das deaktivieren dieser Option hat folgenden Effekt für die App-V Benutzer:

  • Schreibrechte auf alle im APP-V Paket (existierende) Registry Keys
  • Schreibreche auf alle im APP-V Pakete existierende VFS Files
  • Voller Zugriff auf den Assetfolder (Q:example.001

Die meisten Berechtigungsprobleme sollten dann Passé sein.

LOCAL INTERACTION ALLOWED

Haben Sie folgende Phänomene in einer virtuellen Applikation?

  • MAILTO: Funktioniert nicht.
  • Interaktionen mit “Basis”/nicht virtualisierten Applikationen funktioniert nicht.

Dann hilft der LOCAL_INTERACTION_ALLOWED Flag! Dieser lässt sich wie folgt aktivieren:

„VIRTUALENV” öffnen.

Rechtsklick auf “VIRTUALENV”.

„Element” -> „Add” -> „Policies”.

Dann ebenfalls Rechtsklick auf „Policies”. 
„Element” -> „Add” -> „LOCAL_INTERACTION_ALLOWED”.

Nun wählt man das Element „LOCAL_INTERACTION_ALLOWED” aus und trägt beim „Element Text „ den Wert „TRUE” ein.

Dieser muss übrigens pro Applikation/OSD aktiviert werden.

Auf X86 OS mit X86 Sequencer sequenzieren

Last but not least sollte man, sofern es sich um eine 32-Bit/x86 Applikation handelt, die Applikation auf einem x86 Betriebsystem zu sequenzieren.
Wichtig: Man darf danach das Projekt nicht mehr mit einem x64 Sequencer öffnen!

Erweiterte Troubleshooting Techniken

CMD in Applikationscontext starten.

Um Probleme besser analysieren zu können, muss man die Registry/File Ansicht aus Applikationssicht sehen.

Mittels folgendem Trick kann man eine beliebige „base” Applikation aus der Bubble hinaus starten und somit alle virtualisierten Files & Registry Keys sehen:

Sfttray.exe /exe „cmd.exe” /launch „Microsoft WOrd 2010 14.0.xxx”

„Cmd.exe” kann durch jede beliebige Applikation ersetzt werden (bsp. Regedit etc.).

„Microsoft WOrd 2010 14.0.xxx” ist der Applikationsname der virtualisierten Applikation.

PROCMON

Schlagen alle bisherigen Techniken fehl bleibt nur noch das Troubleshooting mittels Procmon & ProcExp.

Folgender Ablauf wird empfohlen:

  • ProcMon starten mit Standard Filter Rules.
  • Applikation starten bis Fehler auftaucht.
  • Capture stoppen und mittels Process Explorer ermitteln welcher exakte Prozess die Fehlermeldung anzeigt.
  • Filter setzen für diese Applikation.
  • Nach Gefühl filtern, die üblichen Verdächtigen sind:
  • NAME_NOT_FOUND
  • ACCESS_DENIED

Adobe Reader X

Seit letztem Freitag steht der neue Adobe Reader X von Adobe zum Download bereit.

Die wichtigste Neuerung ist ein Sandbox Modus welcher für eine allgemeine Erhöhung der Sicherheit sorgen soll.

Die Software wird natürlich demnächst als Direct-Package-Download in unserem Portal zur Verfügung stehen.

Quelle: http://www.heise.de/security/meldung/Adobe-Reader-X-mit-Sandbox-fuer-Windows-verfuegbar-1139095.html

16-Bit Applikationen mit APP-V Sequencen

Microsoft hat ab APP-4.5 das Registry Hooking vom Kernel-Mode in den User-Mode verschoben (Quelle: http://technet.microsoft.com/en-us/library/cc843672.aspx), dies verursacht bei 16-Bit Applikationen das Problem das diese nicht mehr korrekt sequenziert werden (fehlende Registry Keys).
Damit das Sequencen auch bei 16-Bit Applikationen weiterhin korrekt funktioniert ist daher ein kleiner Eingriff notwendig, so das jede “Windows NT Virtual Dos Machine” in einem seperaten Prozess aufgestartet wird.
Mit folgendem Workaround funktioniert das Sequencen wieder Ordnungsgemäss:
Unter “HKLMSYSTEMCurrentControlSetControlWOW” setzt man den “DefaultSeparateVDM” Value auf “yes”.
Danach ist nur noch ein Neustart des Betriebsystems notwendig und die 16-Bit Applikationen sollten sich wieder korrekt sequenzieren lassen.
Diese Einstellung muss man übrigens NICHT auf den Ziel-Clients durchführen.

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 .

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.