Microsoft Application Virtualization (App-V) 4.6 bietet volle Unterstützung für Windows 7 und ist schnell verfügbar; viele Kunden, die die Bereitstellung von Windows 7 planen, beziehen App-V als Komponente in ihr Desktopumstellungsprojekt mit ein. (Bei der Bereitstellung eines Betriebssystems werden häufig auch die Anwendungen und die Infrastruktur überholt, um einen „modernen Desktop“ oder den „Desktop der nächsten Generation“ zu erhalten.)

Wenn IT-Experten vorschlagen, die Investitionen in App-V und Windows 7 zu koppeln, treten fast immer die folgenden Fragen auf:

• Ich habe gehört, dass App-V eine Lösung für Probleme mit der Anwendungskompatibilität ist. Bedeutet dies, dass das Programm für die Kompatibilität meiner Anwendungen mit Windows 7 sorgt?
• Muss ich die App-V-Pakete, die ich bereits für meine aktuellen Windows XP-Desktops erstellt haben, neu sequenzieren?
• Was muss ich tun, um Probleme mit nicht kompatiblen Anwendungen zu lösen, wenn ich App-V als Bereitstellungslösung verwende?

Sehen wir jede dieser Fragen einmal genauer an.

Ist App-V eine Lösung für Probleme mit der Anwendungskompatibilität?

Microsoft App-V ist in erster Linie eine Lösung zur Anwendungsverwaltung und -bereitstellung, die einem Unternehmen erhebliche Vorteile bringen kann – durch Senkung der Paketkosten, Steigerung der Systemstabilität und Unterstützung der mobilen Mitarbeiter von heute, indem diesen dynamischer Zugriff auf Softwareressourcen ermöglicht wird. Der überladene Begriff Anwendungskompatibilität wurde als Teil der Marketingbotschaft jedoch im Laufe der Zeit falsch interpretiert: Er wurde so ausgelegt, dass App-V bei Kompatibilitätsproblemen zwischen Anwendung und Betriebssystem helfen kann. Zum großen Teil stimmt dies nicht. (Heutige Ausnahmen sind größtenteils historisch bedingt und nicht verlässlich, daher werde ich hier nicht ins Detail gehen.)

Die daraus entstehende Verwirrung bei den Kunden hat zu einer Umformulierung der Botschaft geführt. Wir vermeiden nun den Begriff „Anwendungskompatibilität“ und erwähnen stattdessen direkt die zugrunde liegenden Vorteile: dass Konflikte zwischen Anwendungen verringert werden (beachten Sie die strategische Auslassung des Worts „Kompatibilität“) und dass folglich weniger Regressionstests erforderlich sind.

Die offizielle Haltung des Produktteams zur Kompatibilität zwischen Anwendungen und Betriebssystem sieht folgendermaßen aus:

Wie bereits in früheren Diskussionen erwähnt, ist App-V keine Universallösung für Kompatibilitätsprobleme zwischen Anwendungen und Betriebssystem; wenn eine Anwendung jedoch dank eines Anwendungskompatibilitätsshims unter einer bestimmten Windows-Version systemeigen (nicht virtualisiert) ausgeführt werden kann, funktioniert dies in den meisten Fällen und für die meisten Shims auch mit App-V, wenn die geshimmte Anwendung virtualisiert wird. Generell kann man daher sagen, dass App-V die Verwendung von Anwendungen mit Shims unterstützt, die im Rahmen der Anwendungskompatibilitätstools von Microsoft bereitgestellt werden, sofern die geshimmte Anwendung systemeigen unter der Ziel-Betriebssystemversion ausgeführt werden kann.

Damit ist eindeutig klar, dass App-V nicht als Lösung für Kompatibilitätsprobleme zwischen Anwendungen und Betriebssystem gedacht ist. (Auf die Kombination von Shims mit App-V wird später in diesem Artikel eingegangen.) Sehen wir uns nun die anderen Auswirkungen der Anwendungsvirtualisierung auf die Betriebssystemkompatibilität genauer an.

