Tag Archives: desktop virtualization

Just the Apps

We get so excited with the thought of VDI, we often forget to take a step back and focus on what we are trying to do. Here is a recent example…

We need to find a way to get an application to our users. Our first problem is that many of our users are not local, which makes installation a challenge. The second problem is that many users want to use the application on non-traditional devices (tablets) because it is more convenient. We’ve heard that VDI can help us with this. What will it take?

First, this is a good question, but unfortunately, the person has already decided on a solution without understanding what is possible. I can’t blame the person for already believing that VDI is the right answer because the marketing teams that are focused on VDI have done a great job blanketing us with the VDI message. And unless you are knowledgeable about the functionality with different products, you might miss the nuances and buy something you weren’t expecting.

If I were to make a recommendation with this particular customer, I would steer them to XenDesktop 7 App Edition (for those of us who have been around for some time, I’m referring to XenApp), which basically delivers an application to a user instead of the entire desktop. This solution aligns closely with what the user needs.

But what will it take for 500 users? Not much… just three physical servers using two Intel Xeon E5-2690 @2.9GHz with 192 GB of RAM.

Of course many will think this is all theoretical. But to prove this isn’t simply fairytales and unicorns, we built, tested and validated this Design guide to mobilize windows apps in the Citrix Solutions Lab (I will provide more gory details in a future blog).

When we go through the numbers and incorporate it into our 5-layer conceptual model, we get the following (Read about the XenDesktop 7 blueprint to better understand the 5-layer architecture).

This solution gets you the following:

  1. Delivery of almost any Windows-based application to any endpoint to any location without requiring the application to be rewritten for the numerous types of endpoint device types and form factors.
  2. Traffic is protected within SSL as it crosses over public network connections with NetScaler Gateway
  3. An environment, capable of supporting 500 concurrent users, with only 21 virtual servers (Note that VDI would require over 500 virtual machines).
  4. Most importantly, the entire environment is using standard local storage. There is nothing special about the local storage as each physical server includes (8) 300GB SAS drives spinning at 15,000 RPMs configured with RAID 10.

Of course this is just conceptual, so what does the physical architecture look like?

  • 3 physical servers required to support 500 users, with each RDS host supporting roughly 50 users. If more users are required, another server is added resembling the “Server 3” config. We don’t have to worry about scaling the Access and Control layer components for some time as they have low utilization.
  • Three different VLANs for DMZ, VM, and Management traffic. I know some of you will point out the risk with putting the NetScaler Gateway VPX on internal servers and having the VLAN for that VM go to the DMZ. Depending on the size and complexity of your infrastructure, this might be a non-issue as long as you have the proper configuration and lockdown procedures.
  • Access Layer and Control Layer configured with N+1 availability in that if one component fails, a secondary component is available to take over the load.

When trying to decide what to do in your own environment, remember to look before you leap.

If you want to read the entire design, check out the Design guide to mobilize windows apps

Daniel – Lead Architect


Begin your XenDesktop blueprint with your users

The users matter first.

This is why we have a blueprint for XenDesktop 7 because we want to avoid starting wrong. We want to make sure that the first thing we focus on are the users.

Think about it this way, when building a house, one of the first things you have to figure out is what type of a house do you want/need (bungalow, cottage, mansion, split level, etc). Sometimes, you might determine that you don’t need a house and end up with a condo or apartment. To make this decision, you have to look at yourself and understand your needs (how much space, size of yard, number of bedrooms, etc). When defining your needs, you must not only look at today, but also look at what you anticipate the future to hold, because most of us don’t want to move houses every year.

The exact same thing takes place with a virtual desktop solution… Figuring out what type of resources you need (notice that I didn’t say “what type of desktop you need” because not everyone requires a desktop just like not everyone needs a house).

With so many housing options, many times people get stuck in simply trying to figure out what kind of house they need, or they come up with 3-4 options and can’t make that final decision. Again, the same thing happens with desktop virtualization, do I need a non-persistent, persistent or applications.

The thing we tried to accomplish with the blueprint is to provide a starting place based on numerous successful implementations. For example, what if an organization was trying to better protect information through centralization for 3 user groups with the following characteristics:

Call center users focused on getting through a large call volume as quickly as possible with as few distractions as possible.

Engineers who need to do a lot of trial and error and are often looking for alternatives to their current tools that aren’t optimal

Road warriors who are always on the go and sporadically need to enter or review a piece of information contained within a small number of applications.

Based on this scenario, we can start to create our conceptual architecture based on the framework we defined in the earlier blog.

