Many organizations still have legacy applications that require a specific version of Java, or require an outdated browser such as IE6. Seems like the holy grail right? Well for the most part it is, with one exception. 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. 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). 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. 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. 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.

Over the last few years getting these applications to the end users required a couple of tricks and deployment models to present them. 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.

Vmware thinapp client