Ist App-V eine Lösung für Probleme mit der Paketkompatibilität?

Beim Thema Anwendungskompatibilität sollte fairerweise zwischen Paketkompatibilität und Laufzeitkompatibilität unterschieden werden. In der Tat wird auch in unserem empfohlenen Verfahren zum Testen der Anwendungskompatibilität (siehe Abbildung 3 in meinem Artikel vom Juni 2009 zum Thema Planen eines Anwendungskompatibilitätsprojekts) zwischen Installations- und Laufzeittests unterschieden. Beginnen wir mit der offiziellen Anleitung des Produktteams:

Häufig ist es möglich, die Sequenzierung unter einem Betriebssystem vorzunehmen und die virtualisierte Anwendung unter einem anderen Betriebssystem auszuführen. Dieses Szenario ist jedoch sowohl von der Anwendung als auch vom Betriebssystem abhängig, und es kann nicht garantiert werden, dass es für alle Kombinationen von Anwendung/Betriebssystem funktioniert, weil App-V keine Universallösung für Probleme mit der Betriebssystemkompatibilität ist. Sollten Probleme auftreten, muss der Kunde die Sequenzierung möglicherweise in der gleichen Betriebssystemumgebung vornehmen, in der der App-V-Client ausgeführt wird, um diese Probleme zu lösen.

Das klingt zugegebenermaßen nicht gerade vielversprechend – die offizielle Haltung ist im Prinzip: „es kommt darauf an“. Wenn es jedoch um die Risikoabschätzung geht, sollten Sie die drei Setup-Technologien vergleichen, die heute hauptsächlich verwendet werden:

Setup.exe:Hierbei wird beliebiger Code ausgeführt; der beliebige Code unterliegt damit den gleichen potenziellen Laufzeitproblemen wie der beliebige Code der Anwendung selbst und muss daher gründlich getestet werden.

Windows Installer: Auch hierbei wird Code ausgeführt, um eine Installation durchzuführen; ein Großteil dieses Codes ist jedoch strukturiert und deklarativ. Lediglich der imperative Code von benutzerdefinierten Aktionen ist beliebig, sodass abgesehen von quantifizierbaren Änderungen in Regeln, die sich auf die Verarbeitung von Code auswirken, der auf die Datenbank angewendet wird, sowie dem beliebigen Code in benutzerdefinierten Aktionen mit einer besseren (jedoch nicht perfekten) Kompatibilität und geringem Testaufwand gerechnet werden kann.

Microsoft App-V: Hierbei muss überhaupt kein Code ausgeführt werden. Es wird lediglich ein Daten-Blob kopiert, der das virtuelle Dateisystem darstellt, und dann die Meldung ausgegeben, dass das virtuelle Dateisystem bereitsteht. Ihre Hauptsorge ist also nicht die Installation der Anwendung (das Kopieren eines einzigen Daten-Blobs ist ja nun ganz einfach), sondern die Laufzeitkompatibilität der Anwendung. Von allen Technologien ist hier also mit dem geringsten Aufwand für Installationstests zu rechnen. Das ist großartig.

Während also niemand offiziell bestätigen wird, dass alle Pakete funktionieren, liegt der Hauptgrund für die Botschaft anscheinend darin, dass für viele Leute nicht zwischen Installationsproblemen und Laufzeitproblemen unterscheiden. Generell können Sie davon ausgehen, dass Sie erheblich weniger Kosten für Anwendungsinstallationstests einplanen müssen, wenn Sie bereits in Microsoft App-V investiert haben.

Wie behebe ich Probleme mit der Laufzeitkompatibilität, wenn meine Anwendung im Microsoft App-V-Paket enthalten ist?

Erinnern Sie sich noch an den verlockenden Teil der Aussage zur Anwendungsunterstützung? „App-V unterstützt die Verwendung von Anwendungen mit Shims, die im Rahmen der Anwendungskompatibilitätstools von Microsoft bereitgestellt werden …“ Wie wird das in der Praxis implementiert? Sind beide grundsätzlich kompatibel?

