Skip navigation

Dons EUC Blog

4 posts

Throughout my time working on the View and Horizon portfolio, there has always been one driving factor for every deployment.  The desktop.  From handling the intense I/O of boot storms, to abstracting every element to achieve a non-persistent environment, to licensing of the Windows OS and applications.  Desktop, desktop, desktop!  Well, that probably isn’t going away, at least any time soon, but new additions to the Horizon and AirWatch suites are creating options that can allow us to ask. Is a desktop needed?

              We are moving deeper and deeper into the mobile workspace.  A space that is much harder to define but at the same time has much simpler requirements, that is applications.  Users have become accustomed to using their mobile devices to achieve tasks.  We are getting to a World where a user can complete a menial tasks in 15 seconds over their phone as opposed to taking 5 minutes to walk to their desk to access a desktop OS (VDI or not).  If you have ever accessed a virtual desktop over a phone or tablet, it can be a challenge to say the least accessing a full desktop OS over a small screen.  This is where the application first mentality comes into play.  If I can deliver a functional application platform that can be utilized easier over mobile devices, could this offer more flexibility than a traditional VDI implementation?  Utilizing the new Horizon View capability to create RDSH linked clones tied with App Volumes allows a RDSH environment that is as easy to tear down as a linked clone desktop pool.  AirWatch’s Project A2, AirWatch and App Volumes integration.  This allows for a device agnostic, BYOD architecture that can offer applications to devices, regardless of operating system or type.

              Of course, net every workflow and use case offers the ability to fully remove the desktop OS.  Like when Linked Clones came around, there are many benefits to getting to that design, but sometimes requirements force design compromises that make it impossible.  To touch on a few of these benefits. Application licensing, in some cases there will be applications that require a terminal server license, but I see that as far easier than the normal head ache of attempting to get all my licensing working in a non-persistent environment.  Second, OS licensing.  RDSH CAL’s do not require the same level of compliance as far as endpoints are concerned as VDA does.  For those who have not read about this, have fun, it is as complicated as you would expect out of Microsoft.  I also see more flexibility as to how resources can be added on the back end. If users are having performance problems, throw another server in the farm.  You cannot throw another desktop at a user, you normally have to expand resources for everyone, or find some fat to cut on the image.  To me the biggest benefit is embracing a true BYOD environment. You have users who prefer Mac, then they can use their Mac.  Applications are delivered to the OS looking as if they are installed and users can work on their preferred device.  As well, they can switch devices and maintain their applications and content. 

              What I see is the World of EUC and Mobility merging into a next generation EUC solution.  Breaking away from the OS silo’d model and into a range of applications.  In a way we are already there.  Many applications are offering mobile options and SaaS applications are already offering a BYOD, application anywhere, solution.  I expect users that leverage that now will demand that level of mobility for many of the applications they are using.  I feel like I have been pushing desktops to replace remote applications for years and now I am trying to talk people back into remote apps. I imagine that somehow in the future, I will be writing a blog talking about the merits of going back to the desktop.

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.

With the advent of virtualization and End-User Computing (EUC), a complex set of variables comes in to play in order to build a successful EUC solution. Over time, I have learned my best bet is to use the Occam’s Razor approach, designed by English philosopher William of Ockham. Occam’s Razor is a problem-solving principle that states among competing hypotheses that predict equally well, the one with the fewest assumptions should be selected.

Other, more complicated solutions may ultimately prove to provide better predictions, but—in the absence of differences in predictive ability—the fewer assumptions that are made, the better.  He is also credited with stating, “entities should not be multiplied unnecessarily.” In simple terms, the simplest, working solution, is the best solution. So often it is easy to dive into the abyss of technical capabilities and get lost in that ocean, drifting, waiting for a lifeline.

To keep things in context here, I would not suggest using triple the resources so you don’t have to virtualize one application. Simple is also much more than how technically complex a working solution is. Simplifying deployment and management are key pieces to the puzzle.  Today, there are A LOT of options available to solve your technical problems within the EUC realm. If you ask the vendor, their solution can walk on water and bend space time. Many of these tools are great but can also have the most pragmatic Engineer jump off the deep end and scheme a strategy that creates a black whole of abysmal technology.

