VDI Application Deployment Strategy

Migrating to VDI from a traditional laptop/workstations world is like relocating to a new city. Lesser the baggage, easier it is.

Migrating 1000s of applications deployed through SCCM (or any other tool) from laptop/workstations landscape to a VDI infrastructure is exactly that. You will first need to conduct few preliminary exercises to understand more about your application estate before formulating a deployment strategy for VDI. Introducing Windows 10 into the mix is certainly not going make it easier for you.

There are 3 steps before formulating Application Deployment Strategy:

  1. Application Rationalization exercise
  2. Application Compatibility Testing
  3. Application Delivery Pilot

Application Rationalization Exercise

“Key goal of application rationalization exercise is to identify and if possible eliminate (or remediate) applications that are not suitable for VDI”.

For this exercise, let’s take an example of a typical enterprise customer with over 50,000 employees and 1000 applications.

Generally speaking, the applications will fall into the following categories:

  1. Core Business Applications – Business owners will have list of applications that are used by their users for the core business workflows. If it is a bank it could be their core banking software and if it is a retail it could be their inventory system and so on. It is important to get an accurate list of required versions of these applications and installation/packaging details from the application vendor.
  2. Core Applications – These are typically applications that are required by most users (if not all) to remain productive. MS Office, Instant Messaging and collaboration software like Lync, internal HR, employee portals, Google Chrome and so on.
  3. Long Tail Applications – These are applications that are occasionally used by small group of users. Since it is hard to predict when they will be used it, it is common practice for IT to push it users who may need it. I wouldn’t be surprised if 20-40% of all applications fall into this category.
  4. Redundant applications – Different versions of the same applications is common in the enterprise. It for the business owners and application vendor (if applicable) to confirm the version(v) or (v-1) of the application that is supported and recommended for their end users.
    1. Common reasons of seeing redundant applications are:
      1. OS and platform dependencies
      2. Inability to keep applications updated.
    2. VDI should ease the above two problems as users will be using a standard OS build and applications are updated centrally.
  5. Unused Applications and/or Shadow IT – Every enterprise has applications that are not used anymore because business process has changed or there is no requirement. Typical example are PDF readers. It’s common to find 5-10 different PDF readers in the install base due to some specific functionality requirements at some point in time. Another common type of applications is the one that user runs themselves without the authorization or approval of IT known as Shadow IT.
  6. End of life applications –Windows XP applications. Familiar? Enough said.

The application inventory can be retrieved from SCCM (or other tool) but for assessing how applications are used, you may need other tools like Lakeside SysTrack. Key data you want to find out are things like application sprawl, how often they are used, resource requirements and so on.

There may be applications that are listed in the SysTrack report but are not in the SCCM list. These maybe “shadow IT” where the user installs or runs applications that are not authorized or distributed by IT.

The question to always ask yourself when analyzing apps are:

  • Do you really need this application?
  • If not, do you want to keep it?
  • Is there a newer version of this app that could make things easier here? Perhaps version 1.5 doesn’t work, but version 2.0 does work?

Application Compatibility

After the previous exercise of Application Rationalization, you may be able to eliminate large chunk of applications which fall in the last 3 categories (Unused applications, end of life or redundant applications). Of the 1000 applications in our example, through standardization, we may be able eliminate 400 applications which is 40% of the application landscape if you are aggressive.

The next step is to check for the compatibility of applications on OS platforms such as Windows 10 or Windows 2012 R2 (for VMware Horizon Apps or Citrix XenApp).

Applications can be classified broadly into 2 categories:

  • Web applications
  • Windows Applications

Note: For the scope of the discussion we will leave out native mobile applications based on iOS, Android and Windows.

Web Applications

We applications typically have the following characteristics:

  • Browser supportability
    • IE version – Are applications certified on IE 11? If not what other versions?
    • Chrome/Firefox
  • Plugin requirements – Typical are Flash, Quicktime,     custom plugins
  • Java Requirements – JRE
  • Permissions (elevated privileges in some cases)

Windows Applications

Windows applications typically have the following characteristics:

  • Parity:
    • x86 – Is this application supported and function correctly on x64 OS such as Windows 10 or WS 2012 R2?
    • x64
  • OS compatibility:
    • Windows 10 or Windows 7
    • Windows 2012 R2 or Windows 2008 R2
  • Graphics requirements
    • Does this application vendor specify the use of specialized graphics hardware or is it just extra display memory and processing?
  • Platform dependencies such as Dot NET, Java and so on.
  • Permissions (elevated privileges in some cases).

