Updating a ThinApp can seem like a really tricky or difficult process, but in reality it is a very simple process (relatively speaking and, of course, dependent upon the application).
Updating an Application:
Regardless of ThinApp, with the nearly infinite number of Windows applications, there are literally just as many ways in which updates are performed upon those applications. Of all the ways application updates are accomplished, with regards to ThinApp, they can generally be boiled down into four types of updates.
- Manually changing the application or reconfiguration of the application’s settings from within the app.
- Copying in updates through Windows Explorer or manually entering in registry or config file modifications.
- Run the update directly from within the application via it’s built in update feature.
- Install a separate hotfix / update package to the application.
- Any combination of the above.
Whichever way is chosen, these options can also be used to update a ThinApp packaged application as well.
One of the easiest ways to ensure you get your ThinApp package updated correctly is test it in the native world. This may seem redundant on some levels, but you will gain experience with the application if you are somewhat unfamiliar with how it works and how it’s updates are applied. Additionally, this can be done on a clean Capture and Build (CnB) system – giving you the opportunity to capture the app with the upgrade separately to give you a baseline of what the updated project should be similar to.
ThinApp Project Updating – Capturing the App:
One of the first ways we can update a ThinApp project is to just capture a new one. While this isn’t traditionally seen as an actual “update”, it is definitely an option.
Additionally, one can also capture just the update – although this is not recommended as it can be a cumbersome and troublesome process. Plus, there are easier ways to achieve the same results.
ThinApp Project Updating – Manually Customizing the Project:
Another option for updating a ThinApp project is to directly modify the application’s files/registry settings within the ThinApp project. A minimally skilled application packager can easily accommodate simple modifications to a ThinApp project by simple file manipulation. As ThinApp has no need for an external editor GUI, this is easily accomplished via Windows Explorer and Notepad.
One can simply edit the files within the project just as they would on a natively installed version of the application. Simply replace the actual path with the variable path to find the files and folders you are looking for.
Virtual Registry Hive Mods – Beware!
One thing to beware of when modifying the virtual registry hive text files is to ensure the file is edited properly and spaces are left between each of the registry key sections.
ThinApp Project Updating – SBMERGE:
Aside from the above, the last way to update a ThinApp Project is to import the settings from within the Application’s Sandbox.
Remembering the sandbox to be a “Runtime Modification Storage Area”, this means if the application packager can install the update through the virtual bubble, the update is applied to the sandbox.
To do this…
- Start with a clean sandbox – otherwise one runs the risk of contaminating the application with additional modifications or settings which might be undesirable.
- If the application has a built in update feature, just launch the application and run the update feature. If the application update is via a separate hotfix / update, run the update.
NOTE: The person who is the application packager may have to reconfigure the PACKAGE.INI in order to allow access to the virtual CMD or other tools to view the virtual file system and launch the hotfix / update. Typically this is a simple modification to the Entry Point for those items within PACKAGE.INI – setting the “Disabled=1” value to “Disabled=0” or remarking it out with a semicolon. This modification requires a rebiuld of the ThinApp package before applying the upate to the app sandbox and executing the sandbox merge into the project via SBMERGE.EXE. Then, once the updated sandbox is merged, resetting the “Disabled=0” value to it’s original state and rebuilding will remove access to the ThinApp via that specific Entry Point (i.e. CMD, etc.).
- Once the update is in the app and everything has been tested to work, use SBMERGE to merge the sandbox back into the project.
Simple SBMERGE Process:
Here is my simple SBMERGE procedure which works flawlessly every time:
- Make a copy of the original ThinApp Project WITH the BIN folder and it's contents (EXEs/Data Container).
- Clear the SANDBOX within the %APPDATA%\THINSTALL folder.
- Run the primary app in the project to be updated.
- Update the app with plugins, settings, updates, modifications. Close the app.
- Relaunch the app and test the updates exist and work.
- Close the app.
- Open CMD natively.
- Change Directories (CD) into the project to be updated.
- Type "SBMERGE APPLY"
NOTE: If successful, the ThinApp Sandbox for this packaged app will have been removed from %APPDATA%\Thinstall.
- Execute BUILD.BAT within the project just updated by SBMERGE.
- Run new version of ThinApp packaged app to test updates/mods.
- Deploy via AppSync, Side-by-Side, MSI (via ESD), etc.
This was previously documented here on the ThinApp Blogs.
ThinApp Package Updating:
Once the updating of the ThinApp project has taken place, it has been built and successfully tested, all that remains is updating the existing ThinApp package currently in use by users.
Quite simply, this could be done in the same manner the original ThinApp package was pushed out, but to iterrate all of the options, they are as follows:
AppSync is an End Point initiated (not client as there is no ThinApp client installed) solution where the ThinApp packaged app on the remote system initiates the update. It is not required to use if you wish to utilize another application devliery/update mechanism.
The way it is configured is like this:
- The administrator builds a ThinApp packaged app such as Office.
- The ThinApp package is configured to look at a web server (IIS, Apache, Abyss, etc.) via HTTP, HTTPS, or even using the FILE protocol, on a set frequency (hours, days, weeks, etc.) for an updated version of this packaged app.
NOTE: This server is called the AppSync server and can be any web server you already have – even behind a VPN. It is then deployed to those remote End Points in whatever fashion using the tools you use to deploy apps to users today.
- At some point in the future, the administrator deems the ThinApp packed Office needs to be updated and install those updates (let’s say it was 20MBs of updates) into the ThinApp Office project via one of the aformentioned update processes and rebuilds the project into the package.
- The administrator then puts the NEW ThinApp Office package (the whole thing) up onto the AppSync web server.
Now, the next time a user on a remote End Point launches their ThinApp’ed Office, it will detect the update on the web server. This is done by the ThinApp Virtual Operating System (VOS) built into the original ThinApp package (in our example: Office) through the following processes.
- The original Office package (or whatever the ThinApp package is) launches on the end point (let’s say a user’s Home System) and checks the AppSync Web server by conducting an SHA-1 hash comparison on itself (the whole package) and on what you just put on the AppSync server.
- If the hash values are different, then ThinApp knows the package on the server is newer.
- If newer, ThinApp then does an SHA-1 hash comparison on each block of data in the package on both itself and on the package on the server to determine the block level differences in order to only download just the differential data (in this case, the 20MBs of hotfixes) rather than the entire package (which, with Office could be as much as 1GB!).
- Once the differences are downloaded, ThinApp recompiles itself in the background and the next time the user of the remote End Point launches the ThinApp package, they are launching the updated package.
Using AppLink to update an application is not a recommended procedure – however it can be done.
As it is not a recommended procedure, the configuration of AppLink for updating packages will not be covered here. Reasons it is not a recommended procedure are:
- The Parent ThinApp package will likely still need to be modified to accommodate the AppLink.
- The Child ThinApp package may need to be a required AppLink. Without diving into a long, dark, twisty rabbit hole, this can potentially be detrimental and/or cause additional work.
- While not a huge issue in most cases, the Child ThinApp package cannot be executed on it’s own.
- The Child update process cannot be utilized with AppSync with the Parent app.
- There are other better and easier ways to achieve the same results. Additionally, the use cases for conducting this type of update are highly unusual and very infrequent in nature.
One of the most easiest ways to update a ThinApp package already in existence is by placing the updated package next to the original package. This can be done whether the package exists on a PC’s local hard drive being accessed by one person or on a file share where the ThinApp package is being accessed by numerous people.
The beauty of this is it can be updated during production, it’s easily rolled back in the unlikely event an issue occurs, and because the update is just a file copy process, the need for downtime is either drastically reduced or completely eliminated!
To do a side-by-side update, simply rename the “new” ThinApp package to the same sir name as the original ThinApp package and use a numbered extension.
In the above example, the original JAVA.EXE package has been upgraded twice – the original file being JAVA.EXE, the first upgrade being JAVA.2, and the second upgrade being JAVA.EXE.3.
Using the above example, in the unlikely event JAVA.EXE.3 were to “break” something, the administrator could simply delete JAVA.EXE.3 if it was not locked open. But if it was locked by the file system (maybe it mostly worked except one part), the administrator could simply copy JAVA.2 and rename the copy to JAVA.4 (or JAVA.EXE.4) to roll back.
Wrapping this into a View deployment (or maybe a Terminal Server farm deployment), one can easily upgrade and downgrade all apps without taking any systems down. Additionally, the only remaining network downtime would come when a need for cleaning up the file system surfaced. This would simply be a deletion of all of the old packages and renaming the latest working package to the original file name. Using our example above again, we would delete JAVA.EXE and JAVA.2, then rename JAVA.EXE.3 to JAVA.EXE and leave for home five minutes later than usual!
For a video example, see the ThinApp Blog Article, "ThinApp Side by Side Updating Video".
To use an MSI to deliver application updates, there are a couple of things which must occur between the “old” and “new” versions of the ThinApp packaged app within the PACKAGE.INI files of these ThinApp Projects.
- MSIProductVersion values must be valid MSI Version numbers in the format of XX.YY.ZZZZ and the version number of the “new” ThinApp project must be a higher numerical value than the other app. By default VMware uses a value of “1.0” here.
- MSIProductCode values must be a valid GUID which is unique to each of the projects. In other words, the “new” ThinApp project (seen on the right side) must have a value different than the old ThinApp project (on the left side).
- MSIUpgradeCode values must also be a valid GUID, however these values must match exactly in both the “old” and “new” ThinApp Projects.
- It is recommended to use a different MSI File name for each project so as not to get them confused.
NOTE: Free GUID generators can be found out on the Internet.
Once these values are set correctly, it’s simply a matter of building the “New” ThinApp project and delivering the MSI either manually to the user or automatically through an ESD tool.
The resulting behavior is, when the MSI of the “New” ThinApp package is executed, it will automatically detect and remove the older ThinApp packaged app (or a natively installed app of the same MSI Upgrade GUID) and replace it with the new ThinApp package.
So, to wrap up, updating a ThinApp is a simple three part process.
- Updating of Applications is done through various means.
- Each app will have it’s own unique process for updating, so referring to “ThinApp Mantra #1” – Know Thy App!
- You may have multiple options for updating and configuring the app.
- Once the update of the application is done, updating a ThinApp Project can be done by a couple of different means:
- Simply capturing the new app with the update is always an option.
- Capturing just the update (for use with AppSync) is not recommended.
- Manually direct configuration or modification of the Project files/folders is absolutely allowed – especially if it’s a simple update.
- Use of the SBMERGE tool to import settings and updates captured in the Sandbox into a copy of the project is always a solid option.
- Finally, updating a ThinApp Packaged App can be very easily done via…
- ThinApp’s built in AppSync feature from an existing web or file server which is then allows the pulling of delta updates by the Remote End Point.
- AppLink (Not Recommended)
- Side-By-Side file updates is extremely easy and virtually eliminates any downtime to the user by simply copying the updated package with “.#” extension.
- ThinApp can generate an MSI of any ThinApp project – with can then be delivered to the remote systems via any ESD solution.