Jun 24, 2013 - 12 Comments - Virtual Vibes -

Global File State Changes in App-V 5.0

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.

12 Responses to Global File State Changes in App-V 5.0

  1. Mark C

    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?

    26 Apr 2014 - Reply
    • Thamim Karim

      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.

      26 Apr 2014 - Reply
  2. App-V 5.0 Ramp up Guide | VirtualVibes

    […] Global File State Changes in App-V 5.0 | Blog […]

    1 May 2014 - Reply
  3. A Blast from the Past – Security Descriptors and Save as New Package are back with App-V 5.0 SP2 Hotfix 4 | VirtualVibes

    […] Ticking this box does exactly what it says on the tin, it enables us to write to all of the virtual file system whether we are a admin or not! Of course this writes will be considered state changes as talked about in this post: Global File State Changes in App-V 5.0 […]

    1 May 2014 - Reply
  4. Global Registry State Changes in App-V 5.0 | VirtualVibes

    […] on 4.x. I have discussed at length both App-V 5.0 – OS Integration – State Changes and Global File State Changes in App-V 5.0, but what about when we make changes to global locations of registry for our […]

    17 Nov 2014 - Reply
  5. Raj

    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??

    29 Mar 2016 - Reply
    • Thamim Karim

      Hi Raj,

      No real significance of this, just a by design behaviour.

      30 Mar 2016 - Reply
  6. Raj

    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?

    30 Mar 2016 - Reply

Leave a Reply

Your email address will not be published. Required fields are marked *