Die Antwort lautet glücklicherweise „Ja“. Es gibt hierbei sogar mehrere Optionen.

Kurze Einführung zu Shims

Für all diejenigen, die es noch nicht wissen: Ein Shim ist eines der sehr wenigen aus vier Buchstaben bestehenden Microsoft-Wörter, bei denen es sich nicht um ein Akronym handelt. Es ist eine Metapher, die auf dem englischen Wort „shim“ basiert, einem Begriff aus dem Ingenieurswesen, mit dem ein Stück Holz oder Metall beschrieben wird, das zwischen zwei Objekten eingefügt wird, um ihre Passung zu verbessern. In diesem speziellen Fall sind die zwei Objekte das Anwendungsprogramm und Windows, und das Shimmaterial ist zusätzlicher Code, der bewirkt, dass die beiden Objekte besser miteinander funktionieren, wie in Abbildung 1 und Abbildung 2 dargestellt.

Abbildung 1 Vor der Anwendung des Shims interagiert die Anwendung direkt mit Windows.

Abbildung 2 Nach der Anwendung des Shims interagiert die Anwendung indirekt mit Windows. Der Shimcode wird eingefügt und kann die Anforderung an Windows und/oder die Antwort von Windows modifizieren.

Ein Shim fängt APIs ab. Die Windows-API wird mithilfe einer Reihe von DLLs implementiert. Jede für Windows geschriebene Anwendung importiert diese DLLs und verwaltet eine Tabelle mit den Adressen der einzelnen Funktionen im Arbeitsspeicher. Da die Adresse der Windows-Funktionalität in einer Tabelle enthalten ist, kann das Shimmodul diese Adresse ganz einfach durch die Adresse der Shim-DLL ersetzen. Die Anwendung merkt in der Regel nicht, dass die Anforderung nicht an Windows selbst, sondern an eine Shim-DLL geleitet wird; Windows seinerseits merkt nicht, dass die Anforderung von einer anderen Quelle als der Anwendung stammt (da die Shim-DLL einfach nur eine andere DLL im Anwendungsprozess ist).

Ein sehr häufig verwendetes Shim ist beispielsweise ein Versionsvortäuschungsshim (Version lie). Zur Implementierung dieses Shims fangen wir mehrere APIs ab, mit denen die Windows-Version ermittelt wird, unter der die Anwendung ausgeführt wird. Normalerweise wird diese Information an Windows selbst übergeben, und das Betriebssystem antwortet wahrheitsgemäß. Wenn das Shim angewendet wurde, werden diese APIs jedoch abgefangen. Anstatt die Anforderung an Windows zu übergeben, wird eine andere Windows-Version zurückgegeben (z. B. Windows XP statt Windows 7). Wenn die Anwendung ausschließlich für die Ausführung unter Windows XP programmiert ist, kann die Anwendung auf diese Weise überlistet werden, sodass sie glaubt, sie werde unter dem richtigen Betriebssystem ausgeführt. (Häufig kann ein Anwendungskompatibilitätsproblem schon durch diese einfache Maßnahme gelöst werden.)

Mit Shims sind zahlreiche Tricks möglich. Zum Beispiel:

