Global File State Changes in App-V 5.0

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

In a previous post we talked about state changes with App-V packages and how these changes were stored, that post revolved around user profile based changes that we would typically like to roam.

How about changes that are made to non-user profile locations such as the package root itself? These are stored in %LOCALAPPDATA%\Microsoft\AppV\Client\VFS

In here you will find GUID based folders that represent the packages that reside on the client, anyone who has read my OS Integration series of posts will be familiar with this concept!

Once we identify the folder that represents the package we are interested in, we can traverse the folders to see what (if anything) has be laid down post sequence outside of the user profile. For example in this case with NetBeans a .conf file has been created within the root of the package (the PVAD).

Although the change was affected in the root of the package, it is important to understand that this is still treated as a user change, therefore it gets stored in this %LOCALAPPDATA% location and is only ever seen by the specific user. If another user logs on a launches NetBeans they will not see this same .conf file.

Similar to user profile based state changes, these settings can be cleared down using the repair functionality we have with App-V.

What about deletes?

Now we understand how changes are handled, let’s take a look at what happens when files or folders within the virtual environment are deleted.

Let’s take this application, it has a collection of PDF manuals with can be opened from the Help menu.

From within the package I am going to leverage the open menu to actually browse into the PVAD of this package and find these PDF manuals, this is just a quick alternative to breaking into the bubble for this instance.

And it’s gone! Let’s stop and think about exactly what took place here, I have gone a deleted a file directly from the root of my package. We know the package is physically held and protected in cache under %ProgramData%, surely we haven’t directly modified the cache???

Of course not! Here you can see that the R-intro.pdf file we deleted remains in cache, correct and present. We know it is deleted from the perspective of the user running this package however, as you can see if we try and open the PDF from the help menu we get the following error:

So how have we recorded this “fake” delete? Let’s navigate to %LOCALAPPDATA%\Microsoft\AppV\Client\VFS here we will see the familiar GUID based folder naming, let’s drill into our particular package.

Here we find a 0KB placeholder for the delete. Interestingly we also find it in our recycle bin too!

So how do we “un-delete” and restore the file back into our package? Simple, we just delete the placeholder in %LOCALAPPDATA% or we can do a repair from the GUI to clear out all customisations if we wanted.

Now when we run our application it finds the PDF again…

So that summaries changes inside the VE affecting non profile locations, App-V 5.0 recognises that these changes should be stored however also appreciates such post deployment changes may not be something which you would wish to roam with your package and therefore stores them in a non-roaming location in the profile.

In an ideal world our packages shouldn’t change fundamentally after deployment and therefore we wouldn’t look to normally roam anything that gets stored in the locations above however it important to know where such changes go and how they are handled. To read how we handle global state changes in registry click here.

Leave a Reply.

12 thoughts on “Global File State Changes in App-V 5.0”

  1. Hi Thamim. Is there a case for roaming this folder to retain these state changes in a Win 7 hot-desking environment or RDS platform?

    • Hi Mark, in most instances I would lean towards no. Users shouldn’t typically be changing global assets and if they are it should maybe be addressed in the sequencing of the package. Windows best practices would be to roam only the user specific roaming location in AppData. If there is important user personalisation going elsewhere this needs to get addressed on the package level.

  2. Even after App-V package is removed, what is the significance of leaving the PACKAGEID folder under “%progamdata%\appv\”. Does it mean removal of the package is not clean or else is it having any importance??

  3. Thanks Thamim. But it is letting us assume that the package is still exist in the machine. Upon realize we are writing a script to cleanup the folder. Are there any other work around to remove this folder without any extra work?

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.