Updating VMware ThinApp Packages Mechanisms

Updating VMware ThinApp packages is much easier and scale with ease when compared to updating traditional software packages. In fact VMware ThinApp offer multiple ways to update ThinApp Software packages that every environment can find a mechanism that suit their needs. In this post, I will discuss the major VMware ThinApp update mechanisms and the scenario each update mechanism suit best. I have noticed many posts/articles around the web talk about how to use a certain VMware ThinApp update mechanism, but not many that explain when to use that mechanism. In this post, I will work on trying to cover both area how to use a specific VMware ThinApp update mechanism and when to use it.

Before going into each mechanism, its worth mentioning this post is a part of a larger VMware ThinApp series I am creating & below are the links to other VMware ThinApp posts in this series in case you were looking for one of these or interested to read about it as well.

The Magic of Application Virtualization with VMware ThinApp

VMware ThinApp Preparing the ThinApp Capture and Build Machine

VMware ThinApp Deployment Scenarios

Updating VMware ThinApp Packages Mechanisms (This Post)

VMware ThinAPP Antivirus Best Practices

VMware ThinApp Isolation Modes Explanation, Examples, & Video

OK, so let’s look at the different VMware ThinApp packages update mechanism available to you

Updating VMware ThinApp Packages with In-Place Updates

Let’s first cover how this procedure work. Let’s assume you have an application already deployed into production and this application is called package.exe

1. Carry out a capture and build for the updated version of the target application, let’s call it package in our scenario
2. Append the package container file (.exe or .dat) with .1 (or highest integer file extension +1). In our case the new package container will be package.exe.1 where next update will be package.exe.2. If you were using .dat then assuming your original package container is package.dat then you should rename your updated one to package.dat.1
3. Copy the update package next to the old package. In our example you will now have package.exe and package.exe.1 in the same folder.
4. As users attempt to launch the previous version of the application, the upgraded version executes.

Its worth noting that ThinApp will always launch the application using the container with the highest integer. Let’s assume you have a folder which contain package.exe  package.exe.1 package.exe.2 if you execute package.exe which is your original package ThinApp will actually launch package.exe.2 which is the latest version instead.

This update mechanism is best suitable for streaming scenarios. Customers who stream applications seems to highly benefit from the in place upgrade mechanism, as it allow them to carry out an upgrade of their packages with ease and without downtime. All they have to do is to copy the file next to the original package and as soon the users close the old instance and open a new one he will be running the new instance. Further, it will allow for an easy fail-back if the updated ThinApp package deemed having a problem, all you have to do is delete the package with the highest extension number and users access will be restored automatically to the earlier version which was never as quick & easy in traditional software deployment. Another way of reverting back to an older version is to copy the older version you wanted and give it a higher extension number, which might work a bit better in many cases as you don’t have to stop all users access due to the newer package being locked and can not be deleted.  It make software updating a breeze. The same mechanism can be used for locally deployed machines, though you will need to watch out for disk space specially in VDI scenarios as the packages will co-exist on all systems where you can end up having 10 copies of the same software on the same machine if you don’t watch out. Further, this method work quite well for both minor and major updates.

Updating VMware ThinApp Packages Using MSI

This update mechanism is very similar to the way you do your traditional software update/upgrade. You build the new update package with the same product name as MSI package and you deployed it to your end user machine. The new MSI uninstall the older version of the machine and install the new one. The main different of how this was done in the traditional software world it required many complications to ensure the software is uninstalled and installed correctly, where in the ThinApp world your install and uninstall is nothing but copying the package files to the machine and create the required short cuts which is created automatically during the MSI packaging. To get a package ready for the MSI upgrade you will need to uncomment and set the following parameters as follow in the package.ini and rebuild the package:

MSIProductVersion=1.0   <== Increase the version of the MSIProductVersion for every new upgrade so next one could be 1.0.1

MSIProductCode={xxxxxxxxxxxxxxxxxxxxxxx}

MSIUpgradeCode={xxxxxxxxxxxxxxxxxxxxxxx}  <== ensure the original package and the upgrade package share the same MSIUpgradeCode.

Below is a screenshot showing a sample of a package.ini for such a package

This mechanism work great for locally deployed ThinApp packages where the process can be enhanced using your current Electronic Software Distribution(ESD). This mechanism is suitable for both minor and major upgrades.

Note: If you don’t care to be in full control, you can skip manually editing the MSIProductCode and MSIUpgradeCode as if left alone (commented out) and only changing MSIProductVersion will work as long as your new package is based on the same project. ThinApp build process will handle the MSI properties..

 Updating VMware ThinApp Packages Using sbmerge

Sometime after packaging your application you remember that small setting, update, patch, or plugin that you have forgot to package into your application. SBmerge.exe is the tool that can save you from having to redo the capture and build from scratch. It actually allow you to integrate these new changes with ease in your application. You just run your application, customize it, then sbmerge it and all the updates will be integrated in the package that you can then deploy using ESD or streaming to your end users. This method is suitable to install a plugin, small setting changes, small updates. Although it could be used for major updates, it can get the package to be more fluffy that I would like it to be when using it for major large upgrades. Below is the procedure of carrying out an sbmerge.