• Das ForceAdminAccess-Shim versucht die Anwendung glauben zu machen, dass der aktuelle Benutzer ein Mitglied der lokalen Administratorgruppe ist, auch wenn dies gar nicht stimmt. (Viele Anwendungen schlagen gänzlich fehl, wenn Sie nicht als lokaler Administrator angemeldet sind; Sie können jedoch möglicherweise andere Tricks nutzen, wie Benutzerkontensteuerung oder Datei- und Registrierungsvirtualisierung, um die Probleme zu lösen, die die Prüfung eigentlich ausgelöst haben.) Die Implementierung dieser Prüfung kann ganz einfach sein. Dieses Shim fängt beispielsweise die API IsUserAnAdmin von shell32.dll ab. Der vollständige Quellcode der geshimmten Funktion (die verglichen mit der eigentlichen API über bemerkenswerte Leistungsmerkmale verfügt) lautet einfach „return TRUE“;
• Das WrpMitigation-Shim macht Installationsprogramme von Anwendungen glauben, sie könnten in Dateien schreiben, die durch Windows Resource Protection (WRP) geschützt sind. Wenn Sie versuchen, in eine geschützte Datei zu schreiben, erstellt das Shim zunächst eine neue temporäre Datei, markiert sie zum Löschen nach Schließen des Handles und gibt dann das Handle an die temporäre Datei zurück, als wäre dies die eigentliche, geschützte Datei. Die Anwendung installiert die Uraltversion von kernel32.dll oder shell32.dll (oder einer anderen Datei, die beim Packen aufgenommen wurde) in einer temporären Datei; diese temporäre Datei wird dann jedoch gelöscht, und die passende, gepatchte, aktuelle Version der geschützten Datei verbleibt im Dateisystem. Mit WRP kann nach wie vor sichergestellt werden, dass auf Ihrem Computer keine Uraltkopie von shell32.dll aus Windows 95 mehr vorhanden ist, das Installationsprogramm schlägt jedoch nicht mehr mit der Meldung ACCESS_DENIED fehl, wenn Sie dieses Shim verwenden.
• Das CorrectFilePaths-Shim kann Dateien von einem Speicherort an einen anderen umleiten. Wenn also eine Anwendung versucht, in c:\myprogramdir zu schreiben (was durch Benutzerkontensteuerung, Dateisystem- und Registrierungsvirtualisierung nicht automatisch korrigiert wird), können Sie die Dateien, die zur Laufzeit geändert werden, an einen benutzerspezifischen Speicherort umleiten. Dies ermöglicht Ihnen die Ausführung als Standardbenutzer, ohne dass Zugriffssteuerungslisten gelockert werden müssen; Sie wissen ja, dass die Sicherheitsverantwortlichen es hassen, wenn Sie diese Listen lockern.
• Es gibt Hunderte von allgemeinen Shims, mit denen Anwendungskompatibilitätsprobleme gelöst werden können. Die Möglichkeit, diese Patches zu nutzen, kann erhebliche Kosteneinsparungen bedeuten. Hier einige Beispiele für Fälle, in denen Shims häufig von Kunden eingesetzt werden:
• Der Anbieter ist Pleite gegangen, sodass keine Möglichkeit mehr besteht, eine aktualisierte Version zu erhalten. Wenn Sie es sich nicht leisten können, eine andere Anwendung von einem neuen Anbieter zu erwerben oder selbst eine neue Version zu entwickeln, können Sie durch ein Shim Zeit sparen.
• Die Anwendung ist nicht besonders wichtig und lohnt keine Investition in aktualisierte Versionen (bei der auch Support enthalten wäre), da aber Ihre Benutzer mit der Anwendung zufrieden sind, ist es für Sie in Ordnung, dass sie mit einer Version ohne Support arbeiten.
• Die Anwendung wird intern entwickelt, Sie möchten jedoch nicht warten, bis das Team eine vollständig aktualisierte Version herausgibt. Stattdessen wenden Sie lieber ein temporäres Patch an und geben dem Entwicklungsteam die Möglichkeit, das dauerhafte Patch zusammen mit der nächsten geplanten Version der Anwendung zu veröffentlichen. Bei dieser Vorgehensweise ist es nicht mehr erforderlich, sämtliche Aktivitäten zur Anwendungsentwicklung zu stoppen und Zeit und Ressourcen für die Behebung von Kompatibilitätsproblemen aufzuwenden. Sie können temporäre Patches anwenden und dem Team Zeit lassen, diese Patches zusammen mit den neuen, bereits in der Entwicklung befindlichen Funktionen zu veröffentlichen.

Die Nutzung von Shims als Lösung für Probleme mit der Anwendungskompatibilität kann beachtliche Kosteneinsparungen bedeuten und die Bereitstellung von Windows 7 erheblich beschleunigen.

