During my experience working with VDI/EUC deployments with customers one thing becomes pretty clear during engagements, it’s not necessarily about the actual desktop as much as it is about getting access to the applications that your users need and require to be productive. Over the last few years getting these applications to the end users required a couple of tricks and deployment models to present them. From a VMware View perspective initially you had two “native” options, install the needed application into your golden image or images (which lead to both image and View pool sprawl) or leverage VMware’s ThinApp product to create and isolate the applications from the underlying operating system. With ThinApp came the challenge of the application delivery; a not so robust integration with the Horizon View Administrator console, leveraging Microsoft Group Policy setting to deploy a MSI, and finally logon scripts and file shares.
In August of 2014 VMware added an additional application strategy with its purchase of Cloud Volumes which has since been re-branded to VMware App Volumes. App Volumes leverages an application “layering” approach (similar products are available from UniDesk and LiquidWare Labs), where as the application or applications are installed into a capture virtual machine and saved as a VMDK disk (this is the lite explanation). This VMDK or “layer” can then be mounted and accessed by multiple virtual desktops for a “just in time delivery” mechanism for your application sets.
Seems like the holy grail right? Well for the most part it is, with one exception. Many organizations still have legacy applications that require a specific version of Java, or require an outdated browser such as IE6. This is the beauty of VMware ThinApp, with its ability to virtualize and isolate applications and their dependencies from the operating system you could run multiple versions of Java on the same virtual machine. So, what do you do if you still have legacy applications that are best served being virtualized via ThinApp but you want to use the power of App Volumes to distribute them? Well, you put your ThinApp’s into App Volumes of course!
VMware ThinApp Capture Process
From a VMware ThinApp perspective there is little to do or change about your existing packaging process. If you are unfamiliar with ThinApp and how to capture a package, I have blog article HERE that provides the overview of the process. One key thing to remember/take away is that when creating your ThinApp package, since our ultimate goal is to install and capture it in an App Volumes AppStack, you need to check the box for “Generate MSI Package”:
Not the most representative of a true enterprise application, but from the example above you can see that we will be capturing Foxit Reader as our test application. I have selected the option to create the MSI file and left the name of the file as Foxit Reader.msi. Once you have the application captured, copy the directory from your project location to a file share or to a location accessible to your App Volumes capture machine.
VMware App Volumes AppStack Creation Process
With our ThinApp application captured and moved to your central repository, it is time to do some work in VMware App Volumes. The process of creating the App Volumes AppStack to be used by our ThinApp’ed application is no different then the traditional process, other then you need to execute the MSI package that contains your ThinApp’ed application as the install source. Like with the ThinApp application capture steps above, I am going to reference a previous article that walks you through the needed App Volumes steps.
As a high-level walkthrough, the following steps where performed in VMware App Volumes:
- Created a new AppStack titled ThinApp_Foxit
- Assigned the AppStack to my provisioning virtual machine, Win7AppVol
- Launched the Foxit Reader MSI file from a file share
- Completed the AppStack application provisioning process
- Assigned the AppStack to my Active Directory TA_FoxitReader Security Group
Here is a shot of the completed work in the VMware App Volumes Manager interface:
Testing it Out
With the hard work completed, time to try it out. My current golden image already has the App Volumes agent installed and I have a general purpose VDI pool already created. Using the View Client and logging in with a member of my TA_FoxitReader Security Group I get the following:
As you can see, the Foxit Reader icon is present and displayed on the desktop. What happens when I launch the application? Have a look:
If you familiar with ThinApp you are used to seeing the start up popup in the lower right hand part of the screen and the application is launched. Voila! In this deployment scenario we get the best of application virtualization via ThinApp and the ease of assignment and deployment of App Volumes.
Thanks for reading!