1. On the CnB Workstation backup the project folders & its contents of the application you want to upgrade using sbmerge.
2. Launch the ThinApp packaged application from the local copy of the project folder. Then close it.
3. Clear the sandbox by deleting the %APPDATA%\THINSTALL\<AppName> folder.
4. Update the application with the plug-ins, updates, settings, configurations , and modifications. Reboot the application/system as required by the applied updates
5. Ensure that your application is functioning as expected after the update, then close the application.
6. On the command line change directories into your project directory you are upgrading and type C:\Program Files\VMware\VMware ThinApp\sbmerge.exe apply
7. Check the %APPDATA%\Thinstall folder and make sure the <AppName> folder is removed as that indicate the success of the sbmerge operation.
8. Rebuild your project by re-running build.bat from the project folder to build the updated ThinApp Application.
9. Now you can distribute the package using In Place upgrade, MSI/ESD, or AppSync.

Updating VMware ThinApp Packages Using Relink.

Unlike other VMware ThinApp Mechanisms this update mechanism does not apply to the software you are packaging, but the Virtual OS(VOS) deployed within a ThinApp package. You might wonder why would this be required. Well, imagine if you have packaged hundreds of apps with VMware ThinApp 4.0.4 and then you required a feature that was only introduced in ThinApp 4.5(ex: running applications captured on XP on Windows 7 machines), relink will make it possible to upgrade your ThinApp package VOS to ThinApp 4.5 gaining all the new features of 4.5 without having to repeat the capture and build process from scratch. Relink make updating your ThinApp package VOS to the latest ThinApp version a breeze. Actually the relink process is as easy as drag and drop as shown in the procedure below:

– You can easily update the VOS of a ThinApp package to a newer one by dragging the entry point of it into the Relink.exe file in the ThinApp Installation folder.

– You can as well do multiple applications recursively by using the following command:  relink [-Recursive] <target> [<target> …]

Updating VMware ThinApp Packages Using AppSync.

VMware ThinApp AppSync is mainly used to update VMware ThinApp packages over a WAN link. AppSync allow ThinApp packages to check for an updated version of the package on an http/https server or file server. If there is an updated version then the application only pull the difference. Though AppSync does not even stop you from replacing an application with a totally different one if you like to do that (lol replace IE package with Firefox for all of your users and watch their faces when their IE shortcut open up Firefox! Yeaha! Been there! Done that!). Let’s look on how to set it up.

– First of all you will need a webserver/fileserver that could serve .exe & .dat files (IIS & Apache work well for this purpose where IIS will require some tuning to allow it to server .exe & .dat files)

– Uncomment & modify the following lines in your package.ini as required

AppSyncURL=https://AppSyncwebsite/folder/ThinAppPackage.exe       <== This should point out to where you have the update package

AppSyncUpdateFrequency=0  <== This should tell the ThinApp package how often to check for updates. 0 means it will check for update every time the application is launched.

AppSyncExpirePeriod=0d        <== How long if the package did not check for update it will expire. Setting it to 0 will ensure the ThinApp package has to carry out any available update before running.

– Rebuild the package using the build.bat

– When ever you have an updated package put it on the same path you have setup in the AppSyncURL

– Now when ever you start the ThinApp Application it will download the updated package, though it will run the old one till the new package is downloaded where the new package will be run the next time the package start after the new package was fully downloaded unless you have setup AppSyncExpirePeriod=0d which will force the package to be upgraded before it will run when an update is available.

In case you might want to use a file server rather than an http server then the syntax of the AppSyncURL line will be as follow:

AppSyncURL=file://fileserver/share/folder/myapp.exe

Below is a screenshot of a sample package.ini  ThinApps Firefox package with AppSync enabled.

AppSync Tips:

• Both the original package and the new updated package must have AppSync activated.
• 
An Entry Point cannot have the same name as the Data Container, that might break AppSync as well (e.g. Mozilla Firefox.exe and Mozilla Firefox.dat).
• AppSync will run thinreg.exe on the new updated package if you place thinreg.exe in the AppSyncURL location.

VMware ThinApp AppSync update problems/trouble.

I have noticed many people has shared few common problems when using AppSync to update ThinApp packages and thought I will document those in here. One main problem that you will notice the update file coming up with 0 size and the package is never updated although you have done everything correctly. Below are three items to check:

1- Ensure that your webserver support all .exe & .dat files download. Test it manually and ensure you don’t get an error downloading these files from the webserver and do any modification required to allow that.

2- Try a different webserver. Two known webserver that I know for sure AppSync work with is IIS and Apache, where IIS require some modification to allow serving .exe and .dat files. I have tried before Xerver webserver at one client and that did not work for us. It might have required some modification, but we failed to get it working.

3- Ensure that the data-container name of the new package and the old package is exactly the same. As that how VMware ThinApp check if the package update is valid and for the same package or not. I believe this is one of things most people miss and not very well documented catch ya points.

Another complain I hear of ThinApp Admins is that they notice AppSyn is downloading the full package every time when monitoring their ThinApp package folder during update. This is more of a confusion than a problem. Although the files you see in the folder show the updates being downloaded to be of a similar size to the new package, this file was not totally downloaded but most of it constructed from the old package. The build process of the new package when done by AppSync is done as follow. The AppSync first download a hash file of the new package and compare it to the old one the blocks that has been updated it download it from the webserver, blocks which was not updated it just copy them from the local old package. Though it still end up constructing a full package size, most of the things it did not need to download but constructed from the earlier available package.

I hope this help every one find the ThinApp update mechanism that fit his fantasy in this post. If you have any questions or comments please leave it in the comments area below.