Please make sure you download our latest release. More information: http://www.vmware.com/support/thinapp4/doc/releasenotes_thinapp404.html
Since we get a number of questions on how to use AppSync as well as how it can be utilized, specifically around ThinApp packaged applications such as Office or Adobe CS which are not a single executable like Firefox, Opera, or Adobe Reader, we figured it best to create a video to review how AppSync works, show how to use AppSync in general, show how to use AppSync with packaged apps having separate data container files and/or multiple entry point EXEs, and discuss what is required when needing to have clients download just the differentials vs. the whole updated ThinApp packaged app (i.e. slow links, remote/home users/etc.).
NOTE: Click the FULL SCREEN option to view a larger, more detailed image.
Just wanted to share some tips on how to apply updates to a ThinApped package.
There is three ways of applying updates to a ThinApp project.
1. If you just have a couple of updated files then you simply copy them into the project and rebuild.
2. If the application have a built in mechanism for downloading and applying updates (Mozilla Firefox has for example Help – Check for Updates) then you simply run this feature from within the ThinApped application and all updates will be applied to the sandbox (I recommend WriteCopy as the default isolation mode just to be sure everything is sandboxed). Then you run sbmerge to update the project and then rebuild.
3. If the update is a separate downloaded file you need to run this update within the virtual environment of the package. The simplest way to accomplish this is using a CMD entrypoint (just enable it in the package.ini if you do not have it and rebuild) and launch the downloaded update file from within the cmd. All updates end up in the sandbox (default isolation mode should be WriteCopy) and with sbmerge you update the project and then run build.bat.
Running sbmerge:
1. Open a cmd prompt.
2. Place yourself in the project folder (C:\Program Files\VMware\VMware ThinApp\captures\ApplicationName)
3. Run sbmerge, “C:\Program Files\VMware\VMware ThinApp\sbmerge.exe” Print this will show all changes that will be applied to your project. “C:\Program Files\VMware\VMware ThinApp\sbmerge.exe” Apply will do the actual update to your project. Since there is no reverting sbmerge you should keep a backup of the original projectfolder. The sandbox should be in the default location on this machine. The sandbox will be deleted after the update.
I’m being asked quite frequently if there is a way to add functionality to the MSI file that ThinApp generates. Yes there is, besides the obvious of modifying the MSI file in a MSI editor you may want to always change its behavior to reflect a company standard.
From the manual:
In the Vmware ThinApp folder you will find the file Template.msi. You can customize this template to ensure the .msi files generated by ThinApp adhere to company deployment procedures and standards. For example, you can add registry settings that you want ThinApp to add to client computers as part of the installation.
Even though it is in the manual not many seems to find it..
We are going to re-visit question 2 and 3 from Part 1, hopefully you’ve drawn some conclusions about which applications to stream and which ones to deploy over the last week or so. Question 2 really deals with the question of where to put the thinapp packages which are your applications. The options are A. C: drive of guest VM B. User Data Disk or C. Fileshare. Options A & B are for deployed packages and C is for streamed packages. If you’ve read this paragraph are lost already then make sure you read Part 1 and then come back to this post J For option A you’ll need to consider the specifics of the desktop pool, specifically the template that the VM’s are based off of if you’re using View Composer and whether this is a persistent or non-persistent pool. When using View Composer its likely you’ll be doing a recompose and refresh operation periodically which will affect the linked clones off of the C: drive. You can use that to your advantage because it is an opportunity to not just patch the OS but update the thinapp applications on the C: drive. Consult the View Admin guide for the details of View Composer, but basically you are going to power on the VM that the other desktops are based off of, patch it, put some new thinapps in, and then take a snapshot. At that point, you go to the View Administrator and say that you’d like for the desktop pool to now be based on that new snapshot. In one fell swoop you’ve updated the OS and Applications. For thinapps that you deploy in the vm its hard to beat this and there are very few downsides. The limitation you do get is that updating only the thinapps has to be done using some other process, like a script that pushes the.exe’s out to a certain directory, or configuring the packages to use an AppSync url, or use a sw distribution tool to do the work for you. So go through the process of a View Composer refresh and weigh that against the effort to update via the other methods discussed in Question 3. Summary – View Composer + C:\ThinApps = very efficient OS and App management Option B is slightly different in that it utilizes User Data Disks. UDD’s are basically a separate vmdk (virtual disk file) that is logically attached to a virtual desktop. I tend to think of them as the equivalent of USB drives as they are a different drive letter, can be moved between vm’s, and maintain more of the personal data such as profile, my documents, and typically user data. (profile and my documents are automatically redirected here from the C drive) So there is more of a separation between this location and the C:\ of the vm which is maintained by the Administrator. The advantage of that is that users can have their own directory of ThinApps which can either be populated by the Administrator or they can drag over from a central location. This gives the user some control over which applications they want to use but Administators will need to create a central directory of ThinApps for them to choose from. So it’s not truly user installable apps because the administrator has to prepackage the app and virtualized apps are never installed anyway. Summary – UDDs (D:\ThinApps) provide a location with a little bit more user liberty that is not affected by View Composer ‘Refresh’ or ‘Recompose’ operations on the template VM. Option C is for those apps that you have decided should be streamed. A fileshare location is all that’s required but I’m a big proponent of DFS for this as a simple way to provide a logical link between your desktops and your virtualized applications. When we get to Part 3 or Part 4 of this series we will get into the details of application registration, but at this point just know that it’s handy to be able to reference an entire directory of applications without putting in a server specific share. Its probably reason enough to just mention that to provide a redundant fileshare is important and DFS is a simple means to do that. The fileshare should be redundant and have plenty of bandwidth and locked down to read-only for users of course. Summary: Streaming Apps need to live on a highly avail fileshare with plenty of network throughput Now for Question 3. How do I manage updates to virtualized applications? There are two methods of updating thinapp packages – Side-by-Side or Appsync. Side-by-Side is my personal favorite because it means simply placing a new package next to the older one and naming the newer package.1 or .2 or .3. No downtime for update and easy contingency (just rename the file) built in to back out of update. Another reason that side-by-side appeals to me is that it can be used on a central fileshare or on a local directory of thinapps. Same update method for both deployed and streamed thinapps – the practicality appeals to me. Appsync isn’t a bad mechanism either but its usually used to update applications that have been deployed on unmanaged machines out in the wild via a Https location over the Internet. With AppSync you can centralize the updating ‘from’ location to a UNC location. However, when using AppSync you need to incorporate the update ‘from’ location when you package the application so think through this before you distribute the packages. The package.ini should include a line like this before you build the package - file://<server>/<share>/<path>/<package_name>.exe The major benefit here is that you can have decentralized packages that look to a central location for updates. So there is no need to use something in the middle to actually distribute the updates. This is probably the determining factor for whether you want to use AppSync or Side-by-Side. If you have a mechanism to put a package.1 file in a C or D drive directory then Side-by-Side is a good option, if you don’t have a good distribution process or mechanism then use AppSync. So those are the two methods of updating, let’s relate that back to our primary discussion of View desktops and the Options A,B, and C that we laid out above. Keep in mind that these methods are only needed when you want to update applications for Option B or Option C when you aren’t using View Composer for application updates. Also, Option C is a little different because it’s a shared directory so Side-By-Side is your best option. Summary of suggestions for how to update virtualized applications Option A. C:\ThinApps - Use View Composer for thinapp updates or Side-by-Side for application only updates. Option B. D:\ThinApps - Use AppSync or Side-by-Side Option C. \\Server\ThinAppShare - Side-by-Side or just replace the package with newer version Hopefully this will provide you a good framework to look through as you make your design decisions. I’m looking forward to Part 3 where we will discuss some of the finer details like persistence of application settings and application registration. As always feel free to comment or contact me directly via aaronblack@vmware.com or twitter: aaronblack_vmw