Stories from the Front: Things That Go “Bump” in Desktop Virtualization Projects

Grace Krokidas (Profile)
Friday, March 30th 2012

Or, "Why You Need a Solution Like Stratusphere UX to Diagnose and Solve VDI Problems"

At Liquidware Labs, we have the privilege of being able to talk to customers about their real-world implementations, and it always gets the most interesting when they move into production. First, let me explain why it gets “the most interesting” after customers move into production. What we’re learning is, that while a lot of companies do start out with an assessment of their physical environment and users, probably just as many don’t. They proceed with recommendations or reference architectures from their preferred vendors. They successfully go through a pilot with a control group of users. They roll out to production confidently and everything is great – for a while, maybe even a long while. But then, things change...

For example, management wants virtual desktops to support more users for better ROI. Application patches or upgrades happen. Or everyone needs to migrate to a new something, something because the old one is being retired. Or your company acquires a new company and guess what? You need to migrate all the new employees to virtual desktops, and they all need to work remotely.

Believe it or not, the hardest part of rolling out virtual desktops is not the early stages… it’s the subsequent stages when you find you are either dealing with the unexpected or have to plan for change. This is what happened to the following customers, and if any of this scenarios sound familiar to you, there’s hope, because we have a solution – Stratusphere UX – for what ails your virtual desktops. So, presenting six  “stories from the front”  where things did not go as planned...

How Many Monitors Are Too Many Monitors?

One company built out its virtual desktop environment based on vendor recommendations. However, a practice at the company was to routinely equip their power users with dual high-resolution monitors, which was not factored in the infrastructure design. Almost immediately, performance problems surfaced. Using Stratusphere UX, it was determined that the company had not taken into account the extra load on the infrastructure that multiple high resolution monitors would impose via the display protocol.

Misbehaving Applications

A financial services company ported one of their proprietary apps to the virtual platform. The application kept “breaking,” and all problems were attributed to the new platform, but no one could describe exactly why this was so. The company used Stratusphere UX to get a detailed look at how the application was working on virtual servers. What they discovered was that the application itself was the culprit – not the platform. The application had been “breaking “on physical servers, but users just figured out “work-arounds” and stopped complaining. Once the company saw this, the app went back to development for optimization on the virtual platform and things have been great.

Modeling Change

An insurance company needed to determine the impact of adding a data-loss-prevention (DLP) application to the virtual environment. Having had consequences from introducing apps without due diligence before, they decided to use Stratusphere UX to perform an analysis of the effects on performance, capacity and the resultant cost of deploying the solution. They successfully modeled the repercussions of adding the app and learned what adjustments were needed to compensate for the change before implementing it in production. In this case, they could add storage, balance workloads or re-engineer the application. They decided to ask the vendor to re-engineer the application for the virtual platform, which the vendor agreed to, and they are working it out.