Knowledge Base
Updating VMware ThinApp virtual applications in Horizon Application Manager (2030248)
Purpose
Resolution
ThinApp 4.7.2 provides a new update mechanism for ThinApp packages in the Horizon environment. This ThinApp update mechanism is different from other update mechanisms for ThinApp packages outside of the Horizon environment. (For a discussion of these other ThinApp update mechanisms, such as AppSync and side-by-side updating, see the ThinApp Users Guide.)
The key change to ThinApp to enable updated packages in Horizon is a new Package.ini parameter, VersionID, which is the version of the package. VersionID works in conjunction with the package identifier, AppID. An updated package must retain the same AppID as the previous version, and VersionID must be incremented.
Which Package.ini parameters are involved in the update of ThinApp packages in the Horizon environment?
|
VersionID | |
|
Purpose |
VersionID is the version number for a ThinApp package within Horizon. VersionID is a new parameter in ThinApp 4.7.2, implemented to support updates of ThinApp packages in Horizon Application Manager. |
|
Syntax |
VersionID=<integer> |
|
Default value |
1 (packages enabled for Horizon in Setup Capture have an implicit value of 1 when read by Horizon). Also, if left blank in Package.ini, VersionID is understood as 1. |
|
Possible values |
Positive integers from 1 to 99 |
|
Notes |
Horizon considers any ThinApp packages with the same AppID to be versions of the same application. You increment the VersionID by 1 to mark a ThinApp package as an update. The ThinApp package with the highest VersionID is the most recent update. When you mark a new ThinApp package as an update in Setup Capture, and you point to the old version of the same application, ThinApp increments the prior VersionID by 1 so that the new package becomes the update. |
|
InventoryName | |
|
Purpose |
String the identifies the package, for application inventory tracking utilities and other purposes. |
|
Syntax |
InventoryName=Microsoft Office 2003 |
|
Default value |
By default, the application capture process sets a value for the InventoryName parameter based on strings created under one of the following locations:
Most applications have the inventory name in a registry key, and ThinApp picks this up. If no such name exists, ThinApp generates a random string. |
|
Possible values |
Unspecified |
|
Notes |
Becomes the name for the application sandbox and the project folder, and is used in the string for Add / Remove Programs. |
What are the different ways you can create an updated ThinApp package for Horizon?
If you want to create an updated ThinApp package for use in Horizon, you must accomplish the following two goals:
-
Create a new package with the same AppID as the prior version
-
Make sure the package is still enabled for Horizon
You can create the updated ThinApp package in three ways:
- Capture with Setup Capture from ThinApp 4.7 or later
- Update Package.ini manually and then rebuild the package with ThinApp 4.7 or later
- Relink -h command from ThinApp 4.7.2 or later
The Setup Capture and Package.ini methods both rely on incrementing VersionID. The relink method can either use VersionID or circumvent the use of VersionID.
Setup Capture is the easiest way to update a virtual application for Horizon. The Setup Capture wizard provides you with a graphical interface to select options and enter values in text fields, which automates the setting of Package.ini parameters.
To update with Setup Capture, you need only the:
- Application executables from the prior virtual application
- Application installer
- Setup Capture and the ThinApp Program Files from ThinApp 4.7.2 or later
To create an updated package in Setup Capture, proceed as for any package through the prescan, application installation, and the postscan. During package configurations, when the Manage with Horizon window appears:
- Select Manage with VMware Horizon Application Manager.
- Select This package is an update of an existing base ThinApp package.
- Enter the path or click Browse to point to the prior (base) ThinApp executables folder, not to specific executables. When updating a Horizon-enabled package with Setup Capture, you can point directly to the application executables folder in the ThinApp Repository, if that file share is connected to the ThinApp capture machine. Alternatively, you can point to a copy of the executables folder.
- Continue with Setup Capture and build the application.
After you designate the package as an update and point to the prior version in Setup Capture, ThinApp:
- Reads the AppID of the prior package and assigns the same AppID to all of the executables and the Primary Data Container of the updated package
- Reads the VersionID (if present) of the prior package and Increments VersionID to the next integer for the updated package. If no VersionID exists for the prior version, the VersionID for the updated version is 2 because the default VersionID for a first version is understood to be 1.
- Reads the InventoryName from the prior package and assigns the same InventoryName to the updated package. When you get to the Project Settings window in Setup Capture, the Inventory name field is already populated with the prior package's InventoryName and is not changeable. Whether you chose the default InventoryName for the prior package or changed it, Setup Capture replicates the InventoryName when you mark a package as an update of a previous Horizon-enabled package. The Horizon Service uses the InventoryName to identify packages.
How do you find the AppID of a package previously enabled for Horizon?
If you use a method other than Setup Capture for creating an updated package for Horizon, you sometimes need to know the AppID of the prior ThinApp package that you are updating.
If you used Setup Capture to enable the package for Horizon, the default value of AppID is genid, which causes ThinApp to generate a random AppID for the package during the build. (If you had wanted to specify the value for AppID, you could have stepped out of Setup Capture and edited Package.ini to enter a GUID value for AppID.) If the value of AppID is genid, Package.ini does not record the randomly generated value. Instead, Package.ini shows genid as the value for AppID. The value for AppID is embedded in the application executable during the build.
You must use the ThinApp SDK to expose the value of AppID that is within the executable. For information on using the ThinApp SDK, see the VMware ThinApp SDK.
C:\Program Files\VMware\VMware ThinApp\relink.exe application.exe -h
Where application.exe is the ThinApp entry point of the package.
You might want to update a package by editing Package.ini if:
- You do not have the application installer for recapture
- You need to update the package to the new version of ThinApp, and you need to update more than the ThinApp runtime (which relink would handle). Rebuilding incorporates changes to the file system and registry which are in a new version of ThinApp. For example, the new version of ThinApp might have a new Package.ini parameter that you want to set; a rebuild is necessary to incorporate this kind of change from the new ThinApp version.
How do you update a ThinApp package for Horizon by editing Package.ini?
To mark the new package as an update, edit the following Horizon parameters in the [BuildOptions] section of Package.ini:
- Set AppID to match the AppID of the prior version of the application. You cannot reuse a value of genid for AppID, or a new AppID will be generated for the updated package. See How do you find the AppID of a package previously enabled for Horizon?
- Increment VersionID to one higher integer than the prior package. If the prior package has no VersionID, its value is 1 by default, so give your updated package a value of 2 for VersionID.
- Make sure the InventoryName matches the InventoryName of the prior version of the application. The InventoryName values for the prior and new packages must be identical.
When would you choose relink -h to update a ThinApp package for Horizon?
Relink -h is a good candidate for updating an application if:
- You already captured, built, and tested the package and are ready to enable the updated package for Horizon and then place it in the ThinApp Repository in the Horizon environment
- You want to update only the ThinApp runtime for the package to incorporate bug fixes in the new ThinApp version
- You only need to enable the package for Horizon
- You do not have the project folder for an application
Relink is very fast; you do not need to recapture or rebuild the package. And you do not need the application project directory to run relink.
How do you use the relink command to update a ThinApp package that is in Horizon?
In brief, relink -h enables a package for Horizon and updates the ThinApp runtime at the same time. You need to either run relink on the old package to pick up the AppID, or else specify the same AppID as for the old package you are updating. You can increment VersionID to create a versioned update that you place in a new folder on the ThinApp Repository, or you can skip setting VersionID and replace the old package In the ThinApp Repository. Both methods use the same AppID, so entitlements and shortcuts are preserved from the old application in Horizon.
Where do you put the updated package in Horizon?
Depending upon whether or not you increment VersionID to indicate an updated ThinApp package, you place the new version of the virtual application in a different place on the ThinApp Repository.
- VersionID-updated package: If you increment VersionID to indicate that the package is an update, place the updated version of the ThinApp package in a new folder on the ThinApp Repository. You can choose the name for the new folder.
Version ID is incremented when you
- Use Setup Capture to update the package
- Manually edit Package.ini (including VersionID) to update the package
- Use relink -h with the VersionID flag to update the package
With all three of these methods, you retain the same AppID and increment the VersionID for the updated package. The best practice for updating a ThinApp package in Horizon is to increment the VersionID of the package.
-
Replacement package: If you do not increment VersionID for the ThinApp package, you must replace the application executables in the old folder on the ThinApp Repository.
This is the case if you use relink -h to update the ThinApp package, and if you keep the same AppID, but do not increment VersionID.
If you increment VersionID and place the new executables in a new folder on the ThinApp Repository, you do not need to remove the prior executables and their folder from the Horizon ThinApp Repository. Horizon ignores the older package after it recognizes an updated package with a higher VersionID. The Horizon catalog lists only the updated version of the package.
Because the AppID of the new version of the application is the same as for the prior version, shortcuts on user desktops point correctly to the updated version, and user entitlements are also preserved.
You can safely remove the prior directory of executables for space reasons at any time if all endpoints use download deployment mode for their ThinApp packages. After the Horizon Agent downloads a ThinApp package to an endpoint, removing the package on the repository has no effect on the endpoint. When the Horizon Agent polls the ThinApp Repository at the scheduled interval, a new package is downloaded to the endpoint to replace the old one.
How does Horizon handle updated packages it discovers on the ThinApp Repository?
The Horizon Connector discovers application folders in the ThinApp Repository containing packages with identical AppID values. The Connector compares their VersionID values and considers the package with the highest VersionID to be an update. The Connector then uploads the highest versioned package to the Horizon Service. When the Horizon application catalog is refreshed, it lists only the most recently updated versions of ThinApp packages.
When the Horizon Agent on the endpoint periodically polls the Horizon Service, it receives the most recently updated version of the ThinApp package. If the Agent already has this application, and the received package has a higher VersionID, then the package is determined to be the update. Because the AppID is the same for the new and updated packages, user entitlements to the ThinApp package are retained.
The interaction of the Horizon Agent with the endpoint is different according to whether the ThinApp package is downloaded or streamed to the endpoint:
- For download mode, when the Agent identifies an updated package during its periodic poll of the Horizon Service, the Agent downloads the new package to the local ThinApp cache folder on the endpoint. If the user is currently running the older version of the application, that version is running from the ThinApp cache. The Agent does not replace the old version in the cache while it is running. On the next periodic poll of the Horizon Service, the Agent again checks if the old version of the package is running. If not, the Agent downloads the updated version of the package to the cache and deletes the old version. If the old version is still running, the Agent checks again at the next polling interval.
- For streaming mode, there is no cache on the endpoint with the ThinApp packages. The user runs ThinApp packages from shortcuts pointing to the application share in Horizon. At the polling interval, the Agent replaces the shortcut on the endpoint to point to the path for the folder of updated executables on the ThinApp Repository. This change happens at the polling interval; the Agent does not wait for the user to be finished using the application. The user continues to run the old version of the application until they quit it. The next time the user launches the application, they do so from the updated shortcut, and they run the updated application.
Additional Information
At the current time (ThinApp 4.7.2), a limitation exists in the Horizon Agent handling of updated ThinApp packages in download mode. If the user is running an application, it is standard behavior that the Agent does not replace the old version of the application in the local cache. The limitation is that the Agent records a successful download of the updated application, even though the Agent failed to download the application. On the next poll, when the Agent receives the updated application again, the Agent discovers that the application is marked as already downloaded to the endpoint. The Agent does not check if the endpoint has the old or new version, but accepts the marker that says that the updated application has already been downloaded to the endpoint.
Update History
Request a Product Feature
|
|
