Understanding the PVAD

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

The Primary Virtual Application Directory, more efficiently called the PVAD has been a topic of much discussion ever since the advent of App-V 5.0. I guess although we complained about the Q: mount drive we had in App-V 4.6 it did make things really easy to understand. The PVAD is an altogether more mysterious animal.

At the most simplistic level the PVAD is the location you tell your sequencer that you are intending to install your application. This then becomes your root directory, everything written outside that location gets put into VFS.

Let’s zoom out a bit and look at the PVAD in terms of the bigger picture and how our app sees the world.


PVAD in the Virtual File System?

Now here’s something not everyone knows about the PVAD, even though it physically resides in the cache as shown above, we actually create a mapping to the original location we specified at sequencing time. In other words the App-V 5 client honours the original PVAD location used at sequencing time and presents it to the virtual application.

Take ExcelViewer in this case:


Looking into the FilesystemMetadata.xml we can see this package was sequenced to C:\Program Files\Microsoft Office as the PVAD. Therefore most of the files are captured under the package root and anything that got written outside that root got put under VFS.


When we use the Open menu within Excel Viewer to look at the file system we do not see the PVAD reflected into its original location, that’s not because it’s not there, it’s because it’s hidden!

If we sneakily manually type in the path that we think is there but can’t see…



Magically it is there and accessible! So what does this show us? It shows that the PVAD is infact a hidden folder. This allows our applications  (if they wish) to make calls to exactly where they expect to find themselves, in the original PVAD location not the physical location in cache. Some applications will always refer to the location they are running from or the working directory, however in the instances where an application has a hard coded path or reliance on a environment variables which points them to the original installation location they will still get routed back to the cache location in %programdata% because of this hidden PVAD folder.

Some interesting developments have taken place with the PVAD in the latest SP3 release, check them out here.

So that explains the PVAD and the phases it goes through from sequencer to client. What about permissions to change things inside the PVAD? Hmmmmmmm read here…..

Leave a Reply.

4 thoughts on “Understanding the PVAD”

  1. What would cause the PVAD to NOT be applied to the client? I manually enter the address and I get location not found even though it is in the Root and in the filemetadata.xml file. Because of this my application tries to call this PVAD location and errors out.

    • Hi Kevin, there is no reason for this to happen. Inside the bubble is your PVAD visible? Also is it there in cache?

  2. I have created one app-V package, which is installing to “C:\program files\xelis\” and also installing one config.xml file which has hard code entries pointing to “C:\program files\xelis\….”. Upon converting this application, it is failed to work when I launch the shortcut. It seems that config.xml file is not able to locate the folders/files referred inside of it.

    Please let me know how to resolve hard code issues from config.xml file.

Comments are closed.