At the moment I am chilling in sunny Bangladesh but thought I would set this post to publish today before I left for annual leave last week, nobody can ever say I leave you VirtualVibes readers hanging huh!
Today I thought I would share some info around upgrades. During my time with customers ever frequently I am asked about how updates work with App-V 5.0 and do we do differential streaming like we had in App-V 4.6?
Basically yes we do and because we essentially just use hard links for our package integration to the package store the whole story is much clearer in terms of mechanics.
This v1 package sits 100% loaded into our package store cache on our client machine…
Now imagine we publish out an update for Java Runtime Environment 6, the update in this case is additional 5MB on top of the of the original 80MB package.
What happens on the client next refresh?
We notice when our upgrade is delivered, rather requiring a full re-stream into cache, the percent cached indicator merely jumps down a notch to indicate some differentials will need to be streamed down.
The logic is further exposed via PowerShell when we run a Get-AppvClientPackage -All:
You will notice from the above that v2 of my package has been published to my user and is 96% in cache, at the same time v1 of my package was automatically unpublished however sits idle at 100% in cache.
Now you might be wondering what happens if we pull the version 1 package from under the feet of our v2 package, does it then need a full re-stream?
The answer is no, the App-V client is clever enough to retain any assets required by the v2 package and amend the relevant hard links. As you can see below even after removing the v1 package, our v2 package still remains 96% in cache.
So taking this a step further, what about cases where the V1 package is only partially in cache itself and we deliver an updated v2 version, can we still leverage differentials?
This is going one better than App-V 4.6 whereby we required our .sft to be fully in cache before we could leverage differentials. Now because of our flat file system in the package store, we can leverage the v1 package assets regardless of how much is streamed down to avoid having to re-stream when we load the v2 package.
Above you can clearly see that even though our v1 package is only partially loaded at 26%, upon delivery on the v2 package we automatically leverage what we already have and only require the differentials to come down.