We’re excited to have an increasing number of customers who own Citrix XenDesktop. Unfortunately, we see some of them struggle at times with the implementation of the technology and it appears that some of you take more time to provide value to your end users than you anticipated in the beginning.

The good news is that  there are some relatively simple steps you should take in the beginning of the desktop transformation initiative to minimize unforeseen roadblocks and disruptions. A couple of key things before we get started though:

  • Desktop Virtualization is NOT like server virtualization. The workloads are different, the design of the hypervisors, storage, monitoring, etc. are different. So, expect that you will need to build or acquire the right skills and knowledge in order to be successful.
  • Desktop virtualization is a transformative force. It is likely that the best organizational structure for IT will look different from what has worked thus far.
  • Don’t start with the most complex project first. Many of you have a burning desire to solve a specific problem with a specific set of users – I understand the sense of urgency, but if you’re not well equipped to deliver, it will take you forever to go live and you’ll spend a lot of time and energy on a frustrating project.


So, what would it look like if you looked at all your potential user groups, determine the business value of desktop virtualization for each group, figure out for which projects you can deliver value the fastest, and prioritize your projects accordingly?

It’s not that hard to do, and here’s how it works:

One can describe the overall project lifecycle in three main phases: Assess, Design, Deploy. I am focusing on the Assessment piece in this blog, and the technical design and testing / deployment until go-live can be handled separately.

Pitfall Alert: Under no circumstances is it advisable to move from a vendor Proof of Concept (POC) into production. A POC is there to convince you that the technology works on your network, with your apps, with your authentication, etc… it’s there to proof a specific concept to answer some of your questions and not to serve production users.

How about the assessment now? This follows the desktop transformation methodology, which Citrix Consulting introduced in late 2010.

Start by organizing business priorities. Do you know what’s a priority to IT? Do you know what’s a priority for your CIO? Do you know what’s a priority to your company? Hint: It’s not always lowering costs at the desktop.

Example: A North American oil and gas exploration company has their geophysicists at sites north of the arctic circle. The season to stand up derricks and drill is only 150 days long, so any interruption to the scientists ability to analyze samples and make recommendations for the next production sites is extremely expensive. Prior to using virtual desktops, these guys had some of these really sturdy laptops with a lot of special applications. The laptops fail frequently due to the rough conditions and each time that happens, IT had to build a new device and ship it “up there” – which takes days or weeks. This customer decided to switch to virtual desktops using blade PCs with individual GPUs and assigned users. This protects the critical applications and data in headquarters and allows them to stock the supply container with laptops containing only a basic Windows 7 image. Each time a device freezes to death now, it’s just a question of grabbing a new end-point and be back up in running in minutes. So, costs savings at the desktop was probably very low on the list of priorities, while increasing agility and enabling virtual work styles was very important here.

With the business priorities for the organization clearly documented, it’s time to have a discussion on users and their apps. Do you know which apps your users need or use? You may answer in the affirmative, but many IT departments today manage a set of owned applications and the business units and individual users procure, install, and manage a lot of their own apps. So, if you don’t know which apps are present, you have two options: Make a list together with your business managers (or conduct a survey – it can take a while to do that though) or deploy one of the agent-based (or agent-less) tools that scan each users device and report back what apps they are using. You may need to clean up the list that comes back and scrub for duplicates and remove apps you’re not willing to support. So, there is always a bit of manual work to be done.  Now, group users by a common application set – this is more art than science, although there are several tools that can do that for you. You should expect to find a common application set, but expect to have a list of individual users with individual apps they need that you’ll need to treat as an exception.

Now, look at each of the user groups you have thus far and answer the following questions:

  • Can they all be served out of the same datacenter – based on their primary location? If not, split the user group appropriately.
  • What are their mobility requirements? Hint: In most cases, expect to be mobile, but online, all of the time. The exceptions of the PC era are the new assumptions in this cloud era.  If you have users who need to work entirely  offline, break them out into a separate user group.
  • What is their risk tolerance? In other words, how much would your overall business suffer if these users were unable to connect to their apps and data? For most “office” users, this would be a nuisance, but for others even short outages are unacceptable (clinical staff, stock traders, our geophysicists example above, etc.). Separate the user who can’t stomach even short outages. The reason is that the infrastructure to serve those users need additional redundancy.
  • Lastly, will the users new endpoint support their requirements? Most of the time, that’s the case. I talked to one customer once who bought a  large quantity of inexpensive thin clients and then decided to deliver graphically intensive applications that require HDX flash and 3d acceleration, which these endpoints could not deliver.


So, by now, you should  have a good handful of user groups. All of the users contained in a single group should be served by the same technology.

The next step is to determine the high level virtual desktop model for each user group. Looking back at your business priorities can help here. For example, if costs savings at the desktop are high on your list, consider hosted shared desktops. Choosing this model may require you to venture into server based computing and get your apps up and running, but the per desktop cost is probably lower than doing individually assigned VDI desktops. On the flip side, if you need to provide value quickly, don’t worry about per desktop costs too much and are familiar with desktop management, you may choose individually assigned VDI desktops. Supporting  executive mobility initiatives is a good example of such a case.

Note: You may end up identifying multiple FlexCast models per user group. Maybe you deliver the majority of apps in a Windows 7 pooled VDI model and deliver a handful of sparsely used apps with XenApp Apps on demand.  For the user groups requiring mobility, add Access Gateway; for those requiring high uptimes, consider redundant data centers, etc. Don’t worry about a detailed design at this point, but make sure you get a feeling of the technical complexity for each user group.

Now it’s time to tie it all together and ask yourself for each user group:

  • How well does the groups desktop virtualization align with my business priorities? In the example of the Geophysicists for our oil and gas company, the answer was “very well / high importance” while a set of back office users in headquarter only scored a “medium” rating in this category.
  • How much time will it take me to implement everything I need for this group? This answer is largely dependent on the overall complexity of the user group (the smaller the number of apps, the less complexity in most cases) and your familiarity with the required technologies. The less experience you have here, the longer it will take you to deliver the value to that group. Unless, you have the budget to get someone to help you.


One way to tie it all together that has been proven pretty effective, is to place each user group on a 2 dimensional chart. Business value on the vertical axis and time to value on the horizontal axis. Your high impact, fast time to value projects will be at the top left of the graph. That’s where you should start… the projects towards the right or towards the lower portion of the graph will take longer or are not that important.

I’ve spent the better part of the last decade in software related professional services and it is amazing to me (while not surprising) how much more successful customers are who conduct this initial assessment as compared to those who just get started and make it up along the way. The good news is – it’s not that hard.

Citrix customers and partner are strongly encouraged to check out the desktop transformation accelerator, which is THE tool to guide you through this entire process and through the design and deploy phases. Whether you do this on your own, with a Citrix partners, or Citrix consulting, the methodology should always be the same and follow the steps outlined above.

Here are some additional goodies for you:

The XenDesktop design handbook: http://bit.ly/xdhandbook

The collected wisdom of Citrix Consulting. Blogs, tweets, white papers, articles, and more.

And… of course… the desktop transformation accelerator.

As always – please share your thoughts and comments.

Florian Becker

Director, Worldwide Consulting Solutions at Citrix

Twitter: @florianbecker