Archive for the 'NEWS' Category

Several months ago I met a new challenge in shape of a device driver I’ve never seen before called…

NDIS – Network Driver Interface Specification.

I dont want to loose much time with talking about the “driver type” itself, because you can get all information from a well written wikipedia article.

Such a driver usually consists of the very typical driver files:

Inf File, Cat File & Sys File. Everything signed as you might expect of course.

My first attempt was to install the driver the “Ontrex Best Practices” way which usually means either to use the difxapp merge module or the dpinst.exe executable (custom action).

Unfortunately, none of them led to to same result as the original package had behave.

After googling around a bit I finally came to the tipping point: netcfg.exe

This executable is present on every windows at least since windows 2000 and basically helps you to automate any “Network Card” related installation tasks like

- Installing/servicing/uninstalling Network Protocols (e.g. Internet Protocol Version 4 (TCP/IPv4)

- Installing/servicing/uninstalling Network services (e.g. QoS Packet Scheduler)

- Installing/servicing/uninstalling Network Clients (e.g. Client for Microsoft Networks)

Kindly asked the program offers me the following command line parameters:

So the last missing information in the puzzle is how do I know the component id for my driver?

Solution was simple: I had installed the original package and searched through the registry  using the INF Filename and this offered me the following result:

Now I had all required information to schedule a custom action in my package to install the driver.

Because netcfg.exe is already on every windows installation I used the type “Execute Program From Destination” (MSI SDK: Custom Action Type 34)

[System64Folder]netcfg.exe -l “[#netlwf.inf]” -c s -i BNNS_NdisLwf

In our case the target operating system  was a x64 OS and therefore we needed to specify the [System64Folder].

Because the action changes the system state it logicaly belongs to the “deferred” installation sequence.

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