locked
APP-v45 Package Update and publishing updtaed package RRS feed

  • Question

  • When you update an existing package, how do you publish it so that the current package is not disrupted and client dont have to logg off the package so that the updated package could be overwritten?
    Tuesday, February 24, 2009 5:58 PM

Answers

  • To expand on that answer...

    The best practice is to first back up the folder of the existing package on the content share.  You also make a copy from which to sequence the upgrade (Never open for upgrade on the content share).  When you save, you will have updated all the files in that folder except for the original sft and will have a new _2.sft.  Copy all of these, EXCEPT for the original sft, into the content share folder, saying yes to overwrite.  Then in the management console locate the existing package in the packages part of the tree, right click and add new version.  Browse to the _2.sft file using a \\url , copy that string without the \\server\content portion, hit next and paste into the "relative path" entry.

    So why copy more than just the new _sft?  First, you may have changes that require updated OSD files.  Second, you might touch this package again so having the new sprj to work with makes sense. 

    Also, some people insist on renaming the OSD files when sequencing the upgrade, but I do not find that necessary.  If you do rename the OSDs, then after adding the new version you will need to go into the applications tab and import applications, but don't select the sprj file, change the input type to OSD and add the new OSDs.  You can remove the old OSDs from the management console then also.

    After you are sure nobody is using the old sft it may be removed from the content share.  I would leave the version in the management console because of reporting.
    Sunday, March 1, 2009 10:15 PM
    Moderator
  • Hi,

    i assume that youa re working with App-V Native (Management Server - Clients)?

     If you upgrade a package and then add the new version to the package in the packages node it will automatically stream to the clients when users launch the applciation again. They don''t need to log off and log back on again. Users who are working with the application during the upgrade will continue to work with the old version until they launch the application again. This is called active upgrade and it has nothing to do with the refresh mechanism.

    One disadvantage of the mechanism is that you cannot test the new version of the pacakge in the same environment. you cannot add it as a new package. so if the new version is not working well, users may get errors and call the support department. This can be solved easily by removeing the new version from the packages node. After removeing the pacakge from the node, the old version is automatically streamed back tot the clients.

    If you want to test upgraded packages you need some test/DTAP environment.

    Regards,

    Jan van der Elst
    Wednesday, February 25, 2009 6:32 AM

All replies

  • Hi,

    i assume that youa re working with App-V Native (Management Server - Clients)?

     If you upgrade a package and then add the new version to the package in the packages node it will automatically stream to the clients when users launch the applciation again. They don''t need to log off and log back on again. Users who are working with the application during the upgrade will continue to work with the old version until they launch the application again. This is called active upgrade and it has nothing to do with the refresh mechanism.

    One disadvantage of the mechanism is that you cannot test the new version of the pacakge in the same environment. you cannot add it as a new package. so if the new version is not working well, users may get errors and call the support department. This can be solved easily by removeing the new version from the packages node. After removeing the pacakge from the node, the old version is automatically streamed back tot the clients.

    If you want to test upgraded packages you need some test/DTAP environment.

    Regards,

    Jan van der Elst
    Wednesday, February 25, 2009 6:32 AM
  • To expand on that answer...

    The best practice is to first back up the folder of the existing package on the content share.  You also make a copy from which to sequence the upgrade (Never open for upgrade on the content share).  When you save, you will have updated all the files in that folder except for the original sft and will have a new _2.sft.  Copy all of these, EXCEPT for the original sft, into the content share folder, saying yes to overwrite.  Then in the management console locate the existing package in the packages part of the tree, right click and add new version.  Browse to the _2.sft file using a \\url , copy that string without the \\server\content portion, hit next and paste into the "relative path" entry.

    So why copy more than just the new _sft?  First, you may have changes that require updated OSD files.  Second, you might touch this package again so having the new sprj to work with makes sense. 

    Also, some people insist on renaming the OSD files when sequencing the upgrade, but I do not find that necessary.  If you do rename the OSDs, then after adding the new version you will need to go into the applications tab and import applications, but don't select the sprj file, change the input type to OSD and add the new OSDs.  You can remove the old OSDs from the management console then also.

    After you are sure nobody is using the old sft it may be removed from the content share.  I would leave the version in the management console because of reporting.
    Sunday, March 1, 2009 10:15 PM
    Moderator
  • Hi,

    Thanks for your response, it was very informative I will try it out. One thing to verify So when I copy the updated package to the sharepoint to overwrite the existing package I dont have to wait for users to logg off in order to overwrite, because that is my concern as it was the case in Softgrid v4.2 when I had to ask users to logg off in order to overwrite the package.
    Monday, March 2, 2009 3:34 PM