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.