If I could provide some thoughts…

When tasked to design a solution, ask yourself three questions. First, why? Is there a reason to do it that way or does it just sound cool? Second, is the juice worth the squeeze? Are you spending weeks to eliminate a task that takes 15 seconds to do manually? Third, what is the impact? Will this impact operability? Will this impact ease of management? Here are some almost universal truths I have found in my EUC travels.

  • Plan. This may be the craziest idea I place in this blog. What kind of anarchist am I?  Seriously though, the idea that you can make it work is a kiss of death. Shortcomings and oversights can stall or downright put your project out of its misery, and it WILL be misery if you don’t plan.
    • Define your use cases. Determine what your users will need. Sometimes you can qualify them or disqualify them before you ever get a quote. The users that are running SQL servers on their systems running queries all day – good luck with that!
    • Use tools to assess your environment. Seriously, you cannot wing it! This isn’t for the folks trying to virtualize their kiosk workstations. If you are an enterprise with 1,000 users and six different use cases, the capital expense you spend to get a good assessment will be saved 10 times over in the operational expense and Rolaids you will be continually purchasing.
    • Inventory your applications and licensing. Ensure you know what you are getting into because, at the end of the day, your job is to get users their applications. Ensure that licensing is or can be obtained to fit within the deployment model you have chosen or have been forced to use.
    • Do the math! OK, you can use a calculator, but run some numbers bro (or sis)!  Look at not only the infrastructure requirements, but also growth. Don’t think you are done because you figured your IOPs, CPU, and memory. How fast do your users profiles grow? How fast does your image grow? The best way to minimize risk is to draw out the solution with math. You should be able to know exactly what the environment will look like before you even have it if you use solid math.
  • You are not going to virtualize every application. I promise you, you will find yourself trying to cut through a Constantine barbwire spider web of integration that will leave you wondering what is impacting what. If you are setting up a VDI environment, find common denominators and leave them in your image whenever possible. This will allow a simplistic approach to management. How do I patch these applications then you ask? You still need to patch the OS so you will have plenty of opportunity to patch locally installed applications to your heart’s content.
  • Try to get to a non-persistent, linked clone environment. That should be the goal. The bonus in ease of management and resource consumption makes this a no brainer.  There will be use cases that will not allow it, but don’t let that discourage you. You cannot always get what you want. I once heard, if you try sometimes, you just might find, you get what you need. Set a goal and let the use case determine if it is feasible.
  • Just because it is easier to create a pool for every use case or static desktops for everyone does not mean it is the simplest approach. It is a gargantuan, management nightmare. If someone would argue it is the simplest solution, I would argue it is easier to use physical desktops then VDI. There are some situations that make this a necessity. Really make sure it is and think outside the box. One of the biggest goals and key business drivers is consolidation and cost effective use of resources.
  • For all the complexity you introduce there is often a tax associated with it.  Most times this tax comes out of infrastructure performance or capacity. Sometimes it comes at the expense of your sanity and free time. As the saying goes just because you can, doesn’t mean you should.  Who ever said that was a genius!  Here are some examples of the complexity tax.
    • Streaming 100 applications via ThinApp. Those applications being streamed consume bandwidth. Those applications will require IO on the shares they are streamed from. Make sure there is a reason you do it.
    • Creating 20 pools to keep from having to ThinApp a couple applications. Those pools will have Replica disks that are IO intensive, they will consume space, and it sounds like they will probably require their own image (I will touch on that next). If you have a reference architecture based solution by any of the big vendors out there, I guarantee you they did not design it for 20 pools. You can delete that PDF and empty your Recycle Bin if that is the road you go down.
    • Creating too many images. Managing multiple images is a pain in the butt. The last thing I want to do is run Windows Update four or five times, much less update every single other application on that base image. A lot of times, it is hard to have just one image. If the only reason is because one user needs Visio and one needs Project, I suggest you find a way to package those applications.