Optionen für die Verwaltung von Shims im Unternehmen

In meinem Whitepaper zum Verwalten von Shims im Unternehmen aus November 2007 gebe ich einen Überblick über die zwei Optionen, zwischen denen sich Benutzer hauptsächlich entscheiden, wenn es um die Verwaltung von Shims als Lösung für Anwendungskompatibilitätsprobleme in ihrem Unternehmen geht. Hier noch einmal eine kurze Zusammenfassung:

Einzelne, zentral verwaltete Shimdatenbank Bei dieser Option wird eine einzelne, zentral verwaltete Shimdatenbank bereitgestellt, die Einträge für jede Anwendung enthält, die ein Shim benötigt. Sie können die zentrale Datenbank aktualisieren, wenn Sie weitere Anwendungen ermitteln, die Patches erfordern. Dies ist das von Microsoft verwendete Verfahren. Im Lieferumfang von Windows 7 ist eine System-Shimdatenbank mit Patches für Tausende von Anwendungen enthalten. Wenn wir neue Anwendungen mit Patchbedarf finden, stellen wir Aktualisierungen der Datenbank über Windows Update zur Verfügung. Sie können genauso vorgehen: Integrieren Sie eine Shimdatenbank in Ihr Masterabbild, und aktualisieren Sie sie über Ihre Systemverwaltungssoftware (z. B. System Center Configuration Manager).

Anwendungsspezifische Shimdatenbanken Alternativ können Sie Anwendungspatches direkt mit der Anwendung bereitstellen. Einige Kunden entscheiden sich für diese Strategie, wenn nur eine oder zwei ihrer Anwendungen Patches benötigen, da diese Vorgehensweise in einer kleinen Umgebung kostengünstiger sein kann als die Einrichtung eines Prozesses zur Verwaltung einer zentralen Datenbank. Anwendungsspezifische Shimdatenbanken haben jedoch einen großen Nachteil: Im Fall von Problemen ist die Aktualisierung der Shimdatenbank schwierig. Dieser Nachteil wird jedoch von App-V ausgeglichen, denn nun können Sie die anwendungsspezifische Datenbank aktualisieren und die aktualisierte Version per Streaming den Benutzern zur Verfügung stellen. (Wie Sie jedoch sehen werden, entsteht hierdurch ein weiterer, sehr viel schwerer wiegender Nachteil.)

Die Art und Weise, wie Software von Microsoft App-V bereitgestellt wird, gibt Ihnen mehr Möglichkeiten zur Bereitstellung von Anwendungspatches im Unternehmen; zudem können Sie das Verfahren wählen, das für das aktuelle Prozessmodell Ihres Unternehmens am besten geeignet ist.

Shimmen von App-V-Anwendungen mit einer einzelnen, zentral verwalteten Shimdatenbank

Wie müssen Sie also taktisch vorgehen, um eine einzelne, zentral verwaltete Shimdatenbank bereitzustellen und dafür zu sorgen, dass sie von einer mit App-V sequenzierten Anwendung verwendet wird? Das ist ganz leicht – führen Sie die Installation einfach wie gewohnt durch. Eine mit App-V installierte Anwendung wird fast genauso gestartet wie normalerweise und verwendet die gleichen Lademechanismen mit angewendeten Shims. Sie werden lediglich von einem Ersatzprozess gestartet. Genauer gesagt ist sfttray.exe das Element, das den neuen Prozess anstelle von Explorer startet. Die sich daraus ergebende Prozessstruktur ist in Abbildung 3 dargestellt.

Abbildung 3 Ersatzprozessstruktur

Wenn die Anwendung gestartet wird, durchläuft sie das Ladeprogramm wie jede andere Anwendung auch. Die Clientschnittstellenschicht von Microsoft Application Virtualization (sftintf.dll) ruft CreateProcessW auf, die wiederum die interne API CreateProcessInternalW aufruft. In der CreateProcessInternalW-API wird das Shimmodul aufgerufen, und Shims werden in den Prozess eingebunden.

