VMware ThinApp Blog

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