Simply understanding your user’s high-level requirements and the overall goal of the organization helps us to start creating our conceptual architecture. Based on these three user groups, we have the following:

  • Because we want to centralize our data, we are looking at a hosted model for our three user groups:
    • Road Warriors -> On-Demand Apps
    • Call Center -> Shared (non-persistent model)
    • Engineers -> Personal (persistent model)
  • We also know that the users will need to be presented with their resources, which is provided by StoreFront. Although we know we will need StoreFront, we don’t know the details of it yet, which is better defined in the Access and Control layers.
  • Because we have these types of resources, we know this requires us to have delivery controller and infrastructure controllers. But we don’t know the details of these yet until we reach the Control layer of the design.

Stay tuned for the Access Layer…
Daniel – Lead Architect

What are you good at?

I just got back from visiting friends who live about 2-3 hours away. Every time I take this trip, I decide if I will take the interstate or local highways. The interstate gets me there faster, but it is usually more stressful due to the number of people. Even though the interstate is faster, it feels longer as the road is straight and boring while the highway is more fun to drive.

This is the same problem that plagues desktop virtualization.

For those of you who were there in person or watched online, I got the change to host GeekSpeak Tonight at Citrix Synergy 2013. The topic… Desktop Virtualization (big surprise :))

I wanted to make this session different than GeekSpeak Tonight from previous years. I wanted people to walk away with a set of guidelines on how to achieve success with desktop virtualization. I wanted everyone to come away with a plan for how they should move forward with their own solution. I had a great cast of experts on the panel. I had a list of questions that should be easy to answer. I was all set. And then, something else happened.

No one could agree. No matter what topic I brought up, there room was split down the middle. If I asked if the glass was half full or half empty, I would get part of the room to say half-full, the other part to say half-empty, and then the true geeks of the room would say the glass is completely full as it is 1/2 full of water and 1/2 full of air. This was not what I wanted.

The problem with desktop virtualization is choice.

  • Do I manage my virtual desktop like a traditional desktop or do I manage it differently?
  • Do I use persistent or non-persistent desktops?
  • Do I let users install applications?
  • Do I …

The list goes on and on and on.

How do you answer these questions? You have to answer them or else you will never go anywhere or do anything.

Before we can have a productive discussion that comes to a result, we need to have the same perspective. Why am I doing desktop virtualization (The “Why” of the project might change for each user group.)? What do I excel at?

  • If I have a good desktop management system in place, why do I want to change that? Why not use these same techniques for the new environment?
  • If my concept of desktop management is to give new employees a new end point and walk away (and this process works), why would I change?
  • If I have a locked-down desktop environment, why do I want to change that? I’ll have to completely rethink the way I manage, support and secure the desktop and it might go against company policy.

You can be average at a lot of things, or great at a few things. Use your strengths to help you develop your solution.

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

The importance of user personalization within your virtual desktop

I just got off the phone with Citrix helpdesk because I finally messed up my virtual desktop. I have a dedicated virtual desktop and I guess I installed/uninstalled too many things over the past few years. The same thing always happened to me with a traditional desktop. The good thing is that it only took the helpdesk a few moments to reset my virtual desktop to a base image and I didn’t have to sit and install Windows 7 and Office for the 100th time.

This experience got me to the next question from Project Accelerator: The importance of personalization.

We all know what personalization is. What rights you, as a user, have in altering the initial state of the desktop/application environment. Can you change a setting in an app? Can you install apps? Can you change OS-level settings? Can you even change the background (seriously???)

Why does personalization matter? We need to align the technical solution with the user requirements. In Project Accelerator, we break this down into three levels:

  1. No personalization: User cannot modify any desktop or app setting (similar to a kiosk)
  2. Basic personalization: User can modify user-level settings within desktops and apps
  3. Complete personalization: User can make any change, including installing applications

Easy, just pick the one most appropriate for your users group. Let’s think hard about this because if you get this wrong, your users will be ready to revolt. Imagine you gave a user a pooled desktop. They installed an app. The next day, the app is gone. User thinks this is strange. Maybe I was under severe medications yesterday and I only imagined myself installing the app. So they do it again. Bam, next day, the app is gone. Now they start to get angry and they let you know about it.

This scenario plays out all the time. If you assess your users, you should understand what level of personalization they require. The “No Personalization” item is usually the easiest to identify as these users typcially make up a very specific use case.  However, we often get into the debate between Basic and Complete.   I say when in doubt, go with complete. Your users will be happier in the long term, which will probably make you happier as well.

