The workflow for package upgrades is pretty similar in App-V 5.0 as it was in 4.5, however there are now a few added benefits around phased targeted rollout of App-V upgrades….
I have a version one of Paint.NET deployed here:
This version of the package is without a additional plugin called “ColorCount” that would normally be seen under Effects->Photos
To deploy the package update we have already sequenced all we have to do is choose “ADD OR UPGRADE PACKAGES” from our management console and specify our upgrade location:
Once we click add we get the following:
Notice the tick box that says “Copy access and configurations from a previous version”. The console understands that this is an upgrade to an application and offers to copy over the access permission and configuration items from the version that is already present. I can see this being useful to people who have a long list of entitlements on a previous packages and want these to now apply to the latest upgrade.
In this case I am going to leave the box unticked.
Now the package is imported and we can see the console has automatically stored it a version 0.0.0.2, no manual work was required to connect this package to the previous version.
Another interesting note is the defaults mean this package has no AD access specified against it and neither is it publish. This a move away from the auto-upgrade we had 4.5 whereby as soon as you published a upgrade it was automatically published and made available to all users with access.
The good thing about this approach is I can now phase my rollout of this upgrade, for example I could choose to publish this to a test pool of users first:
Now only users in this particular group would get the upgraded version of Paint.NET and all other users would continue to use the previous version.
After logging on as a user in the AppVirtTestUSers group and completing a refresh I now get the updated package with the ColorCount when I run Paint.NET:
