Updating Managed ThinApp Packages After Deployment in Omnissa Access

After adding a ThinApp package to your organization's catalog and entitling your Omnissa Access users to that ThinApp package, your organization might want to update that package and have the users use a newer, or rebuilt, version of the ThinApp package, without having to remove the user assignments from the current package and assign users to the newer package.

An updated ThinApp package might be made available because a newer version of the Windows application for that package is released, or because the packager of the application has changed the values of parameters used by the package.

ThinApp provides an update mechanism for ThinApp packages used in Omnissa Access. This ThinApp update mechanism is different from other update mechanisms for ThinApp packages used outside of an Omnissa Access environment. The updated ThinApp package must have been updated with this mechanism for you to be able to deploy the updated package in Omnissa Access and have users automatically see the newer version.

For ThinApp packages that are managed in Omnissa Access, two Package.ini parameters are used by Omnissa Access to determine that a package is an updated version of another package.

• AppID

  The unique identifier for the ThinApp package in Omnissa Access. All entry points (executables) for the package's application are assigned the same AppID. After a ThinApp package is synced to your organization's Omnissa Access catalog, the package's AppID is displayed in the GUID column in the ThinApp package's resource page. This value consists of alphanumeric characters in a pattern of character sets, each set separated by dashes, such as in the following example:

  XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX 
  
  

  Omnissa Access considers any ThinApp package with the same AppID to be versions of the same application.

• VersionID

  The version number of the ThinApp package. Omnissa Access uses the VersionID to keep track of different versions of the managed ThinApp package. You increment the VersionID value by one (1) to mark that ThinApp package as an update of another package, retaining the same AppID.

You place the updated package in a new folder in the network share folder configured for the managed ThinApp packages. When Omnissa Access performs the scheduled sync with the network share folder and it encounters an application that has the same AppID as another application, it compares the VersionID values. The ThinApp package with the highest VersionID is used as the most recent update. Omnissa Access automatically incorporates the previous user entitlements to the ThinApp package with the highest VersionID, and shortcuts on the users' systems are synced to point to the updated package.

Important: The standard ThinApp InventoryName parameter is important to successful updates of managed ThinApp packages. Both the previous and updated ThinApp packages must have the same value for the InventoryName parameter. If the person creating the ThinApp package changes the InventoryName in a package, and then creates an updated package, you must make sure the InventoryName values match for the updates to work properly in Omnissa Access.

See the ThinApp Package.ini Parameters Reference Guide for details about the various parameters that are used in a ThinApp package's Package.ini file.