Linked Clone Environments: Application Qualifications and Requirements

By far, the most complicated component of a successful virtual desktop deployment is applications. Fully understanding applications, the installation, licensing, and update process are a time consuming, complex,, and unnerving process. With the advent of the decoupling of components in Linked Clone Virtual Desktop Infrastructure (VDI), Desktop as a Service (DaaS), and application virtualization, certain methods of application licensing, installation, and configuration currently used in persistent physical environments will require changes to meet licensing compliance and insure proper functionality in a Linked Clone environment. In some instances, with all the tools available, an application can be problematic or not function when introduced into a Linked Clone environment. Sometimes, you get it to work and are downright baffled at how it does.

Below are application qualifications and requirements commonly used by GANTECH’s End-User Computing (EUC) experts.

But, before we discuss considerations, it’s important to understand the basic terminology.

• Linked Clone Desktops – Desktops that are clones from a central “master” or “gold pattern” virtual machine
• Application Virtualization – A method to create a central application package that is run in conjunction with a guest operating system. Common solutions include; VMware ThinApp, VMware App Volumes, LiquidWare Labs FlexApp.
• Horizon DaaS – VMware DaaS offering, formally known as Desktone. As well the Horizon Air public cloud DaaS service would fall under this.
• VMware Horizon View – VMware’s private cloud VDI and EUC offering

Application virtualization can present challenges in itself.  The simple fact is, there is no way for one person to be a Subject Matter Expert (SME) on every application, much less a virtualization SME. If you are, stop reading, go ask for a raise, and please offer this humble author some pro bono work for his advice! There are many applications that are contingent on; available licensing, the level of the operating system they install, other dependencies, and how the application is coded. These considerations can impact or exclude one or all forms of application virtualization software as a workable solution. Unfortunately, there is no guide, there is only the definition of insanity. Keep trying until you win or give up is sometimes all you can do.Linked Clone VDI Considerations:

1. Licensing: The thing that spoils all the fun for most of us technical folks. Why do they not just give this stuff away for free? Generally, licensing options for Linked Clone environments should include volume, concurrent user licenses, site licenses, unlicensed, or managed with a license file or licensing server. For Linked Clone virtual desktops, problems may be encountered with single user, named user, or per device licenses due to the nature of central user installations being done with a local admin account, and the fact that the desktop is replaced during any reconstitution operation. Licensing compliance must still be met and if there is any question as to if your licensing allows you to run the software in a Linked Clone environment, you should consult your vendor to verify you will be in compliance.
2. Single User Installs: This to me is becoming the 1990’s way to license an application. Pick these away with the stain wash and VHS recordings of Murphy Brown. Generally, applications that will only install for the logged on user will be problematic being deployed in a Linked Clone environment. The reason for this is that applications are almost always installed on a base image by the local admin account. User base installs will only be available to that account during linked clone sessions. Installs will have to be possible for, “all users”.
3. Cloud Drive Installs: Cloud drive installs that create a local sync’d copy of files on the Guest and can introduce a heavy IO and bandwidth load after reconstitution of a desktop pool. Upon each reconstitution of the pool, all files will have to sync to the users new desktop. In large scale environments this can be especially problematic.
4. Per Device Installs: iTunes is an example of an application that can be virtualized but will only allow a device to sync with a specific number of computers. As much as I love an opportunity to hate on Apple, it is not just Apple in this case. In a Linked Clone environment, devices will be consumed upon each reconstitution of a desktop pool. This could also be the case for other device syncing software. Consult the vendor for more details for other devices.
5. Scripting Options: There may be situations where automation through scripting makes sense. For example, to mitigate heavy I/O impact when daily updates are required, script a symbolic link to redirect the files to be synced to a share location. Understanding the apps and how they are coded is helpful when analyzing scripting opportunities. Often apps are written to store data in the user AppData Local folder. Delivering these apps may just require first time install scripts and capture of their user persona information where any relevant data may reside.

Application Virtualization Considerations:

1. Licensing:
   1. Packaged Applications:  Generally packaged applications that are virtualized with products like VMware App Volumes, ThinApp, and LiquidWare Labs FlexApp will require a volume concurrent user licensing model that does not bind to a specific hardware or OS ID, user, or any variable that cannot be captured within the application package by the local administrator account.
   2. Hosted Applications: Generally hosting applications on Remote Desktop Session Host (RDSH) servers can offer some added flexibility for applications that have a license tied to a hardware or OS ID since the application is installed on a central server and accessed remotely.
2. OS and additional application integration and isolation:
   1. Packaged Applications:  Packaged applications can provide numerous options for integrating and isolating applications with the guest OS. There are numerous points at which the applications can be “opened up”, or “isolated” from the guest OS or native applications.
   2. Hosted Applications: Hosted applications are installed on a server and therefore have limited integration ability, they are by and large completely isolated from the Guest OS.
3. Support: Often times, vendors will not offer support for applications that have been virtualized. For more information, consult with the vendor to find the level of support they are willing to offer and what platforms they support their application being virtualized on. I can guarantee you will feel like you have no one to help you. You are probably right, unfortunately.

You have numerous possibilities in a Linked Clone environment but it’s important to understand the qualifying requirements first. As I have heard many people say, application delivery becomes an art in EUC environments. Don’t hold yourself to your previous assumptions and processes. Make sure you set expectations and understand your technical capabilities to ensure a smooth transition of your applications.