In reflection, the title and premise of this blog is almost an oxymoron. A simple EUC environment is like a redheaded unicorn (being a ginger myself I can state this without offending any unicorns). You will be hard pressed to find one. For that reason, I find it even more imperative to strive for simplicity, because you will not get it easily. So push for it and compromise where you must. Do yourself a favor, do not be part of the problem. You are here to deliver a solution.

Whether you are knee deep or in the beginning phases of your Virtual Desktop Infrastructure (VDI) or End-User Computing (EUC) project, you have probably encountered what most Architects and Engineers do as they push through the rabbit hole of the project. After a smooth start to creating desktop pools and wowing at the magic of Linked Clones, the project has come to gridlock and the design principles have been compromised to accommodate for applications with requirements so rigid that under traditional deployment methods they do not fit into the upside down, backwards shift End User Computing often brings.

Part of the challenge is many of us are infrastructure folks that get assigned these tasks and tend to focus on the core infrastructure technology. We start thinking about spinning up 1,000 Linked Clones on a high-end hyper-converged platform or hot tiering storage array. Implementing vSphere as the orchestra, vCenter as the pulpit, and conduct a symphony of automated workflows that took teams of people to manage in the past. All of this without having to change out of my sweats, much less touch a physical computer.

Amidst the sweet sounding cellos of an Xtreme I/O or the harmony of my Nutanix, I begin to hear the whine of my end users. I need Visio; I need Photoshop; I need my CAD tools; I need my developer tools. I am also finding that the folks who have been installing applications, more or less, click ‘next’ and ‘finish’ as long as there is no deviation in that order. My career is coming full circle now, installing desktop applications for end users. If only I had known beforehand the challenges I would face!

In an ideal world, it is best to build your VDI requirements within an overarching EUC strategy.  These issues are one of the most common reason that a VDI projects stalls.  Resource constraints can normally be resolved by throwing money at problems. Sometimes an applications can downright not work in a non-persistent, linked clone environment.  The proposition I make is that before we start with VDI, let’s start with a strategy and build rock solid requirements.  In the end, we need users to be able to access applications in order to do their job.

Look at auditing those applications to discover…

  1. What is my applications strategy?
    Define a process to qualify an application based on your use case and application delivery tools.  Start with your primary method and see if the application can fit within it. Be ready for frustration. Think outside the box and have a diverse portfolio of application deployment solutions to assist.
  2. What is the licensing and what is available? Always look for central/volume/site/concurrent usage licensing models. If you cannot find them that does not mean you are at the end of the road. You will just have to ensure you have a strategy to deliver the application to your users. With the advent of Horizon View RDSH hosted applications, Horizon Workspace, and App Volumes, there are several options beyond the traditional ThinApp or go home approach you previously had with VMware products.

These first two pieces are very important to project success in my mind because if you can have these two questions answered, you should be set for smooth sailing.

First, evaluate and determine what models of delivery you would like and what you need.  Your needs will be based off of your application audit. If you have a critical application that has a license that ties to a MAC address, then you might want to consider exploring a hosted applications solution. Second, assume one tool will not get the job done. Some applications can be re-directed without issue, some will have to have a level of isolation that only ThinApp can offer, while some will only work if hosted on a server. Be prepared to be diverse. If you want your EUC solutions to be flexible, you have to be, too.

After you have sorted through what you have to deliver and what tools you can utilize to create a solution, don’t be afraid to ask yourself “Is it possible and feasible based on the resource and cost constraints within your environment?”  The thought that anything is possible is for idealists and artists.  Be pragmatic and honest with reality.  You are an engineer not a philosopher.  It is completely possible that the current EUC capabilities tied with the application’s constraints make the application, and therefore its users, less than ideal candidates for your EUC solution.  It is not always easy to accept but sometimes no is the answer.  That said, with a smart and imaginative mind you will often find a way to make it happen.  I do not care for persistent desktops but a persistent individual is often the best weapon when working through a VDI deployment.