As you can imagine, this one decision plays a big role in determining what kind of virtual desktop the user gets, but it does more than that. This one question influences:

  • FlexCast: what type of virtual desktop the user receives
  • Deployment order of your user group
  • Which folders to redirect
  • What type of profile to use
  • What type of XenClient image to use
  • XenClient backup storage requirements

Choose wisely.

Daniel – Lead Architect

An Architect’s Guide to Desktop Virtualization

What does it take to be a desktop virtualization architect?

Being able to say “It depends” in twelve different languages is a great start.

  • English (American): It depends
  • English (Australian): It depends
  • English (British): It depends
  • English (Canadian): It depends
  • German: je nachdem
  • Spanish: eso depende
  • French: elle dépend
  • Dutch: het hangt ervan
  • Italian: dipende
  • Swahilli: inategemea
  • Chinese: 视情况而定
  • Japanese: それは場合による

Translations courtesy of Google Translator. For all I know, I just said “My hovercraft is full of eels” in many different languages. 

Seriously, the reason why an architect says “It depends” so much is because we don’t have enough information to make the best decision, or even an educated guess. To put simply, it depends on the circumstances. Unfortunately, “It depends” isn’t the answer; it is the start of a longer discussion meant to uncover the underlying challenges and goals. And because a true desktop virtualization solution can take on so many different forms, the time to develop the skills as an architect can be quite long.

How do we shorten this timeframe? It starts with gaining an understanding of the information one needs to gather, how that information goes into defining user groups and virtualization models and identifying/selecting the appropriate design decisions.

This is a huge undertaking, and one we are excited to take on. As you might have seen, we recently released the Citrix Virtual Desktop Handbook, which grew out of the successful Citrix XenDesktop Handbook (we are creative with names ). We wanted to focus on more than XenDesktop because desktop virtualization is so much more than VDI. We want to create an all-encompassing guide for an architect.

Version 1 of the handbook focuses on the Assess phase, which identifies what you need to know and do to successfully start your project. This is only the start. We are getting close to releasing version 2, which will include portions of the design section (this is the part that excites most architects).

If you haven’t already, download the handbook, find a comfy chair, and let us know what you think of the initial release.

Stay tuned for more

Daniel – Lead Architect

Project Accelerator Question 1 – Technical Skillsets

One of the first questions that Project Accelerator asks you is what technical skillset you current have, with a list of about 20 different technologies.  Why do we care?

Let’s say you have App-V experience, then when you get to the application delivery portion, we will probably recommend you use App-V for a subset of applications.

They same can be said for hypervisors as well. We might recommend vSphere or Hyper-V instead of XenServer for your deployment.  I can hear Citrix people saying “Are you kidding me?”, but it is true. The most important goal is to make you successful. Unfortunately, with all of the new technology you have to learn, the time before you can achieve success might be pretty far away.  If we can shorten that learning curve and rely upon your skills you already have, we can speed up a deployment and bring success closer.  So if you already have the technical prowess of Hyper-V in your environment, then we will recommend it instead of suggesting you learn a whole new technology. Of course cost of the technology is another factor, but that is a decision you will have to make for yourself. So if you have vSphere skills, but the cost of the solution is much greater than XenServer, you will have the ability to modify the hypervisor when the “customize your design” portion gets released.

Try it for yourself. If you select Hyper-V for your technical skillset, the architecture diagram will show clusters. XenServer will talk about Pools. vSphere will talk about clusters as well as vCenter servers.

The technical skillset question does more than recommending a hypervisor.  It also plays a big part in determining which user group should be deployed first, second, third, etc.  It’s funny, many people start a project by focusing on the most complex use case first.  Not only are you trying to deal with a difficult scenario, but you are also trying to learn a new set of technologies.  A better approach is to focus on the easiest use cases first. Those use cases where you already have skills.  So again, we use the technical skillset, plus a few other items, to help us make a deployment order recommendation.  Let’s say I have skills with XenApp and I have 3 user groups with the following FlexCast models:

  • XenDesktop users
  • XenApp users
  • XenClient users

Who goes first?

Based on this scenario, the XenApp user group moves to the top of the deployment order because that user group should be easier to deploy as I already know XenApp. Of course the deployment order recommendation is more complex than that, but this is a topic for another blog.

If you want to see these things for yourself, go ahead and take Project Accelerator for a spin.

Daniel Feller – Lead Architect

Citrix Virtual Desktop Handbook – The Architect’s Guide to Desktop Virtualization

Project Accelerator