Are you using desktop virtualization to strong-arm users ?

Do you really know why you are doing desktop virtualization? As with most technical solutions, desktop virtualization has its place. It can enable flexibility, mobility, and a bunch of other “-ility” words. Unfortunately, I’ve seen people try to use a technical solution with the wrong goals. Take the following, which is a common occurrence:

I have a distributed desktop environment. Over the years, my users have installed whatever they wanted on their endpoints. We end up having to rebuild these devices constantly as they continue to slow down. With desktop virtualization, I can…

For this organization, why would you do desktop virtualization? Think about it before you continue reading.

Is your answer “to lock down the desktops and prevent users from installing anything they want?” To many, this sounds pretty good, desktop virtualization will allow us to lock down the environment. With a locked down environment, users can’t install their own applications, they can’t make changes to the environment, and IT won’t have to spend time troubleshooting/rebuilding desktops.

When I look at this challenge, I come to a different goal. For whatever reason, users have been giving the freedom to have complete personalization. They have this capability and expect it to continue. Why would we change the overall expectations of the entire user community? Changing it so they are forced into a standardized desktop environment might sound good as it “will” make IT’s job easier, but users will be unhappy with the new solution. Most technology solutions require user support; without that support, the project will eventually collapse. The goal of the project isn’t to put the users into a standardized desktop environment; instead, the priority for this organization is “better desktop agility” or “faster desktop support services”. With desktop virtualization, IT can still provide users with a completely personalized computing environment while providing better and faster desktop support. A user can get a brand new/clean desktop in a matter of seconds instead of hours or days.

So why does this matter? Because it impacts one of the first design decisions: FlexCast.

The “locked down” path will eventually lead me to Shared desktops; the “better desktop agility” path will lead me to Personal desktops with the PvD option.

When looking at your priorities, make sure you fully understand the core priority.

Daniel – Lead Architect

Project Accelerator
Citrix Virtual Desktop Handbook


Virtual desktop design – The right approach

One of the first questions someone doing desktop virtualization wants answered is usually one of the following questions

  • How many servers do I need?
  • How many IOPS?
  • How many XenDesktop Controllers do I need?

I’ve seen it many times and have been asked these questions many times. The typical answer is “It depends” (I really hate this answer BTW). The wrong answer is any number (You don’t have enough information). A more accurate answer is “Let’s solve for X, where X is the number of servers” (Pretty much the same thing as “It depends”, but we didn’t have to say “It depends”.)

So in order to start solving for X, we need to ask a wide range of questions around the user’s usage requirements, location, personalization, hypervisor, hardware specifications, etc. The list can be quite long if you want a realistic and accurate answer. The problem with this approach, which is the same approach I’ve seen many people take, is that


The number of servers, number of IOPS, number of XenDesktop controllers are some of the LAST design decisions you should answer. Before you can answer this, you need to understand the user’s endpoints, you need to figure out how the users will access the environment and you need to understand what form user’s virtual desktop will take.

The right way to do a virtual desktop design is to follow the 5-layer model:

  1. User Layer: Focus on the decisions that impact the users directly: endpoints, receiver, etc. Should be done for each user group.
  2. Access Layer: What types of authentication, encryption and bandwidth does each user group require? Should be done for each user group.
  3. Desktop Layer: What does the user’s virtual desktop look like? OS, Apps, profiles, policies, printing, etc. Should be done for each user group.
  4. Control Layer: What and how many infrastructure components are required (Access Gateway, StoreFront, XenDesktop/XenApp controllers, Provisioning Servers, etc). Should be done for each data center.
  5. Hardware Layer: How much physical hardware is required, which includes number of servers, total storage space requirements, total IOPS requirements, number of virtual machines, etc. Should be done for each data center.

When you use Project Accelerator, you see this 5-layer model depicted in the architecture diagram.

When you look at the NEWLY updated Virtual Desktop Handbook, you see the design phase following the same flow as well as many of the different design decisions you should answer.

I encourage you to take a look at both. And notice that the latest additions to the Virtual Desktop Handbook go into more details for many of the appropriate design decisions within these layers.

Stay tuned for more, as we are working on additional updates to the handbook.

Daniel – Lead Architect

Project Accelerator
Citrix Virtual Desktop Handbook