Permissions In The PVAD And VFS With App-V 5.0 - Virtual Vibes

Following on from my post called Understanding the PVAD where we talked about how things work in the absence of the Q: mount drive we had in previous versions of App-V, I want to share with you some insights into how permissions work on both the PVAD and VFS for both admin and non-admin users.

For those familiar with the security descriptors checkbox in App-V 4.x you will know that it is no longer available in App-V 5.0. Unchecking the security descriptors box in App-V 4.x allowed us to open up the permissions on our package file system to allow non-admin users write access, this was brilliant for applications that traditionally would require admin rights for run correctly and also meant the practice of making standard users local admins on their machines wasn’t a necessity for the apps.

I see a lot of these types of applications day to day with our customers, applications that at launch require write access to a global location such as C:\Program Files, whether the app writes a new file or folder, amends something that already exists or is just badly written and checks for permission as part of its launch sequence.

So how do things work in App-V 5.0?

In short the PVAD has write access to both admin and non-admin and the VFS only gives write access to admin.

Take this application called MyBatch for example, a simply batch app that will attempt to write a .txt to the PVAD and then attempt to write a .txt to the VFS.

As you can see I have sequenced it to the PVAD of C:\Program Files\MyBatchPVAD and also created a test global VFS folder C:\Program Files\MyBatchVFS

Let’s deliver this application and run it as an admin user…

As you can see we successfully write to both the PVAD and global VFS as an administrator on the machine. Now let’s try as a standard user:

So as above, a non admin user can only write to the PVAD (PLEASE NOTE: There are some restrictions on exactly what types of files we can write into the PVAD), if they try and write to the global VFS they get an access denied. Another interesting point is the standard user does not see the global VFS changes that were made by the administrator previously, more on that later. A third point is this restriction on VFS is only for global locations, the user can obviously write to their own user profile locations regardless of whether it is VFS or locally held.

This table summaries how things work:

So in summary if you need your non admin users to have write access to your App-V package, make sure that location is the same as what you specify for the PVAD. To be clear, this all relates to the application making these changes, not a user manually browsing to these locations and making a change to the cache outside of the virtual environment.

Now you understand how the permissions are handled inside the virtual environment, you might be wondering, where do file changes to the PVAD and VFS get stored? Click here to find to out!