locked
App-V 5.0 package upgrades and using full write permissions to the VFS RRS feed

  • Question

  • I have found a shortcoming with using these two functions in conjunction with each other and I am curious to see if anyone else has and what they have done to get around it.

    We have one application packaged with the App-V 5.0 SP2 Sequencer that requires monthly updates.  I have always used the upgrade function instead of building new packages for this app when we had 4.6, and am repeating that practice with 5.0.  The updates themselves are no more than changes to 20 files, 2 of which are .JAR files and the rest .XML.  We have been through 8 or so different upgrades.  After a few months using 5.0, I started getting reports from some people who are running their OS on persistent disks stating that they weren't getting the upgraded versions of the packages.   While we are using the Shared Content Store Mode for our non-persistent disk users, we aren't for those with a persistent disk.  I would trace from their shortcuts through their profile folders to the ProgramData directory to confirm they had the latest version of the software and that the shortcuts resolved to it.  I even would remove all published apps and sync with the server so that only the most recent versions of the apps were in cache.  They still were seeing things within the application as if they hadn't received the updates. 

    After further testing, I determined the following:

    1. If you have checked the value "Allow virtual applications full write permissions to the virtual file system" in your sequenced package, any changes that a user does make to the install goes to %LOCALAPPDATA%\Microsoft\AppV\Client\VFS\<package GUID>, and folder structure that is similar to what is in the install, but with less depth.  Notice that while the structure contains the <package GUID>, it doesn't include anything from a version perspective.

    2. The files and directory structure of an App-V app is really a combination of c:\ProgramData\App-V\<package GUID>\version GUID>\Root  with the contents of %LOCALAPPDATA%\Microsoft\AppV\Client\VFS\<package GUID> overlaid over it.  The directory structures aren't exactly the same, but the client takes that into account so that functionally, the updated files that are specific to the user supersede any corresponding files in the ProgramData directory.

    Now the problem:

    If you have an application that has files that were updated by the user, intentionally or just through normal function, and you deploy an upgraded version of that package that includes changes to those same files, the files that the App-V Client will use won't be the new files in the upgraded package.  They will be the files that were updated in %LOCALAPPDATA%. 

    As a general rule, I tend to select the "Allow virtual applications full write permissions to the virtual file system" option when I package because it saves me time in not having to test if being more restrictive will work.  For this specific application, I believe I can get away with deselecting this option and eliminating files being updated in %LOCALAPPDATA%.  But I wouldn't be surprised if I run into an application in which:

    - I have to turn on "Allow virtual applications full write permissions to the virtual file system" in order for the app to function.

    - Have periodic updates that I would handle via upgrading the package

    - Files that are part of the upgrade are the same files that are getting updated by individual users.

    The only other option I would think I could do would be to have to build a new package instead of being able to upgrade.  Has anyone else run into this problem and how has it been handled?




    • Edited by TravlinT Thursday, August 27, 2015 10:54 PM typo
    Thursday, August 27, 2015 10:51 PM

Answers

  • This behaviour is by design. The App-V client is just storing user state changes, these state changes are always stored in non-versioned paths so changes may be applied across updates. If you imagine the other side of the coin where a user configures their application to their ideal way and then you deliver a minor update to that package, if the functionality mentioned before wasn't in place that user would have their application reset back to a clean state, this could be very annoying.

    If you wanted this to happen however you can either 'save as new package' so state isn't carried across or repair the existing package before the update.

    • Marked as answer by TravlinT Friday, August 28, 2015 2:42 PM
    Friday, August 28, 2015 8:47 AM

All replies

  • I would recommend to create a new package instead of using upgrade in order to avoid these scenario's.

    Why not try once with App-V 5.1?


    (Please click on "Vote as Helpful" and/or "Mark as Answer", if it has helped you. )

    Friday, August 28, 2015 5:56 AM
  • This behaviour is by design. The App-V client is just storing user state changes, these state changes are always stored in non-versioned paths so changes may be applied across updates. If you imagine the other side of the coin where a user configures their application to their ideal way and then you deliver a minor update to that package, if the functionality mentioned before wasn't in place that user would have their application reset back to a clean state, this could be very annoying.

    If you wanted this to happen however you can either 'save as new package' so state isn't carried across or repair the existing package before the update.

    • Marked as answer by TravlinT Friday, August 28, 2015 2:42 PM
    Friday, August 28, 2015 8:47 AM
  • If App-V 5.1 can't separate user state changes between different versions of the same package, I would expect the exact same behavior.  I don't see any mentions of that as a new feature in 5.1
    Friday, August 28, 2015 2:14 PM
  • Understood.  I can see where there are times when you want those changes to carry over through updates.  We just happen to be in a situation where we don't.  Since that is the case, I suspect the best way is to not allow changes to the VFS for the application because it doesn't need it, and I want to be able to use upgrade functionality.  Thank you for the information.
    Friday, August 28, 2015 2:42 PM
  • Unticking VFS alone won't achieve this unless your changes that you want to avoid carrying across are only in global locations. User state also gets stored in %AppData% for locations written to that are considered user based. So be careful that changes aren't also in there too that you do not want. This behaviour is the same across all versions of 5.x including 5.1.

    See the following links for more info:

    http://virtualvibes.co.uk/app-v-5-0-os-integration-part-4-state-changes/

    http://virtualvibes.co.uk/global-file-state-changes-in-app-v-5-0/

    http://virtualvibes.co.uk/global-registry-state-changes-in-app-v-5-0/

    Friday, August 28, 2015 4:32 PM