Das ist also ganz einfach. Hat die Sache irgendwelche Haken? Ja, einen Haken gibt es. Die Verarbeitung von erhöhten Rechten funktioniert nicht richtig. Sie können z. B. nicht einfach erhöhte Rechte für eine Anwendung anfordern (mit einem RunAsAdmin-Shim) oder mit ElevateCreateProcess Probleme mit Anwendungen beheben, die erhöhte Rechte erfordern. Warum? Wegen der Blase.

Nehmen wir z. B. eine Anwendung, die versucht, ein automatisches Update für sich selbst zu starten (was leider allzu häufig passiert). Angenommen, bei systemeigener Ausführung lag das Problem vor, dass die Anwendung die CreateProcess-API verwendete, die keine erhöhten Rechte aufrufen kann. Daraufhin wird folgender Fehler zurückgegeben: -1073740756 – STATUS_ELEVATION_REQUIRED. Das ElevateCreateProcess-Shim fängt diesen Rückgabewert ab und ruft dann den Anwendungsinformationsdienst auf, damit dieser die erhöhten Rechte bereitstellt. Dieser Dienst kann jedoch die entsprechende Anwendung nicht finden, weil der Dienst nicht in der Blase enthalten ist.

Solange für Ihre Anwendung also keine erhöhten Rechte erforderlich sind, ist die Bereitstellung einer einzelnen Shimdatenbank ganz einfach, sofern Sie bereits einen Prozess ausgearbeitet haben – Sie machen einfach wie gewohnt weiter.

Shimmen von App-V-Anwendungen mit anwendungsspezifischen Shimdatenbanken

Alternativ können Shims zum Lösen von Problemen mit der Anwendungskompatibilität auch mit der jeweiligen Anwendung bereitgestellt werden. In der MSI-Welt wird hierzu normalerweise die SDB-Datei in das Installationsprogramm aufgenommen und dann eine benutzerdefinierte Aktion integriert, die sdbinst für die abgelegte SDB-Datei aufruft. Damit wird die benutzerdefinierte Shimdatenbank als Teil des Installationsprogramms installiert. (Wenn später eine Aktualisierung der Shims für diese Anwendung erforderlich wird, müssen Sie alle installierten Clients ermitteln und ein Skript zur Installation eines Updates ausführen; hierdurch wird das Verfahren ein wenig komplizierter.)

Mit App-V können Sie praktisch genau das gleiche tun. Sie können die Shimdatenbankdatei (.sdb) in die Sequenz selbst aufnehmen, sodass die SDB-Datei innerhalb der Blase vorhanden ist. Zunächst muss die Anwendung, die Shims benötigt, so sequenziert werden, dass sie ordnungsgemäß funktioniert. Anschließend ziehe ich gerne die benutzerdefinierte Shimdatenbank in system32.

(Normalerweise sage ich ja, dass Sie auf gar keinen Fall Elemente in system32 ablegen dürfen, es sei denn, Ihr Gehaltsscheck wird von Steve Ballmer unterschrieben und Steven Sinofsky gehört zu Ihren Vorgesetzten – in diesem speziellen Fall jedoch gebe ich Ihnen die Erlaubnis dazu, weil es die Skripterstellung vereinfacht. System32 ist dann im Pfad enthalten, und Sie hinterlassen nicht wirklich etwas in system32 auf einem Produktionssystem, sondern nur in einer Datei, die für das virtuelle Dateisystem wie system32 aussieht.)

Anschließend bearbeite ich die SPRJ-Datei. Ich navigiere zur Registerkarte Virtual File System und klicke auf View | Virtual File System | Add. Anschließend navigiere ich zu dem Speicherort, an dem ich die SDB-Datei abgelegt habe (c:\windows\system32\appshim.sdb), und klicke auf OK. Nun ist diese SDB-Datei in der Blase vorhanden und wird bei der Installation des SoftGrid-Pakets ebenfalls installiert. Da die Datei Teil des Containers ist, wird sie als Teil der Anwendung geführt (und kann zusammen mit der Anwendung aktualisiert werden.)

