App-V 5 and UAC File Virtualisation

In App-V 5 we no longer have PKG files, and changes made by the user are stored hidden away in various folders and registry keys instead.  Check out Thamim Karim’s articles here, here and here for a full explanation of how these locations work.  But essentially, file changes are stored here:

  • %APPDATA%\Microsoft\AppV\Client\VFS  (for roaming appdata)
  • %LOCALAPPDATA%\Microsoft\AppV\Client\VFS  (for everything else)

Whilst registry changes are stored here:

  • HKCU\Software\Microsoft\AppV\Client\Packages\<PackageGUID>\REGISTRY

However, this is not always the case.  If you are running an app under the following conditions:

  • You have UAC enabled
  • You are not running the app as administrator
  • The app is 32-bit
  • The app has no embedded or external manifest to tell it which execution level to use (i.e. asInvoker, highestAvailable, requireAdministrator) – typically all applications prior to Vista, and even some still being made today

Then the app will automatically redirect failed writes to certain system areas such as C:\Program Files and HKLM\Software to the following locations via a process known as UAC file virtualisation (not to be confused with App-V virtualisation):

  • %LOCALAPPDATA%\VirtualStore
  • HKCU\Software\Classes\VirtualStore

Now, consider that you are sequencing such an application and you have UAC enabled.  Instead of launching the application from the sequencer interface, which is running elevated, you run it via its shortcut and configure the application.  If it is a badly written legacy app that tries to write to these system areas, Windows silently redirects the write operations to the locations shown above.  Files will be excluded from the resulting sequence if you are using the default sequencer configuration to exclude %LOCALAPPDATA%, and registry will be captured under the VirtualStore key:

ExclusionWarning

CapturedVirtualRegistry

When you run the application on the client, any files or registry keys written here will not be visible.  It seems the UAC virtualisation system only looks in those two locations on the local system and ignores anything in the virtual environment.

Now, in another scenario, ignoring what happens during sequencing – what happens when you try to write to these locations when running inside the App-V client?  For the registry, same as usual – users have full permissions to write to HKCU and HKLM.  However, I noticed that HKLM writes get stored under Classes, something not mentioned in the articles linked to earlier:

  • HKLM: HKCU\Software\Classes\AppV\Client\Packages\<PackageGUID>\REGISTRY\MACHINE
  • HKCU: HKCU\Software\Microsoft\AppV\Client\Packages\<PackageGUID>\REGISTRY\USER\<USERSID>

Standard users will not be able to write to Program Files without resorting to the method I published recently.  The difference is that if the app satisfies the UAC virtualisation criteria, writes will be redirected to the VirtualStore folder, outside of the virtual environment:

LocalVirtStoreFile

I consider these bugs, resulting in the following issues:

  • The sequencer may not capture all desired files and registry
  • When launched, different packages could have conflicting files in the VirtualStore
  • When repairing the virtual app, any files in the VirtualStore will not be removed

If you have an application that is suffering from this problem, the workaround is to put a manifest next to the executable configured to use a suitable execution level:

  • requireAdministrator – use this if your intended users have admin rights and you want to pop up a UAC prompt.
  • asInvoker – this will not produce a UAC prompt – users will be able to write to HKLM since App-V allows this, but if you want the app to write to protected file system areas you will have to use my pre-launch script method to apply permissions to the VFS.

For example, for an app named Test.exe, put this in a text file named Test.exe.manifest in the same folder:

 
These tests were of course done using App-V 5. I haven’t tried the same scenarios on App-V 4, but it’s possible the same problems exist there also!

4 responses on “App-V 5 and UAC File Virtualisation

  1. Prem

    While launching prelaunch script like batch file. (C:\windows\System32\Cmd.exe mybat.cmd”), i wan this cmd.exe to run elevated privilege, how can i createmanifest for this, and where can i copy that file. directly under C:\windows\system32 or within the bubble?

    1. Don’t go there. Replacing the manifest of cmd.exe is a bad idea. If you can’t use a machine script (e.g. AddPackage or PublishPackage), which will automatically run elevated under the system account, your best bet is to write a self elevating script (don’t forget all your users will need admin rights):

      http://blogs.technet.com/b/elevationpowertoys/archive/2010/06/20/creating-a-self-elevating-script.aspx

      Also don’t forget your /c switch after cmd.exe.

  2. vp

    I tried to sequence firefox browser in App-V 5.0 SP1. One of the applications I’m testing has a drag and drop plugin which uses Java within.
    I noticed that I can drag and drop a file on a Windows 8.x desktops but the same doesn’t work on Windows7 desktops. Tried to play around with Java plugin security, firefox settings etc but nothing works. Do you know how come the same app works on Windows8 but not Windows 7?
    I’m thinking it has something to do with Shell extensions http://technet.microsoft.com/en-us/library/dn629577.aspx but not sure how to get this working,
    Really appreciate your response.

    Thanks

    1. So this has a Java applet inside a web page that allows you to drag content to the desktop? Not sure why it’s not working on Win7, but probably nothing to do with shell extension settings in the package. Look into what else might be different, such as Java and IE versions, UAC settings, etc.

Leave a Reply