Planning and Designing VDI Use Cases

When planning a VDI deployment, we all know that it’s important to define your use cases.  VMware’s methodology defines three main categories for these use cases: Task Worker, Knowledge Worker and Power User.  I see a lot of confusion in the field though – these are not use cases themselves.  I have yet to find an organization that can neatly divide their workforce into three use cases.  Instead, those categories are really just shorthand to allow us to roughly describe the resources that are required by the use case.

Most environments will have several Task Worker use cases.  There might be a Call Center Task Worker use case, a Data Entry Clerk Task Worker use case and a Secretary Task Worker use case, all within the same organization.  This is perfectly normal, as “Task Worker” really means that the use case employs a very limited set of applications and does not require many resources.  So, how do you actually define a use case then?

A use case is defined by job function, not by resource requirements.  What tools does this position require in order to perform its function?  Or, put more plainly, what applications does this person use when they do their job?  The Call Center staff, Secretary, and Data Entry Clerk might all be Task Workers, but they are going to need different applications in order to perform their jobs.  In fact, depending on the organization, there might be several different use cases within each of those business units, as different call center positions might require different tools.

So, how do you discover these use cases?  Well, since you’re undoubtedly part of a highly organized business with a sophisticated application deployment tool, you can just pull up a report that reveals what applications every employee needs in order to do their job.  If that describes you (and ask yourself, does it really describe 100% of your software, really?), congratulations, you’re done!  For the rest of us, we’ve got some discovery to do.

Fortunately, there are tools that can help us out with this process.  There are two discovery tools that I have used: Stratusphere Fit and MAP.  They will turn up slightly different information, and both of them can be frustratingly possessive of their data at times, but both can be used to get what you need (although you may have to make a few manual SQL queries to their databases to get it).

Stratusphere Fit audits the user experience on the desktop, including what applications are launched and how they perform.  This is my preferred tool, as it can be used to establish performance baselines for the physical desktops.  That function is pretty important, as it gives us absolute metrics that we can use to define success for the virtual desktops.  If you poke around in their “Preview” section, you can generate a report that lists every application launched on every desktop.  This will be very big… as in 27k lines for a 500 user audit… but it’ll get you a working set of data to begin analyzing.

MAP is another tool that can pull up a desktop:application inventory.  I’ve only used it in the lab (we’re Liquidware Labs partners and so I’m lucky enough to always have Stratusphere available), but it queries every desktop for installed applications.  You can use this data in the same way, although you’ll have to query the SQL server directly to pull up the report.

The big difference (besides cost) between the two solutions is the applications that each one reports.  Stratusphere reports launched applications, whereas MAP reports installed applications.  This means that MAP will give you everything on the desktop, whether it is being used or not.  This can lead to false positives as it preserves any applications that were unintentionally deployed to a user (say, when an executive with Visio got a new PC and their old one was repurposed for their Secretary who doesn’t need Visio but still has it because the PC was never imaged).  Stratusphere only catches applications that are actually run, although this means that it needs a long monitoring period in order to ensure that it catches all of the applications involved in a full business cycle.

So, regardless of the tool that you use, you now have a user:application mapping.  Here is where your data crunching expertise comes to the forefront (I’ve written some PowerShell scripts to help me with the process).  You get to determine how many use cases (application sets) exist within the environment and what users fall into what use case.  Only when those use cases are defined and have been populated with users can you really start migrating to VDI.