Methods for Upgrading or Updating Virtualized Applications

In the current SoftGrid implementation, there are three distinct methods of providing users with an updated version of an existing SoftGrid application. This article will review the three methods and the associated benefits and considerations. When discussing the different methods for updates, it is assumed that users are already running an existing version of the application, delivered through SoftGrid.

SoftGrid applications are stored with a unique GUID identifier that is embedded into the SFT file at the time of sequencing. This allows the SoftGrid server to manage applications independently of their filenames or content. On the SoftGrid client, the machine and user settings for each application are managed by the SFT GUID, allowing settings to be managed at the same level. This information forms the basis for the methods below.

Active Upgrade:

The first application update method is called Active Upgrade. In this configuration, the existing package is copied down to a sequencer workstation. The package is then Opened for Package Upgrade, a function found in the sequencer. The sequencer will extract out the contents of the SFT file and restore the application to the end state from the last sequence. The sequencer user then simply restarts the Monitoring process in the sequencer, and once monitoring restarts, the user performs any updates to the application as necessary.

Simple file and registry changes can be made, along with more complex updates such as a package installer like a service pack. Once the application updates have been completed, the sequencer user stops monitoring and the sequencer will process all the updates. The Shortcut Wizard is then re-run, reconfirming that the application still works in SoftGrid. The package is then saved in the sequencer. The sequencer will recognize that this package is an update and append an underscore and an increment number to the SFT files (e.g., EXAMPLEAPP.SFT becomes EXAMPLEAPP_2.SFT).  Once the sequencing is completed, all of the new package files are copied up to the content share. Next, the SoftGrid administrator adds a new Package version into the SoftGrid Management Console, referencing the new SFT file. Once that is complete, the new application is ready and available for all users who have permissions to the application. All new application launches will receive the updated application, and all existing users will still use the old version until they restart the application on their clients and receive the update. 

The primary advantage of this method is that the upgrade is seamless to the end-users. The icon that represents the application on their client machines really represents a living application, always with the latest version. The user simply launches the application and they are presented with the most up-to-date version of the application. Since the application’s SFT is updated, the GUID stays the same, which means all machine and user settings are still associated with the applications are retained for users. Also, no desktop refresh is required for this update, as it’s done on the SFT file that is being launched by the users.  The primary consideration for this method is that both the existing version and new version cannot be served to users simultaneously. The user will always get the latest version upon application launch. Also, once the update is made available on SoftGrid, it is available to all users provisioned to the application. There is no current method to provision the new version to specific users or AD groups.

New Application/Parallel Execution:

The second application update method can be called New Application/Parallel Execution. In this configuration, the application is re-sequenced, starting with the base installer, then the updates are performed as necessary. This creates an entirely new package that represents the updated version of the application. The new package file is then copied to the content share and the SoftGrid administrator adds a new application record for this package. 

The primary advantage of this method is that the upgrade can be run simultaneously with the existing version. This would allow the users to run both versions and potentially test both versions side-by-side, allowing for much better testing of the updated application. Also, since they are independent applications, application provisioning is separate, allowing for test or staged rollouts. This allows time for users to run both versions of the application until the older version is retired.

The primary consideration for this method is that existing machine and user settings will not be available in the new version since the two SFT files have different GUIDs. It may be possible to programmatically transfer the settings between the two applications but the management of those settings is not automatically transferred. SoftGrid will see the two versions as completely separate applications. Another consideration is the time to create a second sequence. The entire installation process would have to be performed before the updates are applied. This increases the likelihood of possible errors. However, if this update is not a simple update or service pack, but rather a whole new version, it is recommended that this method be used. New versions of applications, in general, should be treated as new applications in SoftGrid. Clean application installations often are less troublesome than upgrades and any upgrade logic in the installer cannot be applied to the users as the installation takes
place during sequencing, not on the client machines.

Application Branch/Parallel Execution:

The final application update method can be called Application Branch/Parallel Execution. This configuration is very similar to the New Application method, with one very important distinction. In this configuration, the application is not completely re-sequenced. The existing SFT file is copied down to a sequencer workstation. The SFT file is then Opened for Package Upgrade, a function found in the sequencer. The updates would be performed as in the Active Upgrade, however now the sequencer user performs a Save As of the package, NOT a save. Once this Save As process is started, the sequencer will prompt for a new Package Root, Suite Name, SFT file name, and it will also create a new GUID for the SFT. The result of the Save As is essentially a completely new SFT file, the contents of which are identical to the end state of the existing SFT file, except for the new root install directory (to keep the applications from using the same install path). Thus this new SFT represents the updated application in a new SFT file, which is then added as a new application in the SoftGrid Management Console.

The primary advantage of this method is that the upgrade can be run simultaneously with the existing version. This would allow the users to run both versions and potentially test both versions side-by-side, allowing for much better testing of the updated application. Also, since they are independent applications, application provisioning is separate, allowing for test or staged rollouts. This allows time for users to run both versions of the application until the older version is retired. Also, as an advantage over the New Application method, the entire application does not need to be reinstalled or re-sequenced. The new SFT file represents a branch off the application management line for this application. Both SFT files, both the existing and the new, can be updated using any of the methods described here. This method is very useful for test updates, since the time to create the separate sequencing is not much greater than performing the Active Upgrade. A series of new versions could be made for various purposes. This method is also useful when a second or multiple versions are required from a base app, such as different configurations of the same application.

The primary consideration for this method is the same as the New Application method, such that existing machine and user settings will not be available in the new versions since the two SFT files have different GUIDs. It may be possible to programmatically transfer the settings between the two applications but the management of those settings is not automatically transferred. SoftGrid will see the two versions as completely separate applications. It should be noted that same as with Active Upgrade, this method is not recommended for new or significant versions upgrades.

J.C. Hornbeck

Comments

• Anonymous
  January 01, 2003
  A couple of you seemed to like my recipe for sequencing Office 2007 and asked if I would do one on upgrading

• Anonymous
  January 01, 2003
  The SoftGrid Team blog published an entry today that describes the three methods for upgrading Softgrid applications. The three types are:1) Active Upgrade - You open the existing package up in ...

• Anonymous
  January 01, 2003
  The first thing you’ll probably want to do in preparation for your callback is gather up any relevant

• Anonymous
  January 01, 2003
  Here's an interesting issue our very own John Behneman ran into the other day.  If you're currently

• Anonymous
  June 20, 2011
  The comment has been removed

• Anonymous
  November 14, 2013
  I am using the Active Upgrade method in a 2008R2 RDS environment. It seems that in previous versions of Softgrid, we were able to perform Active Upgrades while users were still in the app. Once they logged out of a server and logged back in the users would see the changes. Now we are on AppV 4.6 SP2 on the servers and 4.6 SP1 HF7 for the clients and this Active Upgrade does not work anymore until all the users of the application log out of the servers. Only then would they see the changes. Anyone ever hear of this issue?

• Anonymous
  February 26, 2015
  GilbertD it depends on how your AppV client policies are setup.
  If it is set to refresh only on login then it will need a logout and login to be able to retrieve new applications.