There are various tools (Lakeside SysTrack, Citrix AppDNA, Dell ChangeBASE) in the market that will help do Windows 10 assessment and provide reports on application compatibility and remediation guidelines for applications. But at the end of the day you may still end up testing and validating the application on the OS platform if there is no application vendor support on that platform.

Applications that are not compatible with OS Build (Win10 or Win7 or WS 2012R2) will need to be remediated or updated to be compatible.

The point is to make sure you don’t go light on the remediation. It’s a hard step, it needs to be really discussed and discussed again. It’s a common find IT spending time and effort wrangling on an app to suit Windows 10 rather than simply switching to native web/SaaS.

Application Delivery Pilot

Once you have a list of applications that are VDI friendly, the next obvious step is to run a Pilot to test applications to validate few things:

  • Compatibility with the OS
  • Interoperability with the rest of the applications
  • Right delivery methodology for the application
  • User experience and performance

In a VMware EUC world, there are 4 ways to deliver applications:

  1. Delivered as a part of the base OS
  2. Delivered via ThinApp (Streamed or Installed)
  3. Delivered via a Layering technology as App Volumes
  4. Delivered via Horizon Apps via RDS

Each of the delivery techniques have pros and cons which are beyond the scope of this document.

At a high level, the following are the pros and cons of each of these delivery techniques.

Delivery Methodology Pros Cons
Installed on Base OS
  • Easiest to install, no packaging effort and expertise required.
  • Native user experience
  • No “overhead” to login process.
  • Updating applications is cumbersome. As applications are a part of base image, any update to the application requires an update to base image.
  • Base image sprawl. You will end up maintaining large number of base image for various user segments.
ThinApp
  • Different versions of the same application can be delivered simultaneously.
  • Applications can be updated independent of the base image.
  • Packaging experience and application knowledge required in some cases.
  • Not all applications are suitable for ThinApp
App Volumes
  • Applications can be updated independent of the base image.
  • Native user experience
  • Vastly simplifies image management.
  • Not all applications are suitable for App Volumes.
  • There is a small login time overhead.
  • Packaging experience and application knowledge required in some cases.
Horizon Apps via RDS
  • Application update process is independent of desktop base image.
  • Simplified image management as desktops and applications are hosted separately.
  • Not a native user experience as the application is not hosted in the desktop
  • Requires additional infrastructure due to the requirement to the RDS servers.
  • Applications need to be compatible to be run on WS 2012 R2 or another version of Windows RDS server.

The next step is to select applications that make a good sample set for the Pilot. This should include but not limited to the core applications, key business applications and applications that are most commonly used.

For example, you let’s say you have selected 50 applications of the remaining 600 applications. This 50 should be a good representation of the 600 so that it will help you formulate a deployment strategy. These 50 applications should be tested with App Volumes, ThinApp and RDS to gauge the most appropriate technique.

So based on factors such as technical complexity, operations and business requirements, you may formulate a strategy to arrive at what percentage of applications will be delivered through which methodology.

The following are the typical delivery considerations for VDI administrators.

  • Limit the number of base OS images
  • Able to update and manage applications independent of base images
  • Provide good user experience
  • Minimal infrastructure

The following ratios could be a “starting point” for the Pilot testing if your key objectives are the above:

Core applications such as MS Office, Lync, Google Chrome and company-wide used applications are installed in the base image. Since these are typically the most widely used applications and require best performance, this is a practice seen among customers. I ve also seen customers having base image for various functions such as “Contact center” user group where all commonly used contact center applications are delivered inside the base image.

App Volumes offer native user experience and helps bundle applications in “AppStack”. Typical use case is IT maintaining an AppStack for every department. In such a case, core applications will be delivered via base image and department applications are delivered via AppStack.

ThinApp applications can be packages and hosted in a SMB network share which can be accessed inside a virtual network. This is called ThinApp streaming. Alternatively, you can also deliver ThinApp as portable application or host in a RDS server.

Lastly, you can deliver applications via Horizon Apps by hosting applications on separate Windows RDS servers. This is especially useful for applications that are “occasionally used” where RDS session is only consumed when a user accesses it.

So, there is no “one size fits all” strategy and you will need to determine the right approach for your business during your pilot testing and validating against your business needs. The above are some guidelines with an oversimplified example.

Credits: Thank you my friend Ernest Nichols for the reviewing the draft and providing useful feedback J

Note: The above article is neither endorsed, reviewed or validated by VMware. This is purely based on my personal experience and what I see in the field.

Advertisements

One thought on “VDI Application Deployment Strategy

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s