Programme, die mit Standard User Rechten ausgeführt werden – und das sind bei eingeschalteter UAC alle, die nicht mit einem Manifest mit einer erhöhten Ausführungsebene markiert sind – werden unter Windows Vista besonders behandelt. Werden diese Programme mit dem Standard User Token ausgeführt, werden alle Zugriffe auf das Verzeichnis %PROGRAMFILES%, %WINDIR%, und %WINDIR%\System32 sowie auf die Registry unter HKLM\Software umgeleitet.
Ein Dateizugriff wird dann nach %LOCALAPPDATA%\VirtualStore umgeleitet und ein Zugriff auf die Registry landet schliesslich in HKCU\Software\Classes\VirtualStore\MACHINE\SOFTWARE. (Anzumerken ist, dass Klasseneinträge HKLM\Software\Classes nicht virtualisiert werden und der schreibende Zugriff für einen Standardbenutzer sowohl für HKLM\Software\Classes, als auch für HKCR unter Windows Vista nicht mehr zugelassen ist!)
Problematisch wird das ganze, wenn ein Administrator oder ein Prozess mit erhöhten Rechten die echten Daten in HKLM und %PROGRAMFILES%, %WINDIR%, etc. ändert und im VirtualStore entsprechende bezeichnungssynonyme Daten vorhanden sind. Diese Ausgangslage ist auch gegeben, wenn ein Softwareupdate mit erhöhten Rechten (was die Regel ist) diese Daten in HKLM und/oder an nicht zugelassenen Verzeichnisorten (%PROGRAMFILES%, %WINDIR%, etc.) updatet oder mit Ergänzungen (bestehende INI + Dateiinhalte) erweitert, die für den Betrieb der neuen Version notwendig sind. Konfuse Situationen können dabei nicht nur bei small und Minor Updates auftreten, sondern auch bei Major Upgrades in der Form von „lösche die Vorversion und installiere die neue Version“, weil auch nach solchen Anwendungsfällen nach der Installation verschiedene Versionen von Daten möglich sind. Solche in nichtvirtualisierter Umgebung und solche, die virtualisiert abgelegt sind.
In diesen Szenarien bleibt die Änderung der Daten in HKLM und %PROGRAMFILES%, %WINDIR%, etc. ohne Wirkung! Denn die Daten aus dem VirtualStore werden hier mit Vorrang behandelt. Das heisst: Sollten Daten sowohl im VirtualStore, als auch in den eigentlichen originalen Positionen existieren, dann werden immer die Daten des VirtualStore verwendet, unabhängig allfälliger verfügbarer neuerer Versionen an den originalen Positionen.
Macht also ein Softwareupdate Korrekturen an den realen Daten und es existieren Teile davon im VirtualStore, dann kann ein unerwartetes Verhalten beim Betreiben der Anwendung eintreten, da durch den Update eine gemischte Umgebung mit alten Daten im VirtualStore und neuen Daten an den originalen Positionen entsteht.
Wie erkennt man virtualisierte Daten?
Neben der direkten Anzeige von den Daten aus dem VirtualStore via Explorer und Regedit erlaubt es der Explorer auch auf die virtualisierten Datenteile zuzugreifen, indem man auf die Schaltfläche Kompatibilitätsdateien klickt. Diese Schaltfläche ist verfügbar, sobald der Windows Explorer in einem Verzeichnis oder Unterverzeichnis virtualisierte Dateien feststellt. Durch den Klick auf die Schaltfläche wird das Verzeichnis des VirtualStore Verzeichnisordners, bzw. ein darunterliegendes angezeigt.
Die Ereignisanzeige (eventvwr.exe) protokolliert zudem Dateivirtualisierungen unter der Struktur Anwendungs- und Dienstprotokolle/Microsoft/Windows/UAC-FileVirtualization-/Operational. Dort können erweiterte Informationen abgefragt werden.
In Migrationsprojekten kann auch das durch Microsoft zur Verfügung gestellte Application Compatibility Toolkit helfen, in bestehenden Umgebungen UAC-Verstösse der Applikationen aufzuzeigen.
Massnahmen:
Für Entwickler ist die Sachlage klar: Diese täten gut daran, die Windows Vista Logo Richtlinien schnellstmöglich umzusetzen, sofern ihre Programme auch unter Windows Vista zum Einsatz kommen. Dann fänden wir auch keine virtualisierten Elemente mehr auf unseren Clients.
In einer Firmenumgebung und im Deployment sollten wir hingegen von Fall zu Fall entscheiden, wie zu reagieren ist. Leider haben wir dort vielfach nur beschränkte Möglichkeiten zu bestimmen, dass eine Anwendung im Falle von UAC-Verstössen gleich aus dem Portefeuille der zu bereitstellenden Applikationen gestrichen wird. Andererseits erhalten wir vom Entwickler oft nicht in der gewünschten Zeit ein Update auf eine Vista taugliche Version. Daher sind Kompromisse entscheidungsbestimmend.
Generell bewährt sich die Methode, dass man vor dem Einstatz der entsprechenden Software, diese auch auf UAC-Verstösse analysiert. Das kann bedeuten, dass man in einer Testumgebung von der softwarefachverantwortlichen Person einen Test auf einem „sauberen“ Vista Client fährt. Auf die dort gesammelten Daten des VirtualStore kann zum einen mit einer Lockerung der Benutzeberechtigung auf die ermittelten Registrierungsschlüssel und/oder Dateien reagiert werden oder die Daten werden nach einem Update durch den Installationsprozess selbst (direkt über Reparaturmechnismen des Windows Installers, über eine Active Setup Implementation oder über anderweitige Umsetzungen) im VirtualStore des Benutzers entfernt. Im Falle dass es sich bei den virtualisierten Daten um „gemeinsame Daten“ mit anderen Usern handelt (es soll beispielsweise immer noch Datenbankanwendungen geben, welche zwingend eine Datenbank in ihrem Programmverzeichnis benötigen und welche von mehreren Personen auf dem gleichen Computer eingesetzt wird) kann von den eben beschriebenen Varianten nur eine Lösung resultieren. Nämlich die der Lockerung der ACL.
Eine andere Möglichkeit bestünde darin, dass die verantwortliche Programmdatei gleich mit einem Manifest mit erhöhten Rechten markiert würde. Dies hiesse aber auch, dass nur Administratoren in der Lage wären, die betroffene Software korrekt auszuführen, was in vielen Fällen nicht gewünscht ist.
Weitere Einschränkungen sind schliesslich mit der Policy Virtualize file and registry write failures to per-user locations möglich, mit Hilfe deren man die Virtualisierung komplett abschalten kann. Aber auch hier müsste man nötigenfalls auf eine Lockerung der Benutzerberechtigung zurückgreifen, wenn man denn den Betrieb solcher Software zulassen wollte. Nebenbei bemerkt, sollten ACL-Änderungen nur für anwendungsspezifische Ressourcen ins Auge gefasst werden, nicht aber für Ressourcen, die das gesamte Betriebssystem betreffen.
Eine abschliessende Antwort betreffend Empfehlungen, wie im konkreten Sachverhalt reagiert werden soll, kann daher nicht gegeben werden, ausser dass eine Abwägung der Massnahmen von Fall zu Fall in Erwägung gezogen werden sollte.
Jedefalls ist es ein Thema mehr, dass man beim Packaging unter Vista berücksichtigen müsste.
Siehe auch http://support.microsoft.com/kb/927387/de
