Permissions in the PVAD and VFS with App-V 5.0

Share on facebook
Share on twitter
Share on linkedin
Share on reddit
Share on stumbleupon

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!

Leave a Reply.

43 thoughts on “Permissions in the PVAD and VFS with App-V 5.0”

  1. It’s a shame that there’s no way to open up these permissions – there will be plenty of badly written legacy applications that depend on quote access to certain locations. With Windows Installer we could set permissions on install, with App-V 4 we could change permissions during sequencing and they would be captured, or we could disable security descriptors entirely… With App-V 5 it seems the only option we have is to use shims. I hope that Microsoft take notice and provide a way to really alter permissions in a future update. Until then, I have my own workaround!…/file-permissions-app-v-5

    • Hi Dan, thanks for sharing your blog post, the team are aware that the ability to modify permissions in the VE is highly desired with App-V 5.0. Sequencing to the PVAD or specifying it as the place you would like to be writable is one technique you may employ, although this isn’t ideal for apps that have multiple locations. App-V 5.0 is really just keeping the default security of the folders that are outside of the package root but I do agree this does not give us as much flexibility as we had in previous versions.

  2. Whatever descibed above , I tried to implement the same as an admin and non-admin and found was not positive.

    Please let me know, whether we could write or not as an admin or user in C:\ProgramData\App-V\71A57C9A-3E3F-4308-B8E1-3909096F02E6\C549E4AE-DEF3-4BD1-83EB-59639F648F44\Root and C:\ProgramData\App-V\71A57C9A-3E3F-4308-B8E1-3909096F02E6\C549E4AE-DEF3-4BD1-83EB-59639F648F44\Root\VFS


    C:\Users\ABCD\AppData\Local\Microsoft\AppV\Client\Integration\7532754F-9420-4D4E-B0F5-D55E94EB67EA\Root and C:\Users\Gautam\AppData\Local\Microsoft\AppV\Client\Integration\7532754F-9420-4D4E-B0F5-D55E94EB67EA\Root\VFS

    Please give brief descriptions based on above directory structure.

    • The thing to understand is the article relates to permissions the user has when running the application not the ability for a user to directly go and modify those locations outside of the application running in the VE.

      There is no documented or supported way to directly change either location you have specified, the cache holds a static state and is not writable, state changes are described in more detail here:…/app-v-5-0-os-integration-part-4-state-changes.aspx

      This article describes what state changes are permitted across VFS and PVAD for non-admin and admin.

      • Thank you for your response Thamim

        As per above mentioned contents “PVAD has write access to both admin and non-admin and the VFS only gives write access to admin.” but when i checked , i found that both admin and non-admin have write access to PVAD , VFS in “C:\Programdata\APPV\…………” on Client.

        Can you please let me know your thought on this?

        • First can you please clarify, in what context you are trying to make changes? Are you physically browsing to the cache location and trying to change files or are you running an App-V package that writes to these locations?

          • Gautam6584

            Avatar of Gautam6584

            3 Sep 2013 1:13 PM

            I installed the package and then launces shortcuts , then navigated File—>Open—> and reached to PVAD(root) and VFS location in VE and tried to create new folder in Root directory and in VFS directory as Admin and as Non Admin and in both cases , i was able to write.

  3. Ah okay great. Is the VFS directory a user profile based location? If not, have you changed the default permissions on the root of the place where the VFS folder resides?

    • VFS directory have two other directories i.e; ProgramFilesCommonX86 , windows .

      I didn’t alter permission , we are working with default permission only.

      • In that case, I cannot explain the behaviour you are seeing nor am I able to replicate it. Feel free to use the “Email Blog Author” button above if you would like to share the package with me to see if I can find anything.

  4. Hmmmm I am assigning my PVAD during sequencing as the install directory but when I deploy my app, users are presented with an error cannot find C:\Myapp\Myapp (which I specified as the PVAD). When trying to browse to this location by typing it in manually (as I know it is hidden) it says that it doesn’t exist. Am I missing something?

  5. Here is a solid solution for the C:\ProgramData allowing write permissions for everyone Full. But I am unable to get write access to the C:\Users\admin\Appdata\Local\Microsoft\AppV\Client\VFS\”GUID”\Common Appdata, now that being said, once the application is launched I can go in and manually add permissions which has resolved the issue for me 100% of the time, but I cannot do that for every user, ugh. Need help on that one.

    Here is the cure C:\ProgramData\…. Permissions

    Within the DeploymentConfig.xml file locate the Machine scripts, take out the “Comments” and the following lines.


    /c %SYSTEMROOT%\System32\icacls.exe “[{AppVPackageRoot}]\VFS\Common AppData” /grant Everyone:(OI)(CI)F


    • Hi Paul, The scripts you mentioned abve , i am not able to run successfully.It gives error , i.e; invalid xml documents. Moreover , Please see error i mentioned above.

  6. You can do that by running it as a userscript instead.

    then change acl by removing the folder and adding it again, then the security will be opened.

  7. This is the error i am getting , when i am trying to load the dynamic configuration file(xml file) while publishing. DOM Error: Unknown HResult Error code: 0xc00ce224 Reason: Het knooppunt is geldig of ongeldig, omdat er geen DTD/schemadeclaratie is gevonden. Error we gets in powershell GUI , invalid xml document. Please let me know , what can be done to successfull load the configuration file.

  8. Thamim — I have couple of questions to be answered.. 1. I have a 5.0 converted package where in after install the application is unable to write or modify files to its own folder and reporting as access denied. Is there any ways that it can be fixed. 2. For some 5/0 converted applications, even DLL files are present inside the bubble where it was in 4.6 package but still upon shortcut launch it throws that file is missing, any reason for this and anyways to fix this.

  9. Gautam, can you check you can replicate this with SP2 please. Arokiyaraj, 1. If you package is entirely VFS then non-admins won’t have access as described in this post. 2. Please can you upgrade to SP2 and check that this is still an issue please.

  10. Hi Thamim – Thank you so much for your suggestion. I do have a straight General question. So any applications which are converted from 4.6 to 5.0 will have VFS folder structure ?, If so NON-ADMINS will not have access to modify something on that manually. But Is this same applicable to the application it self to modify certain files during runtime on the Standard users environment. Thanks

  11. Hi Arokiyaraj, this is not a scenario I have tested and would need to be done on a package basis

    • Hi Thamim,

      I have a package that was already sequenced using 4.6 but now I have converted that package to App-V 5.0 format using the powershell commands.

      If I go to the C:\ProgramData\App-v\ location of the package and try to create a folder under my application’s folder, it gives access denied error (both for Admin user and Non-admin user). I tried to Re-Convert it (with powershell commands) using App-V 5.0 SP2, but still I face the same issue.

      Somewhere I read that in Sequncer under the Advanced tab if we check the last checkbox, we can resolve the issue. But this also didn’t work out for me.

      Can you please confirm that:
      1. Is it possible for a user(both standard and admin) to write to a file that already exists in the C:\ProgramData\App-V\ location?

      2. Is it possible for the virtual package user to create a folder manually in the C:\ProgramData\App-V\ location?

      Thanks in advance.

        • Hi Thamim,

          Thanks a lot for the valuable information.

          I have one more doubt regarding the application that are creating context menu entries.

          I have noticed that when we unpublish those packages globally, it creates Pending task registry and we can remove the package from the machine only after the reboot operation.

          I tried using Stop command also prior to the Unpublish operation, but this command kills the explorer which might hamper my client’s work.

          Is there any other way to have a clean Unpublish and Removal of the packages that have shell extensions or Context menu entries on right click.

          (I tried with 7-Zip, BeyondCompare and Notepad++)

          Also please confirm that whether this thing will be handled automatically by SCCM 2012 ?

          Thanks in advance.
          And once again thanks for replying to my previous query.

          • Hi Mohit,

            The reason it fails to unpublish is because the package is in use, the only way to stop it being in use is by closing any process that is using the virtual environment, either manually or how you describe via PowerShell. Full details are here:

            SCCM 2012 will handle this fine, although I believe only SP2 has full support for reporting back on pending status instead of reporting it as failed.

  12. Hi Thamim,

    Thanks a lot for the information,

    Yes I have checked, the PendingTask key feature is available in SP2 version onwards.

    In my client’s infrastucture, we have both SCCM 2007 and SCCM 2012 machines, as you said that SCCM 2012 will handle the Unpublishing and Removal of the package automatically even if we have a context menu entry or a shell extension, but can you please provide me a solution for SCCM 2007 so that rather than killing the explorer(using STOP command) or Forcing a Reboot (on using Unpublish command without STOP) we can uninstall the package in one go?

    Will it work if we try installing the MSI rather than .appv file in SCCM 2007.

    Thanks in advance.

    • SCCM 2007 does not natively support App-V 5.0 so you would need to deliver packages using a scripted approach. Even if you issue a “Unpublish-appvclientpackage” via a scripted approach it still would leverage the pending tasks feature you refer to when a package is in use and cannot be unpublished.

  13. It is quite amazing what problems you can solve by cleverly editing or adding COW mappings. Although, I do wish there was additional documentation on this. I had to experiment a lot to get the hang of some of it.

  14. By default the PVAD is disabled since App-V 5.0 SP3 , we believe all the packages can be created successfully without any issues (as we can provide full control to VFS folder and we can also resolve the same PVAD issues in a connection group).

    But when we are creating package in our envrionment we are failed to create packages with VFS option where as the same package gets created successfully if we create with PVAD option.

    I would like to know the reason why it is not working in VFS.

  15. Thanks for the reply. But please can you give me the brief idea why these applications are failed to work in VFS?. are there any specific reason or categorizations which does not work in VFS?

    • To be frank there doesn’t seem to be a clear categorisation of applications that require PVAD sequencing. I believe the failures with VFS are due to how the apps are written and how they expect to find their file assets. Unfortunately I can’t give much more insight on this

  16. Thanks for the reply.

    I have one other query, but I do not know where should I post this. But would like to express here in the same blog.

    Could you let us know is there a possibility sequencing the Adobe Acrobat X / Xi. How to handle printer drivers in it. As we do not sequence printer driver, I have tried separating the drivers from the package but failed to do so. Please guide me are there any other documents where I can get much insight to create packages for driver applications.

  17. Hello,
    Great post.
    Just a short question; I’ve sequenced an application that download updates to “C:\Program Files (x86)\applicationName”
    After the sequencing I’ve tested this on a testclient, the strange thing is that when I start the application it will “download the updates” inside C:\Program Files (x86)\applicationName and not inside C:\ProgramData\App-V\xxx

    I though that it wouldn’t write to the local C:\Program Files (x86)

Comments are closed.