Natürlich reicht es zur Anwendung der Anwendungspatches nicht aus, wenn die SDB-Datei lediglich im Dateisystem vorhanden ist – die Patches müssen installiert werden. Die Shimdatenbank muss jedoch außerhalb der App-V-Blase installiert werden. Wenn Sie die Shimdatenbank innerhalb der Blase installieren, kann die virtualisierte SDB-Datei erst erkannt werden, nachdem der Prozess erstellt wurde – dann ist es zu spät für das Shimmodul, nach der Datei zu suchen und Maßnahmen für diese zu ergreifen. Das Ladeprogramm muss außerhalb der Blase auf die Shimdatenbank zugreifen können, während der Prozess erstellt wird.

Glücklicherweise enthält App-V einen Mechanismus, um Skripts als Teil des Anwendungsstartprozesses auszuführen. Wenn Sie die OSD-Datei für eine Anwendung in einem Texteditor betrachten, werden Sie feststellen, dass diese lediglich bearbeitbaren XML-Code enthält. Das <SOFTPGK>-Element enthält ein <IMPLEMENTATION>-Element, ein <DEPENDENCY>-Element, ein <PACKAGE>-Element, ein <ABSTRACT>-Element, ein <MGMT_SHORTCUTLIST>-Element und ein <MGMT_FILEASSOCIATIONS>-Element. Das <DEPENDENCY>-Element möchten Sie bearbeiten – Sie fügen untergeordnete <SCRIPT>-Elemente hinzu, um die Installation der benutzerdefinierten Shimdatenbank auszuführen. Nachfolgend sehen Sie ein Skriptbeispiel, mit dem die benutzerdefinierte Shimdatenbank beim Starten der Anwendung installiert und beim Schließen der Anwendung wieder entfernt wird (also eine JIT-Installation, die hinter sich aufräumt, ein wichtiges Ziel von App-V):

<DEPENDENCY>
       <CLIENTVERSION VERSION="4.6.0.0"/>
       <SCRIPT EVENT="LAUNCH" PROTECT="TRUE" TIMING="PRE" WAIT="TRUE" EXTERN="TRUE">
<SCRIPTBODY LANGUAGE="Batch">sdbinst /q appshims.sdb</SCRIPTBODY>
       </SCRIPT>
       <SCRIPT EVENT="SHUTDOWN" PROTECT="TRUE" TIMING="POST" WAIT="TRUE" EXTERN="TRUE">
              <SCRIPTBODY LANGUAGE="Batch">sdbinst /u appshims.sdb</SCRIPTBODY>
       </SCRIPT>
</DEPENDENCY>

Mit diesem Skript wird das Installationsprogramm der Shimdatenbank (sdbinst.exe) von außerhalb der App-V-Blase aufgerufen, jedoch ein Argument einer SDB-Datei verwendet, das sich innerhalb der App-V-Blase befindet und folglich im Rahmen der Anwendungsbereitstellung bereitgestellt wird. Auf diese Weise können die Anwendungspatches genauso einfach bereitgestellt und aktualisiert werden, als wären sie ein Teil der Anwendung.

Für die Installation von benutzerdefinierten Shimdatenbanken sind Administratorrechte erforderlich; ist es ein Problem, dass wir die Installation zur Laufzeit durchführen? Sie möchten nicht, dass Ihre Benutzer Administratorrechte benötigen, und die Benutzer möchten sich nicht bei jedem Start der Anwendung durch Dialogfelder zur Benutzerzugriffssteuerung klicken müssen. Dies ist zum Glück nicht erforderlich; der Aufruf von sdbinst.exe wird automatisch mit erhöhten Rechten ausgeführt. Die Prozessstruktur für die Installation der Shims ist in Abbildung 4 dargestellt.

Abbildung 4 Prozessstruktur der Shiminstallation

