locked
App-v 4.6: new version of package? RRS feed

  • 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

    Monday, July 28, 2014 9:25 AM

Answers

  • Update the Package's content on the sequencer

    • create A COPY of all package files locally on the Sequencer machine
    • open it 'for upgrade' with the update or add aplication wizard
    • Do your stuff. Usually there is no need to create a new folder on Q: (or whatever drive) as you are upgrading
    • save the package on the Sequencer

    Update the package on the Management Server

    • Make a backup copy of the current package on your DFS
    • Copy *only* the new SFT file to the DFS share
    • In the Management Console, go to packages, find your package and 'add version'. Select the new SFT [IMPORTANT: from now on, the new version will be potentially be made available to all users!]
    • Copy the 'other' files (OSDs, ICOs, SPRJ and all that stuff) from your Sequencer to the DFS folder (this way also these files are consitent to the SFT file)


    Falko

    Twitter @kirk_tn   |   Blog kirxblog   |   Web kirx.org   |   Fireside appvbook.com

    • Marked as answer by janhoedt Friday, August 1, 2014 3:29 PM
    Tuesday, July 29, 2014 7:28 AM
    Moderator

All replies

  • Hello,
    See these process from Technet;

    http://technet.microsoft.com/en-us/library/ff436040.aspx

    http://technet.microsoft.com/en-us/library/dd835526.aspx

    http://technet.microsoft.com/en-us/library/cc817163.aspx


    Nicke Källén | The Knack| Twitter: @Znackattack

    Monday, July 28, 2014 9:50 AM
  • Thanks, but I already found that link. The problem is that I don't have the option to save the package to a location (so I cannot create a new folder either). I open the package for upgrade then it starts to monitor. Therefore I was looking for a screenshotted guide.

    "specify the location where the upgraded version of the package will be placed. This location specified must be located on the drive specified as the application virtualization drive, which is typically the Q:\ drive. To create a new folder, select Make New Folder"

    Version of sequencer = 4.6.0.20200.


    Jan Hoedt

    Monday, July 28, 2014 10:01 AM
  • I'm not sure what you mean...

    You copy the rootfolder of package on the DFS-share to your sequencer, you doubleclick the *.sftfile, you choose, open package for upgrade, you let the sequencer to it's thing, when in monitoring state, you perform the upgrade installation, you click finnish, you save the package to a new folder (or choose the same folder of the old package, and a _2 version will be created)... you copy the folder back to the DFS-share, you open the appv managemt console, you browse to packages, select the package, and choose Add version, and point to the *.sft you just created.

    Monday, July 28, 2014 1:39 PM
  • Update the Package's content on the sequencer

    • create A COPY of all package files locally on the Sequencer machine
    • open it 'for upgrade' with the update or add aplication wizard
    • Do your stuff. Usually there is no need to create a new folder on Q: (or whatever drive) as you are upgrading
    • save the package on the Sequencer

    Update the package on the Management Server

    • Make a backup copy of the current package on your DFS
    • Copy *only* the new SFT file to the DFS share
    • In the Management Console, go to packages, find your package and 'add version'. Select the new SFT [IMPORTANT: from now on, the new version will be potentially be made available to all users!]
    • Copy the 'other' files (OSDs, ICOs, SPRJ and all that stuff) from your Sequencer to the DFS folder (this way also these files are consitent to the SFT file)


    Falko

    Twitter @kirk_tn   |   Blog kirxblog   |   Web kirx.org   |   Fireside appvbook.com

    • Marked as answer by janhoedt Friday, August 1, 2014 3:29 PM
    Tuesday, July 29, 2014 7:28 AM
    Moderator
  • Thanks for the info but it doesn't work (at all) for me.

    What I did:

    1.followed your procedure, what seemed to work fine.
    However, I've read somewhere only the sft needs to be copied. Tried that but then the new package is not received, probably because the other files (like osd) refer to old sft

    2.placed also the other files on distribution point, then it seemed ok but the package now showed an error (due to a config file I replaced in the package a long time ago)

    3.Fully removed the package, opened it again in a sequencer, saved it to the distribution point and imported it again. Now some client see the new version, some don't although they have the correct sft (version 3). Other simply don't update the package and keep the old. But even with the correct sft the error in the package remains. Cleared/removed the package still no luck.

    What a nightmare to update a package. On 1 terminal server it works so there is a workaround but the other always throws an error. I could full clear the cache but that sounds kind of overkill.

    Please advise.


    Jan Hoedt

    Tuesday, October 21, 2014 3:59 PM
  • When you talk about a 'distribution point'... do you refer to System Center Config Manager? If so, the process is different :-)

    When using the Management server, 'my' method is the most consistent :-)

    Note that using an updated package does not repalce everything on a client/user. Every user has is own, personal copy of files/registry that were changed in the user's context. So, you deployed the original Package with setting 'P1'. Then, an overlaying modification of that setting is stored for the user, let's call that 'U1'. This basically always happen when something is changed, but it sometimes also happens without any active modification.

    Now you deploy your new package with 'P2', but on the client 'U1' is still existing and overlaying 'P2' - so the user still has 'U1' in effect.

    As a cross-check you can 'repair' the application/package for a user... this deletes 'U1' and 'P2' should get effective.

    Gridmetric's Application Virtualization Explorer and TMUrgent's PkgView tool are able to show the content of user modifications (would show only 'U1')


    Falko

    Twitter @kirk_tn   |   Blog kirxblog   |   Web kirx.org   |   Fireside appvbook.com

    Tuesday, October 21, 2014 7:59 PM
    Moderator
  • We use an app-v 4.6 management server as distribution point.

    A reboot solved my problem. However, I cannot reboot every time I need to deploy a new package.

     

    I’m not really sure I’m following your explanation. Therefore, our scenario:

     

    1. We have an existing App-v 4.6 package on a management server
    2. The package above is deployed to some terminal servers and is in use
    3. We create an upgrade of the package:
      1. Copy files locally to a sequencer and choose upgrade, save it locally
      2. Copy only the new SFT
      3. Add the new version in the management console => nothing happens on the clients
      4. Copy the other files OS, ICO etc. => why should we do that?! -if it needs to be done, why not in previous step (why only copying sft file there) -in this action you overwrite existing files and cannot return to a previous version. What’s the use of having versions then? How can we reverse to a previous version then?
    4. Tried all kinds of manipulations on the client then: repair, remove even clear cache but no solutions worked but a reboot of the server.

     

    I’m about to upgrade another package but not really eager to ….


    Jan Hoedt

    Wednesday, October 22, 2014 9:29 AM
  • 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

    Thursday, October 23, 2014 7:44 AM
    Moderator