App-v 4.6: new version of package?

Question

Hi,
I have this App-v 4.6 package I need to change/upgrade. I can see in the app-v management server there are already some versions (1.1, 1.2 and now I need to make 1.3). Not sure howto though.
The package is on a dfs-share \\ourcompany\share\.
What I did before = upgrade package and save it to the location on dfs but then I'm lost, how can I add a new version?
I'm looking for a screenshotted step by step guide.
Pls advise.
J.
Jan Hoedt

Answer 1

Hi,
The new .sft file gets only updated on the client when the package is not in use at all. In a TS/RDS environment this means that *no* user may use any application of that to-update package. 
As soon as 3.3 has finished any the package is not in use on a client for a moment, the next user who launches the application will initiate downloading/streaming the new .sft to that RDS/TS server.
@3.4 I admit that overwriting the 'other' files is a downside, but MS hasn't implemented any versioning feature for these files. As a good practice you should have a static package repository somewhere that stores each version ov every package - just as
an archive.
Why should you update the OSDs and alike? 
In fact technically this might not be necessary.
When an App-V package should get added to a client (like a newly built RDS server), the App-V client will connect to the ManSrv, retreive the AppList for a user and download and parse the OSDs. In there it reads 'Use sft_v3'. Then the client requests 'sft_v3'
from the ManServer, but that says: Hold on, my friend, I do have a newer version, sft_v5, for you'. Then the client downloads v5.  This justs takes some time, but won't hurt.
Things get worse when you (or somebody else) figures out that you have already 5 of those 'megapack_X.sft' files in your content share. So you say 'C'mon, we don't need 1..4 any more, my users are working with v5 for a while now) - and you do that maybe
for several packages.
After a while you decide to built a new App-V infra (new sub, lab,. whatever) and want to copy/import your exisiting packages to that new infrastructure. So guess what's happening: You select to import a new package into the console, it's asking you for
the .sprj that you specify. Then the console parses the OSDs, but they haven't been updated (you wanted to skip 3.4.) - they still point to v1 of the SFT, that isn't there anymore. To bad, right?
Same would happen if you bring back such a package to the sequencer - the
So, 3.4 is basically for consitency. There are methods to fix inconsitency, but you should avoid them.
Falko
Twitter
@kirk_tn   |   Blog
kirxblog   |   Web
kirx.org   |   Fireside
appvbook.com