Es wird eine Befehlsshell erstellt, die dann sdbinst.exe aufruft, um die benutzerdefinierte Shimdatenbank zu installieren. Für diesen Vorgang wird zweimal die Fehlermeldung STATUS_ELEVATION_REQUIRED ausgegeben, bevor der Anwendungsinformationsdienst aufgerufen wird; dieser Dienst stellt die erhöhten Rechte bereit. Der Dienst ruft consent.exe auf; dieses Tool überprüft die Richtlinie daraufhin, ob die Anwendung mit erhöhten Rechten ausgeführt werden muss. Die Richtlinie (in der virtuellen Umgebung) bejaht dies, ohne den Benutzer zu einer Eingabe aufzufordern; consent.exe genehmigt die erhöhten Rechten, und es wird eine Instanz von sdbinst.exe mit erhöhten Rechten erstellt, die die benutzerdefinierte Shimdatenbank installiert. Beachten Sie jedoch, dass eine Richtlinie zur Ausführung mit erhöhten Rechten ohne Eingabeaufforderung nur dann im Hintergrund ablaufen kann, wenn Sie über die entsprechenden Rechte verfügen. Wenn Sie ein Standardbenutzer sind, werden Sie bei jedem Start und bei jedem Schließen der Anwendung zur Eingabe von Administratoranmeldedaten aufgefordert. In einer Standardbenutzerumgebung ist diese Situation absolut nicht wünschenswert, daher funktioniert diese Vorgehensweise nur, wenn Sie lokale Administratorbenutzer bereitgestellt haben. Wir hoffen, dass der Prozentsatz der Benutzer, auf die dies zutrifft, sehr gering ist!

Schlussbemerkung

Microsoft Application Virtualization ist ein leistungsfähiges Tool zur Anwendungsverwaltung und -bereitstellung. Wenn Sie es in Ihre Pläne für eine Windows 7-Migration einbeziehen, können Sie von den potenziellen Kostensenkungen bei Installationstests profitieren (ganz vermieden werden können diese Kosten jedoch nicht).

Zudem können Sie weiterhin die meisten der Prozesse zum Lösen von Anwendungskompatibilitätsproblemen mit Shims nutzen. Wenn Sie eine einzelne unternehmensweite Shimdatenbank bereitstellen, ist die Umstellung minimal – Sie müssen lediglich darauf achten, Shims zu vermeiden, für deren Ausführung erhöhte Rechte benötigt werden (wie Sie auch generell erhöhte Rechte in einer App-V-Umgebung vermeiden sollten). Wenn Sie anwendungsspezifische Shims bereitstellen, gibt es einige elegante Methoden, um die Shimdatenbank mit der Anwendung zu packen und bereitzustellen; allerdings hat dies den entscheidenden Nachteil, dass Benutzer ohne Administratorrechte die Anwendung nicht auf vernünftige Weise ausführen können. Ich empfehle daher dringend (wie bei MSI-basierten Anwendungsbereitstellungen), Shims nach Möglichkeit als einzelne, zentral verwaltete Datenbank bereitzustellen, die mit der vorhandenen Systemverwaltungssoftware bereitgestellt werden kann. So kann in Zukunft ein immer größerer Prozentsatz der Benutzer ohne Administratorrechte arbeiten.

Chris Jackson (der „Guru“ für Anwendungskompatibilität) ist ein wichtiger Berater bei Microsoft und technischer Leiter des Windows Application Experience SWAT-Teams. Jackson ist ein weithin anerkannter Experte auf dem Gebiet der Windows-Anwendungskompatibilität. Die von ihm verfassten technischen Dokumente sowie seine Schulungs- und Serviceangebote werden bei Microsoft und auch in anderen Unternehmen genutzt und basieren auf langjähriger praktischer Erfahrung mit Unternehmenskunden und unabhängigen Softwareanbietern. Jackson kann über seinen beliebten Blog erreicht werden.

Verwandter Inhalt

• Blog des App-V-Teams
• Application Virtualization TechCenter
• Erste Schritte mit Microsoft Application Virtualization