Ok, tell me if you've heard this one before? How big can my XenDesktop farm be? The response is "It depends. . . Blah, blah, blah"

I've had many people ask me this exact question. I don't like saying "it depends", but it really does.  But how can anyone design their XenDesktop environment with an "It Depends" answer?  Well, the answer to that is It Depends Enough joking around. Let's take a look at XenDesktop and understand what goes into approximating the size of the farm.

The one component that will have the greatest impact on the size of a XenDesktop farm is the XenDesktop controller. The Controller is used to:

1. Maintain proper level of idle desktops (in hosted VM-based model)
2. Monitor the state of virtual desktops (idle, online, offline, in use, etc) for hosted VM-based VDI and hosted Blade PCs.
3. Authenticate users
4. Enumerate virtual desktops for the user
5. Connect a user to their appropriate virtual desktop
   

Now that we know the determining factor is the controller, one would think that it would be easy to figure out the max size of the farm.  One thing we need to completely understand is that there is no number at which point the XenDesktop farm will simply stop functioning.  There is no defined limit.  The limit is defined based on the environment like:

1. XenDesktop Controller Architecture: Is the XenDesktop Controller implemented as a single server or are the functions split across multiple controllers?
2. Logon storm: How fast and long will users logon during the start of a shift or a workday. I discussed this in a previous blog.
3. Logon Latency Acceptance: How long will a user accept their long time being?  10 seconds? 20 seconds? 60 seconds?
   

Controller Architecture

Looking at different implementation examples, I know that one will get the best logon speeds and farm sizes by separating out functionality within the controller.  For the large XenDesktop implementations, we recommend 3 controllers:

1. Master: Responsible for idle desktops and connecting users to a desktop
2. Brokers (x2): responsible for authentication, enumeration and virtual desktop state monitoring
   

By separating out theses loads, I've seen farms scale over 5000 hosted VM-Based desktops. Read about this architecture in the Modular Reference Architecture for XenDesktop.

Logon Storm

Like I stated earlier, the logon storm will have an impact on the environment.  During a storm, users will authenticate, enumerate, and connect to their desktop. For each connection that is made, a new idle desktop must take the place of previously idle desktop.  As you can see, by separating the XenDesktop Controller functionality across multiple systems, the logon storm's impact is spread across multiple systems, thus helping to negate the impact. The impact of the storm is explained in the blog How User Patterns Impact a Desktop Virtualization Infrastructure

Logon Latency

How long are you willing to wait for a logon to complete?  As the number of users connecting during a logon storm increases, the logon latency will also slowly increase. At some point, the logon latency will become too great for users to accept.  At that time, it is often appropriate to start distributing your load across multiple XenDesktop farms.

OK, OK, Just give me the answer!!!

So how big can my XenDesktop farm be?  2,000-20,000 users. 

1. Smaller: If I don't separate out my controller functionality, and have thousands of users connecting within a short duration, and expect sub-10 second logon times, my farm size will be limited in size
2. Larger: If I separate out my controller functionality, have tens of thousands of users connecting over 1 hour,  and my users will accept 20-40 second logon times
   

When you are asked about how large can your XenDesktop farm be, you need to ask a few questions before you can give an educated guess:

1. Will we be able to separate out our controller functionality?
2. How many users do you expect to login within a 10 minute period?
3. How long will users accept their logon times becoming?
   

I've seen logon rates of 2,000 users in 10 minutes, with separated controller functionality and 20-30 second logon times occurring in XenDesktop farms of 5,000-6,000 users. 

I hope this helps shed some light on how big is too big for your virtual desktop infrastructure.

Daniel

Lead Architect - Worldwide Consulting Solutions
Follow Me on twitter: @djfeller
Blog for Next-Gen Desktop: Ask The Architect
Questions, then email Ask The Architect
Facebook Friends: Ask The Architect

I just read Alessandro's article asking "Is there any real need for application virtualization?"  I say most definitely YES, especially when talking about desktop virtualization!  When I talk about application delivery in conjunction with desktop virtualization, I always refer to three ways of integrating applications into the desktop:

• Install
• Host
• Stream
  

Streaming is what Alessandro means when he talks application virtualization.  Is application virtualization required in every virtual desktop implementation? No.  Have I seen customer successfully use application virtualization for their applications? Yes.  When is it best to use application virtualization?  Not a simple yes or no question, but here is when I typically recommend and don't recommend its use.

Scenario 1: Almost all of an organization's applications, to be delivered in a virtual desktop, are used by 100% of the users.  There are only a few applications that are specific to certain user groups.  In this instance I typically recommend forgoing the use of application virtualization.  If I created a virtual desktop image for each unique configuration, I would end up with a fairly small number of desktop images due to the similarities between all groups.  It would probably end up creating more work to setup an application virtualization solution for this type of environment.

Scenario 2: There is a wide disparity of applications between different groups of users.  Creating desktop images based on these differences would result in 25+ images, each of which must be maintained individually, which will take quite a bit of time.  I would be better off separating out the unique applications and finding another way of delivering them to the virtual desktop either via streaming or hosting on XenApp. 

Scenario 3: Users who travel with laptops need to have locally available applications.  Are these users computer savvy and able to install and maintain their own applications?  Maybe, maybe not.  If they are not, you really don't want them to install their own line-of-business applications. You want those applications delivered to them. And because they are mobile users, they need to have these in an offline fashion.  This is a place where I would suggest using application virtualization. In fact, if you have an environment with mobile users and virtual desktop users, you can use the same application profile, which simplifies maintenance even more.

I've seen quite a bit of success with application virtualization. In fact, I know of a few customers who are streaming large application like SAP.  To be honest, I am also receiving most of my apps to my laptop as virtualized applications via Dazzle. 

Unfortunately, the application virtualization solution is not an end-all-be-all solution yet. In fact, because of technological limitations in the current versions, you will be hindered by the types of applications you can virtualize (services, ODBC configurations, etc). 

The main thing to remember is that you must have flexibility if you are going to do your desktop virtualization designs correctly.  Forcing every user into the same environment without the ability to customize is not something I would accept, and neither would other users.

The big question you have to ask yourself is for typical organizations that have thousands of applications, how would you deliver a virtual desktop and applications to the users? Hundreds of desktop images or one desktop image with one application package per application? 

Daniel

Lead Architect - Worldwide Consulting Solutions
Follow Me on twitter: @djfeller
Blog for Next-Gen Desktop: Ask The Architect
Questions, then email Ask The Architect
Facebook Friends: Ask The Architect

Have you experienced this before?  You need an application to help you with a project. You ask your manager if you can purchase the software and you get approval.  You go out and buy the software and install it onto your desktop and away you go to do your job. 

This is a common situation, one I've done myself on many occasions.  These applications make up the non-IT delivered application set of every organization, and it is a massive list.  This happens over and over again in every organization and in every department.  So when you hear organizations say they have 10,000 or 20,000 applications, they are likely not exaggerating.  Out of that massive list, only 500-1,000 of those applications are IT-managed. 

This brings about the main challenge with desktop virtualization, how do you deal with the non-IT delivered applications?  WithXenDesktop, if you use the recommended strategy of a single image for many users you lose the ability to install the application into the virtual desktop and have it persist across reboots.   This is a major issue that must be dealt with or users will not accept the virtual desktop.  

First, you need an application assessment. You have a few options. # Entire site assessment: By using a tool or doing a manual assessment you can get a list of applications deployed throughout the organization.  This will give you the data points, but the amount of data might be overwhelming. Imagine looking at a list of 20,000 applications. How do you even start determining your optimal solution.  This is information overload

1. Department-by-Department assessment: By focusing at the departmental level, you get a better grasp of the applications without being overwhelmed from the start.  .  If you focus at a departmental or group level, your application list should be more manageable. 
2. Survey: Leave it up to the departments to create a list of what their users NEED to effectively do their job and not what they HAVE.  Many of the applications are outdated and unused.  By identifying what is needed, the number of applications can be better managed. 
   

Regardless of the approach taken, the following is needed for each application:# User

1. Application
2. Dependencies
3. Mobility requirements
   

Second, it's time for layoffs but this time we need to layoff applications.  If you ask your users what applications they have installed, they will miss most of them.  In fact, many of the applications installed on a typical desktop are not needed anymore.  By laying off applications, we can start to get control of our application set and give our IT organizations an opportunity to succeed.  

Third, develop an application delivery strategy.  We can either install, host or stream.  Do you need all three? Potentially.  The point to remember is you need to be flexible. Certain strategies will work better in certain situations.   Think about it this way. # Certain applications will be used by 100% of your users.  These applications are best served by installing into the virtual desktop image. Why add another process (streaming/hosting) for an application that will be used by everyone, everyday?

1. Certain applications have such a massive memory footprint. Executing the application within a virtual desktop will result in massive amounts of RAM being consumed.  However, if that application were hosted on XenApp, those DLLs and EXEs could be shared between users, thus reducing the overall memory footprint required.
2. Certain applications are used by a small group of users (1-2% of users).  These applications might best be served via the hosting model on XenApp or via application streaming into the virtual desktop. 
3. Certain applications go through constant updates (daily/weekly).  It would appear to be easier to use a single application image that can be distributed to any device when needed. Instead of maintaining hundreds/thousands of installations, the single package model would appear to be easier. 
   

The point of all of this is if you going to be successful, you must have a strategy for delivering the applications into the virtual desktop.  The strategy is also dependent on how well your IT group can service the user requests for all of these applications.  If it is just not possible, your other alternative is to go down the Bring Your Own Computer (BYOC) route. 

In the BYOC model, my physical desktop is maintained and managed by myself.  I'm not part of the domain nor do I call support when I have an issue, I do it myself.  This also means that the non-IT delivered applications are installed on my own personal desktop.  So far, this model has worked for me but I'm a savvy user and know how to fix a lot of issues I run into to. This approach might be more difficult for those not used to self-supporting.  But if a user installed their own applications, then technically they are already self-supporting their non-IT delivered applications.

Remember, the desktop is the easy part.  Spend your time looking at your application set and remember the following:

1. Application Assessment
2. Application Layoffs
3. Application Delivery Strategy
   

What other application characteristics have you seen that would help determine your application delivery strategy? 
Daniel

Lead Architect - Worldwide Consulting Solutions
Follow Me on twitter: @djfeller
Blog for Next-Gen Desktop: Ask The Architect
Questions, then email Ask The Architect
Facebook Friends: Ask The Architect

By now, many of you have seen posts and recommendations to attend Citrix Synergy on May 12-14 in San Francisco.  I know that I'll be there because I'm presenting on a few different topics.  For those of you who follow me on Twitter (@djfeller), you have already seen me tweet about the upcoming Synergy session.  I've also done the same thing on Facebook.
 
Instead of standing up on stage in front of a packed room telling you what I think you want to know, I've decided to change things around a bit. This time...

You heard it right.  The decision is up to YOU.  There are a whole slew of items I could spend 90 minutes on, but I might not pick the ones you are most interested in.  So you tell me what you want to here. So far, I've received the following via Twitter and Facebook: 

• Applications
  • Best approach for gathering information about the application set
  • Do I really need XenApp as part of my XenDesktop architecture
• Virtual desktop:
  • Recommendations for how to optimize the desktop image (XP or Windows 7)
  • IO figures for Windows 7 and Windows XP
• Hypervisor
  • What impact does XenServer, Hyper-V and vSphere have on the XenDesktop design
  • Why is XenServer a better platform
• OS Delivery
  • How to calculate the storage requirements for the server-side and VM-side
  • Best practice recommendations for write cache and persistent storage

 
There you have it, the current list of suggestions as of January 21st, 2010.  I know you have many more ideas, so let's her them.  Either comment on the blog, tweet me on Twitter, or post on my Facebook page.
 
If I don't have enough topics, I might have to do something really drastic, like present from a Marketing PowerPoint slide deck
 
Daniel

Lead Architect - Worldwide Consulting Solutions
Follow Me on twitter: @djfeller
Blog for Next-Gen Desktop: Ask The Architect
Questions, then email Ask The Architect
Facebook Friends: Ask The Architect

A common question I get when creating a XenDesktop architecture is if I should use the disks installed within my physical hypervisor server to store the hosted virtual desktop's cache.  There are many benefits in doing this and the major one is not using the more expensive shared enterprise storage.  However, if you go down this route, you must make sure that the local storage is capable of meeting the needs of your virtual desktops.  If you don't, you will experience an unacceptable virtual desktop experience. How do you figure out your storage needs? Personally, I prefer to close my eyes and throw a dart at the board to see what number I hit.  That number becomes the number of spindles I design in my solution. 
 
Actually, the storage decision is based on a few items:

• Disk speed: how fast does the disk spin
• RAID level: RAID level the disks are configured
• Read/Write Percentage: What percentage of the usage is read and writes
• User activity: what are the virtual desktops doing (booting, logging on, working, logging off). 

All of these go into the calculations for determining storage requirements.  Let's say I have 1 server with disks running at 15,000 RPM and I'm curious to see how many desktops that one server can support based on different activities. Because the disk speed is 15,000 RPM, I know that these disks should be able to support around 150 non-sequential IOPS. We could simply use an average IOPS number for each desktop, but you might run into issues as a boot or logon storm could overwhelm your storage subsystem as these two activities are much higher than the average.  Personally, I like to break the IOPS calculations down based on the activities of the environment. The numbers used for this example were directly related to a particular use case based on user's level of activity, the intensity of the bootup, logon and logoff storms.  Your use case is likely to be different and your numbers will vary accordingly. However, for this use case, the following were used

• Bootup: 26 IOPS
• Logon: 12.5 IOPS
• Working: 3.9 IOPS
• Logoff: 10.7 IOPS

The next thing you have to realize is that the RAID level will directly impact how many write IOPS a disk can support.  For example, if you use RAID 0, the write operation happens to 1 disk.  If you use RAID 1 (mirroring), that one write operation actually happens twice across two disks.  And if you use RAID 5 (striping across 3 disks with 1 parity disk), that one write operation happens 4 times!  As you can imagine, the number of desktops a disk subsystem can support actually decreases as our RAID level moves from 0 to 1 and to 5.
 
Let's take this a step further and include the read/write percentages for virtual desktops. Based on numerous independent tests (Virtuall by PQR), a good estimate is 20% read and 80% write.  The Read/Write percentage will have a slight impact on the environment as writes are impacted by our RAID level. If we didn't' include this percentage, our calculations would assume we were doing 100% writes.
 
So, what does this all mean?  First, we have to use a formula to take all of these things into account ((DISK IOPS)/(((Write%* RAID Level Impact) + (Read %))*IOPS for Activity). We should end up with something like the following

Note: These calculations assume that the server is only doing one activity at a time (all bootups or logoffs or logons).  This is not typical. Most servers would be doing a combination of all 4, which will blend the results.
 
By working on these calculations, we can easily see that this server, with a single spindle at RAID 0 will only be able to support 38 active virtual desktops.  At RAID 1, we could only support 21 virtual desktops, and RAID 5 only 11 virtual desktops. With the standard 8 core server running either XenServer, Hyper-V or vSphere, I just don't think the locally installed storage will be able to support our expected user loads of 50-100 virtual desktops unless we add more spindles. If we were estimating that our hypervisor was going to run 75 virtual desktops at the working load activity (other activities would increase these numbers, we would need:

• RAID 0: 2 spindles
• RAID 1: 4 spindles
• RAID 5: 7 spindles

Now does your Hardware support this many disks? If you are using blade configuration, probably not as many of the more common deployments i've seen only contain 2 spindles.  

So what does all of this mean besides showing my 6th grade math teacher that I still remember how to plug and chug numbers into a formula? It means make sure you understand what your infrastructure is capable of doing before finding out the hard way.

As always, if you have any architecture questions about desktop virtualization, then email AskTheArchitect@citrix.com. 

Daniel

Lead Architect - Worldwide Consulting Solutions
Follow Me on twitter: @djfeller
Blog for Next-Gen Desktop: Ask The Architect
Questions, then email Ask The Architect

For those of you who attended the 1,000 XenDesktop Users in 90 Days TechTalk on December 8th, I've gone ahead and compiled the questions and provided you with answers.  If you missed the TechTalk, you can see it on CitrixTV. 

Q: Would the "ideal" solution be to run every app on XenApp instead of installing on XD?

A: There really is no "ideal" solution because every application is different.  You need to look the application characteristics to determine how it will impact your environment. Putting large line-of-business applications in a virtual desktop typically kills the hypervisor scalability due to RAM requirements but placing these applications on XenApp offsets this.  Other applications place on XenApp will work but will not allow the user to have complete control of the application interface customization, which makes it a good candidate for the virtual desktop. Also, you can install the applications into the virtual desktop image, although every user who uses this image will see the applications. So installing the applications into the image might require the creation/management of multiple desktop images. There is no good answer, just guidelines based on the application type (Base, Anomalous, Resource Intensive, and Technical Challenging). 

Q: Can the webservers, XenDesktop controllers, XenApp servers, and Provisioning server be VMs in the hypervisor cluster/pool

A: Every component can be virtualized and it is supported. Different hypervisors will give you difference performances over other components, but each hypervisor is going to add a level of overhead.  You also want to look at the component-level utilization to get the most mileage from your physical servers. For example, Provisioning services is going to impact your network link while the XenDesktop controllers will consume CPU.  Ideally, you want to try and balance out these components so that the components of the physical server are maximized without impacting overall usability.

Q: Why are you recommending creating multiple farms while scaling out rather than adding additional DDCs to the existing farm?

A: It is based on the underlying XenDesktop architecture.  There is no technical limit to the size of a XenDesktop farm, but when you get to a certain size and your bootup and logon storms are so intense, you will start to see logon times slowing down as these requests go through the master controller.  You have 2 options:

1. Add more processing power to the master
2. Add a new master, which equates to a new farm

On the surface, people often think a single farm is the best approach but if you redline your components, strange things can happen (not only with XenDesktop but just about any software).  If you create building blocks, you are better able to expand the environment without a complete rebuild of a component because you have spare capacity and processes in place to simplify management of multiple blocks.

 

Q: Do you have any suggestions for network connection speeds on the Provisioning and Hypervisor system

A: Don't use anything slower than 1Gbps. In fact, there are some people who are using 10GigE.  Basically it comes down to this, the faster the network connection, the more target devices you can support from a single Provisioning services server.  If you are using Windows 7, you can assume that to boot up the target device will take 200MB of network traffic.  Calculate this out fot he size of the environment you are trying to support. This will help you identify your network requirements.

Q: Does streaming apps add a significant amount of complexity, compared to running apps in XenApp or on the XenDesktop?

A: It is a different approach towards delivering applications into your virtual desktop, thus giving you another method to support.  If you already have a mature XenApp environment with hosted applications, keep using it.  If you don't have a mature XenApp, look at installing your base/common applications into your virtual desktops. You will reach a point where you start to increase the number of desktop images. At this point streaming might be a more optimal solution to help reduce the number of desktop images you need to support. This is a decision that is made during the analysis/design phase. 

Q: The more desktop images.. the more disk storage in the data center needed correct. So would the preferred method (if possible) have fewer images?

A: Yes. Although 1 desktop image can be used by thousands of users.  Each image is only as big as you make it (15GB for XP and maybe 30GB for Windows 7).  So if you have Windows 7 images that is only 150GB, not huge.  However, the bigger benefit of reducing the number of desktop images is in managing them.  Instead of patching/updating 5 images, you only have to do 1. 

Q: When using XenDesktop with XenApp, does the user have two profiles or are the profiles somehow "shared" between XenApp & XenDesktop?

A: Two different ones.  You can use tools like the Citrix User Profile Management solution or third party tools like AppSense to integrate the profiles into a single container for multiple operating systems. Your question does bring up a good point, you cannot forget about the profile and the implications on the system.  

Q: Can the License Server be made redundant?

A: Yes. However, if the license server is offline, users have a grace period where they can continue to connection and work. If you virtualize the license server, you can easily move the virtual machine from one physical server to another with XenMotion.  This will not impact the users.   Probably the cheapest and easiest approach to take.

Q: we have an existing XenApp farm, and we are looking for a good White Paper on how to set up a new XenDesktop Test farm with our existing and how to go about it (integrating with Licensing server, etc). Is there a good paper you can recommend? Thanks

A: Yes, take a look at the following.

• Reference Architecture: http://support.citrix.com/article/CTX120516
• Getting Started Guide: http://support.citrix.com/article/CTX120515
• Implementation Guide: http://support.citrix.com/article/CTX120514

Also, take a look at this site for other white papers on XenDesktop that might be helpful for you.

• Ask the Architect

Q: Is a 3rd party application necessary to make the Provisioning servers completely High Available without sessions being lost?
A: No.  When you turn on the High-Availability feature with Provisioning Services, you are all done. If one server fails, the target devices receiving their stream from the failed server will reacquire the stream from another server in the HA set.  The user might notice a pause in the system while the stream is reacquired and synchronized, but the user will not lose their work.

Daniel

Lead Architect - Worldwide Consulting Solutions
Follow Me on twitter: @djfeller
Blog for Next-Gen Desktop: Ask The Architect
Questions, then email Ask The Architect

One of the questions you must ask yourself when designing a desktop virtualization solution is understanding the user patterns.  This has a direct impact on XenDesktop farm design and scalability with respects to boot up storms and logon storms. Let's take two different examples so you can get a better idea for what I'm talking about:
 
Scenario 1: 9-5:
In this scenario, all users logon in the morning and logoff in the evening.  There might be some sporadic users working after hours, but for the most part users stay within these working hours.  This is a fairly easy scenario, which is why I've started with it.  
 
To design your environment, you need to make sure that the boot up storm doesn't overwhelm your environment.  You will be starting a large number of hosted virtual desktops and that has a direct impact on your hypervisor of choice, your storage solution and your network infrastructure.  You can easily overcome any challenges with a boot up storm in this scenario by using the XenDesktop idle desktops configuration to pre-boot desktops X minutes before the main rush begins (X is based on how many desktops you need up and running before users start connecting).  By the time users come online, the system should have calmed down from the boot up storm. 

Each hypervisor limits the number of simultaneous bootups (XenServer being 3).  Although this helps limit the number of virtual desktops powering on at once, that process only requires a short amount of time as it does not include the actual OS loading.  If you have 1,000 desktops (across 10-20 hypervisors) that must be ready by 9AM, and you assume each desktop takes 30 second to fully boot, you want to start your bootup sequence by at least 8:30.    
 
The second aspect is the logon storm.  There is little we can do to the environment to spread the storm over a greater amount of time as it is based solely on the user pattern.  The logon storm is going to have a direct impact on your farm design.  You need to look at the following:
1.    Number of user connections per minute
2.    The IOPS requirements per minute
3.    The logon times you require

As you add more users to the environment, you need to optimize your architecture and allocate additional resources in order to accommodate the storm.  This might require you to dedicate XenDesktop controllers as XML Brokers and Farm Masters.  By giving the controllers specific roles, you optimize those systems to be able to support greater numbers of simultaneously connecting users.

 
Scenario 2: 24/7 (3 shifts)
This scenario brings about a few more challenges in that users are always online.  The organization is running 100% of the time and as users are connecting, other users are logging off .  The cycle continues over and over again.  This architecture is really dependent on the environment in question. Even though the organization might be 24/7, those shifts might be located around the world in different locations connecting to different data centers (follow-the-sun model).  But if we have a unique scenario where we have 1 data center and all shifts connecting to that 1 site, this type of an environment would make us change our design as follows (safe to assume that all shifts are different sizes. In fact, many 24/7 models located in one site have one large shift and the remaining 2 shifts are significantly smaller):
 
In the 9-5 scenario, a boot storm wouldn't impact other users as no users were online before the start of the workday.  In the 24/7 scenario, we have active users.   If we sized our environment based on max concurrency for a single shift, we have little extra capacity to pre-boot desktops.  

• First, we start all available workstations ahead of time to build up our idle pool (without disrupting working users).  
• Second, we disable the reboot after logoff option for the shift immediately before the largest shift starts. This will allow the desktops to be ready to go even faster.  This can be done by creating a workstation group per shift. This does bring the risk of the users not receiving a clean desktop, but this is mitigated by the desktops being rebooted (cleaned) after the other 2 shifts end.
• Third, when the logon storm begins, we can also expect a logoff storm to begin as well because one shift begins as a different one ends.  Disabling the reboot for one shift change will help overcome the boot storm impact. To accommodate the logon/logoffs, we need to optimize our environment, just like we did in the 9-5 operational model, dedicating controllers for XML brokering and farm master.  This type of configuration allows us to support the largest possible number of users within one farm, although at a certain point we will require a new farm.

Two different user pattern scenarios to think about during a desktop virtualization design. A few things to keep in mind:

• Does it require and understanding of the user environment? Yes
• Will it impact scalability of the underlying infrastructure? Yes
• Can the environment be designed in such a way to support these usage patterns? Yes

Daniel

Lead Architect - Worldwide Consulting Solutions
Follow Me on twitter: @djfeller
Blog for Next-Gen Desktop: Ask The Architect
Questions, then email Ask The Architect

Many of you might have already seen the tweet about the new podcast with Eric Perkins and Michael Keen (Alliance Technologies).  This was a great discussion around desktop virtualization and the challenges and obstacles facing organizations who venture down this route.  These two guys have a lot of experience in the application, server and desktop virtualization space.  During the discussion, I came away with the following points:

1. Hosted Virtual Desktops (VDI) are not the only solution, which was the basis for Eric's blog posting the other week where he discussed his concerns.  HVD is just one part of a much larger piece of the desktop virtualization puzzle. 
2. If you are doing a HVD model, you need to have a firm grasp of server virtualization.
3. You need to have a deep understanding of your users, their requirements, and their level of activity on the workstation or else you will over or under allocate resources.  Michael mentioned that LiquidwareLabs Stratusphere product is a great solution for gathering this information from your users.
4. The term VDI MUST DIE.  VDI does not explain the entire realm of desktop virtualization even though people use it as such.
5. Although the hosted virtual desktop model is not the only type of desktop virtualization option, it does make sense in certain use cases: education and branch offices for example (although I think the International Space Station is the epitome of branch offices.
   

Anyone who is interested in doing desktop virtualization should listen to this podcast to make sure you are approaching the solution correctly and not simply applying the one-size-fits-all model.

I personally thought this was an interesting discussion.  Michael, Eric and I are eager to hear your thoughts, so please leave comments. 

Daniel

Lead Architect - Worldwide Consulting Solutions
Follow Me on twitter: @djfeller
Blog for Next-Gen Desktop: Ask The Architect
Questions, then Ask The Architect

Being an architect in the desktop virtualization space, I get a lot of questions around scalability.  I'm not a big fan of scalability questions because there is too much SWAG involved.  Unfortunately, I've been getting them for over 10 years: first with XenApp (which was WinFrame 1.7) and now with XenDesktop.  As an example, I can easily get hundreds of users on a single XenApp server if the users are only running Notepad and I can easily get 150+ virtual desktops on a hypervisor if the users are idle and using a minimal amount of CPU/RAM. But is this realistic? 

The SWAG in scalability responses focus around a few core concepts:

1. User activity
2. Underlying hardware
3. Resource allocation
   

First, user activity.  Users are not the same. I've typically found it worthwhile to categorize users into four distinct groups:

1. Light: 1-2 apps.
2. Normal: 3-6 apps simultaneously
3. Power: 7+ applications simultaneously while invoking more advanced features
4. Extreme: 10+ applications with unique hardware level requirements and complete customization. These users typically fall into our Local Stream Desktop or Hosted Blade PC category of FlexCast.
   

You should be able to see that as you move up the categories, the user will require more RAM and more processing power. This brings us to our second scalability area of focus: Hardware.  There isn't much to talk about except that typically a larger server should support more users.  Pretty easy, although in most cases you will reach a point where the extra hardware does not scale linearly because other bottlenecks within the hardware layer are reached (CPU, Memory, IO, bus, etc). 

You now need to determine what impact the user group will have on the underlying hardware, and this is based on the user group, the operating system and the applications.  Unless you are going for the massive servers (24 cores+), you really only need to concern yourself with processor and memory consumption. Because your mileage will vary this is where you need to calculate what percentage of the physical server will each user type consume.  Once you've done this, your almost done.

The final aspect is resource allocation. There is a lot of debate about over-allocating memory resources (you know where I stand on over allocation) but what about over-allocation of the CPU?  There is some SWAG here in that you have to estimate what percentage of your users will be active at any one point.  If you are a XenApp administrator, you probably realize that about 40%-60% of your users are idle at any given time.  I wouldn't feel comfortable using that same percentage on the virtual desktop side of things.  In XenApp, users are working with 1 application at a time. They oftentimes go back to their physical desktop to do other things, which makes their XenApp session appear idle.  But if we have the entire desktop virtualized, the user doesn't have a non-hosted desktop to go back to.  So your user idle percentages should be much smaller, around 20%-30% (remember, reading an email, reading a doc, attending a meeting makes it look like you are idle).  

When I'm trying to determine my virtual desktop specs, these are the things I look into, what about you? 

Daniel

Lead Architect - Worldwide Consulting Solutions
Follow Me on twitter: @djfeller
Blog for Next-Gen Desktop: Ask The Architect
Questions, then Ask The Architect

Truth be told, no one really cared about the desktop before we started talking desktop virtualization.  If a desktop failed, it really only impacted a single user, not a big deal unless the user is the CEO or Payroll. Unfortunately for that user, they could be out of commission for days/weeks.  But in a desktop virtualization world, that user can automatically reconnect and get their desktop back, albeit it is technically a different entity as it is now running on another hypervisor with a fresh OS install and Apps, but it looks and acts the same.

What happens if there is a major glitch, issue, failure, etc with the environment?  Even if your environment is rock solid, someone is going to do something that will bring down a very critical component. You might lose one user, but chances are you will lose hundreds or thousands.  If the failed component is critical, those users might not be able to reconnect.  Now you are in a world of pain.  If you are in IT and in charge of the desktop virtualization solution, it might be time to either
1.    Change your name
2.    Update your Resume
3.    Convince everyone that you are trying to save energy costs and shut down the entire system (not likely to work)

How do you avoid the name change or career change?  By doing your job correctly and designing a desktop virtualization solution that can withstand the failure of components without denying user access.  A High-Availability Reference Architecture and Implementation Guide for XenDesktop have been released to the Ask the Architect site.  

The choice is yours, design an environment that has high-availability or design your own rapid exit plan.  
Daniel - Lead Architect - Worldwide Consulting Solutions

• Twitter: @djfeller
• Desktop virtualization information: Ask the Architect - Next-Generation Desktop site
• Questions - Then Ask The Architect

Migrating to a desktop virtualization environment is something one would expect to take a very long time. And it should because you need to:

1. Understand the environment (users, business, and goals)
2. Understand the solution
3. PoC, Design, Build/Test, Pilot and Rollout
   

This all takes time, and quite a lot of time if you are new to the game. But what if you could get 1,000 users up and running in a desktop virtualization solution within 90 days?  Sounds too good to be true right? 

Wrong.  Actually, because we've been involved with many organizations and implementations, we believe this is possible by following a rapid implementation that still follows the Citrix Consulting methodology.

I can tell you that the first desktop virtualization solutions took a long time as there is a learning phase for everyone involved, but we now have the knowledge to get this done fast. We have a proven XenDesktop blueprint that enables us to rapidly speed up this process. 

I can't tell you everything right now. You will have to wait until next week for an Ask the Architect TechTalk where Florian Becker (Director of Worldwide Consulting Solutions) and I (Lead Architect of Worldwide Consulting Solutions) will show you how we can get 1,000 users live in 90 days. 

Look forward to seeing you there at this Ask the Architect TechTalk starting at 1PM eastern time on Wednesday, December 9th. 

Daniel - Lead Architect - Worldwide Consulting Solutions

• Twitter: @djfeller
• Desktop virtualization information: Ask the Architect - Next-Generation Desktop site
• Questions - Then Ask The Architect

Florian - Director - Worldwide Consulting Solutions

• Twitter: @florianbecker

I recently had the opportunity to sit down and talk to one of Citrix Consulting's most experienced desktop virtualization consultants... Doug Demskis (Sr. Architect). Doug has been involved in just about every major XenDesktop project to date, which made it so much more enticing to pick his brain. Doug spoke about one project in general where they are aggressively building a XenDesktop environment with the following specs:

• Size: 60,000-100,000 users strong
  • Virtual Desktop Types:
  • Current: 1:1 assignments
  • Future: Pooled
• Data Centers: 7-10 spread across the world
• Application Delivery:
  • XenApp delivered
  • User-installed applications based on optimized IT process

During the discussion, Doug focused on one area that many people fail to understand and plan for when doing a desktop virtualization solution: Operational Model. If you need to make a change, which group is responsible? Desktop, application, server, or networking group? This is a very interesting discussion I had with Doug and you can hear it as well with the latest Ask the Architect podcast. Also, if you or someone you know who is currently or already completed a desktop virtualization implementation, I'd be eager to hear from you.

• Doug Demskis (Citrix Consulting) Podcast
•Ask the Architect - Next-Generation Desktop
• Questions: then Ask the Architect
• Twitter: @djfeller

Daniel - Lead Architect - Worldwide Consulting Solutions

If you have paid any attention to any articles relating to desktop virtualization, you will quickly see claims like:

• Will Windows 7 fuel desktop virtualization adoption
• How desktop virtualization eases Windows 7 Migration
• Windows 7 Drives Desktop Virtualization
• Windows 7 and Desktop Virtualization: The New Tools
• Windows 7 - The Desktop Virtualization Catalyst 

 
I could go on, but you get the point. The major thought is that Windows 7 and desktop virtualization go hand-in-hand, but how do you get there?  You are not only migrating the OS but you are also migrating to a virtualized desktop operating environment.  Is this too much change for an organization?  
 
NO.  This is the perfect time to make the move.  Think about it this way, we have the opportunity to start with a clean slate.  We can define the new operating system that completely aligns with the organization's policies.  We can provide an environment that self heals and is optimized each and every time a user connects.  But in order to achieve these benefits, we have to design the environment correctly.  We need to focus on
•    What do we include in our base desktop image?
•    How do we deliver the operating system to our end point (which might be a physical or virtual desktop)?
•    How do we integrate applications into the mix?  
•    What are the recommendations for allowing users to personalize their environment without impacting the business?
•    What are the best practices for providing a great user experience for any user over any connection?
 
These are some of the topics being presenting in this week's Microsoft TechNet broadcast focusing on "Accelerating Windows 7 Migration with Citrix and Desktop Virtualization"
 
The show starts on Thursday, November 12th at 1PM Eastern time and you can register here

Daniel - Lead Architect - Worldwide Consulting Solutions

• Twitter: @djfeller
• Desktop virtualization information: Ask the Architect - Next-Generation Desktop site
• Questions - Then Ask The Architect

I got an interesting item in my inbox from a friend who was speaking with VMware about their VDI solution.  He asked me if the information VMware was telling him was true. He was especially curious because he knew I wrote the Citrix XenDesktop Enterprise Designreference architecture that VMware was referencing to talk about how much better View was. VMWare's approach is laughable.  They are taking a detailed consulting design document  and trying to compare it to the VMware View reference architecture, which if you read it like I have (wasted 2 hours of my life), you will quickly see it is high-level and full of marketing spin and provides no insight.  I, on the other hand, was trying to provide all of you in the community with insight into how to design a large, and complex customer environment with XenDesktop.  Anyways, I told him the angle they were using and he thought it was ridiculous.  I was going to leave it at that, but I've been seeing and hearing more about it from others so I thought I would provide all of you with the same information.  Let's break it down: 

Scalability:

• Misconception: VMWare says that XenDesktop has poor hypervisor scalability. They say that on a 16 core server XenDesktop can only support 40 users (3 users per core). 
• Truth: The XenDesktop reference architecture for the hosted virtual desktops is 8 cores, not 16.  In the design phase, we estimated 40-50 VMs per server, which averages to 5-7 virtual desktops per core.  We were a little conservative as we were not sure how the unique applications would impact the system.  But you can look at Project Virtual Reality Check scalability white paper to get a good comparison of XenServer and ESX.  Although the design VMWare references was for XenServer, the same estimates would have been used if the hypervisor was running ESX.

Storage:

• Misconception: VMware likes to say that XenDesktop is a storage pig in that we need a lot of storage associated with each virtual desktop. 
• Truth: This particular design had a requirement to keep a few system items persistent across workstation reboots so we recommended the creation of a local, persistent disk of between 3-5GB to store items like event logs, performance metrics, antivirus definitions, etc.  This is not NAS/SAN storage; it is the storage on the physical XenServer.  Think about it. You buy an 8 core server, install XenServer, which is small, and the rest of the local storage is wasted.  We utilize that for the persistent store of the virtual desktops.  This means we cannot do XenMotion on the virtual desktops, but most customers I've spoken to do not have this requirement.  After looking at VMware's reference architecture I don't see any level of detail as to the amount of storage they require.  I wonder why not. 

Workloads:

• Misconception: VMware states that they can get more users on a hypervisor than we can.
• Truth: This is all around scalability tests, which I'm not a fan of.  I can easily find you 5 tests that show XenServer is better and another 5 that shows ESX is.  The VMware reference architecture had users connected for 14 straight hours, seems like a long workday to me. I have a question for VMWare: What company did you create this architecture for where users would work for 14 hours? Please tell me as I do not want to work there.  As we all know, the most typical system hit is during startup and logon. So by expanding the session time from a few hours to 14, the overall average utilization rates can be significantly lowered, thus providing an inaccurate estimate to the hardware
• Truth: The Citrix Reference Architecture made estimates based on the applications and expected real user workload, not simple apps and 14 hour workdays.  VMware's reference architecture was based on standard scalability samples shown below. If this was an actual user workload, I totally want to work for that company because that job looks so easy:
  • Microsoft Word - Open/minimize/close, write random words/numbers, save modifications.
  • Microsoft Excel - Open/minimize/close, write random numbers, insert/delete columns/rows, copy/paste formulas
  • Etc

RAM:

• Misconception: The amount of RAM that VMware recommends in their reference architecture is nuts.  They say they can get 96 users on a server with 96GB RAM.
• Truth: If you subtract the hypervisor overhead you are looking at "USABLE" RAM of about 800MB per virtual desktop.  I say usable because ESX has probably enabled memory ballooning.  It is true that XenServer does not have memory ballooning, but I would recommend customers disable this feature for virtual desktops.  On XenDesktop projects that use the ESX hypervisor, I also recommend disabling this feature.  Users and desktops are more dynamic than server workloads, meaning the RAM consumption is going to fluctuate greatly.  If RAM starts to decrease to the critical threshold, what happens to the hypervisor?  It must free up memory by paging this to disk.  Isn't this an intensive system process that consumes more resources at a time when resources are scarce?

End Points:

• Misconception: Vmware talks about the end points and only focus on thin clients and end points that we can repurpose with a Linux OS or locked down Windows OS. What about the newer end points that organizations have already spent money on? 

• Truth: With VMware View you still will connect to the VDI desktop and idle your local hardware. Seems like a lot of wasted desktop resources to me.  XenDesktop, on the other hand, allows you to re-use those desktops as a local streamed virtual desktop. Don't be fooled, there is more to desktop virtualization than VDI.

Provision:

• Truth: Closer to the end, the reference architecture talks about the time to provision X number of linked clone desktops.  I'm not sure if this is automated or if an admin has to do each desktop one-by-one. I'll give VMware the benefit of doubt here and say it is automated, but taking 161 minutes (2 1/2 hours) to provision 500 virtual desktops seems long to me.  I personally don't think this metric is important, even though XenDesktop is measured in seconds.  If it is automated, you do all of this in the build out phase and not in production. So the time it takes is irrelevant to me. Why did they choose to include it? No idea

So my advice to anyone who is still reading this blog... Take everything you get with a level of skepticism.  Do your own due diligence and look at the details to see if things were glossed over or if an in-depth analysis and design was completed.  That recommendation even includes the materials I post.  I try to be open and honest in my blogs, white papers, TechTalks and videos, but I am a little biased to Citrix because they pay my bills. 
If you want to discuss more, or have further questions, then Ask the Architect

Daniel - Lead Architect - Worldwide Consulting Solutions

• Twitter: @djfeller
• For the latest desktop virtualization information visit the Ask the Architect - Next-Generation Desktop site
• Questions - Then Ask The Architect

  

My role allows me to speak with many different people (customers, technologists, coworkers, administrators, etc). I've been able to see presentations comparing the different desktop virtualization solutions out there.  One of the problems I see is that many of the solutions only focus on one aspect of desktop virtualization, and that is the VDI model. 

VDI is only one aspect of the entire desktop virtualization solution.  This is a concept that many fail to comprehend. For example, I attended Gartner ITExpo last week and was amazed at how many people I talked to only thought about the VDI scenario (you know VDI, allowing you to have a remote virtual desktop running on a hypervisor in the data center).  When I talked to people about the other options, I could see their eyes light up.  

If you are reading this and only know about the VDI version, the I suggest you take a look at FlexCast to get a better understanding at all of the different options out there (FYI, even the CIO magazine identifies there is more to desktop virtualization than VDI). But in a nutshell, here's the deal... desktop virtualization includes:

1. Hosted shared desktop
2. Hosted VM-based VDI desktop
3. Hosted blade PCs
4. Streamed local desktop
5. Virtual Apps to installed desktops
6. Local VM-based desktop

I want to focus on the Streamed local desktops scenario. This is the one that really got people's attention at Gartner.  Why?  Because most organizations do not do a big bang effect of replacing their end point devices. Instead, most have a rolling lifecycle where each year a portion of the endpoints are upgraded and over the course of 3-4 years the entire desktop environment has been upgraded. Once the process completes, it starts over, never ending.  
 
Let's now say you are embarking on a desktop virtualization project.  It seems like  a waste of resources and money to idle those desktops that are only 1 year old. They are powerful enough to run Windows 7 and the latest applications, so why would we not use the hardware we already have?  This is where the streamed local desktop comes in. It uses the same XenDesktop infrastructure, the same OS images, the same application layer and the same personalization layer.  The only thing that changed is the hardware layer.  
 
As money always seems to speak louder than words, think about it this way: If you have 3,000 desktops and they are replaced every 3 years on a rolling cycle, that means 1,000 of those desktop are less than 1 year old.  If you estimate 50-100 virtual desktops on a hypervisor (XenServer, ESX or Hyper-V) then you need 10-20 fewer physical servers, which is a substantial cost savings (and even greater if you are using a hypervisor that costs money).

So I encourage all of you to not think about the VDI-only solution but instead to look at your environment as a whole. Chances are you will see that VDI-only might work for you, but probably isn't the best way to run your business. Think about it this way... You can create documents in Notepad, but would you really base your business on a solution that only does one thing, or would you use a more complete solution like Microsoft Word that gives you options?  

Daniel - Lead Architect - Worldwide Consulting Solutions

• Twitter: @djfeller
• For the latest desktop virtualization information visit the Ask the Architect - Next-Generation site
• Questions - Then Ask The Architect

I have recently returned from Gartner ITExpo in Orlando.  It was quite interesting, especially some of the thoughts they had around the economy and impending recovery.  One thing stated during the conference should not be a surprise to anyone, during a recession you save your money by not taking on any new projects. By not implementing beneficial upgrades to your systems. By not delivering newer versions of your applications to users.  

This does have the benefit of saving money, but this can only go on for so long.  Eventually, your competitors will stop saving and start expanding. Where will you be?  

We are at a very unique inflection point that can have lasting ramifications to your IT infrastructure.  We are:

1. Coming out of a recession. We are very likely to see a slew of projects going across the tables to install this or upgrade that. So it is looking like the next 1-2 years will have IT taking on a lot of tactical projects.
2. Getting ready for a major operating system upgrade with Windows 7. Whether you are ready or not, Windows XP doesn't have much time left, and most people are skipping Windows Vista. How are you going to migrate?
3. Able to do things that were unheard of in previous years. We can virtualize a massive server into small chunks, we can do the same to an operating system, applications, and the user's personalization layer and deliver it to any type of device imaginable (phones, PCs, MACs).  

So what does this mean? It means you can continue running your environment like you have for the last 10-20-30 years, or you can ask yourself one simple questions: "Is there a better way?"

We have a very profound opportunity to correct the issues of the past.  And if we do it correctly, the resources required to update, maintain and support our environment will greatly reduce.  So when the next recession comes around, your organization will be ready with a fast and streamlined approach towards maintaining your IT environment as well as continuously providing new services.  But where to begin?  

Take a look at your infrastructure. What area requires a lot of time and resources to maintain?  Probably your desktop environment.  Let's investigate and fix it, but let's do it right.  Make sure you look at all aspects

1. The users: what do they need and how do they work
2. The devices: what type of devices, what capabilities
3. The locations: where are they located, what bandwidth pipes are available
4. The applications: how many are there, what level of dependencies do they have, who uses what

This information is critical.  This is what you need if you want to do the desktop virtualization solution correctly, from day 1.  Is it going to be something you can do in 10 minutes? No. Is it something you can implement in 1 hour? No. Why?  Because we are taking something that is seriously complex and trying to create a solution that can scale and simplify our lives. So during the next recession, we won't have to stop delivering new services, but can forge ahead and beat your competition with an entirely new delivery solution.  
Daniel - Lead Architect - Worldwide Consulting Solutions

• Twitter: @djfeller
• Ask the Architect - Next-Generation site
• Questions - Then Ask The Architect

We have had a great discussion going about user-installed applications and the need/risks associated with this type of solution. One of the comments I received in favor of allowing users to install applications was around Firefox. For those of you who don't use Firefox, there are thousands of add-ons a user can install to customize their browser experience. I personally have about five different add-ons configured with my Firefox implementation.

Now I've been advocating the need for IT to have a process in place that can handle the expansion of the application pool for the users as needed by:

1. Taking user requests for new applications/tools
2. Validating the need
3. Delivering in a timely manner

This is all well and good until we get to the topic of these add-ons. I don't expect any IT organization to have a requirement to support the add-ons. There are thousands of them. Think about it, do you really expect your IT to be spending time messing with these add-ons? And what would it look like for the user? A Firefox application with thousands of add-ons? CRAZY (I do wonder at what point that app would crash. Maybe need a MythBuster episode on it)

All of the sudden, I had a very enlightening experience. I just got my new XenDesktop 4 environment built. I went in an started to personalize my environment, including my 5 Firefox add-ons (remember I'm using pooled desktops from a single base image with roaming profiles). The next day, when I logged onto my virtual desktop, my Firefox starts up and BAM all of my add-ons are still there?!?!

I did some investigation into this. Well, this is an example of an intelligent application design. The add-ons are located within the user's profile (the roaming portion). User's are able to customize the Firefox application without any special tools/utilities. The discussion about Firefox and the add-ons is now a non-issue as the application manages this for us.

So, 1 application down, only 999,999 to go   The point is you need to test before deciding if something will or will not work.

Daniel - Lead Architect - Worldwide Consulting Solutions

• Twitter: @djfeller
• Ask the Architect - Next-Generation site
• Questions - Then Ask The Architect

Now that XenDesktop 4 includes numerous ways to deliver virtual desktops, (Greater description of the FlexCast technology), we need to take a look at how those applications are integrated into:

1. Hosted/Shared desktops
2. Hosted VM-based desktops (VDI)
3. Hosted Blade PC desktops
4. Local Streamed desktops
5. Virtual Apps to Installed desktops
6. Local VM-based desktops

(BTW, this also aligns with a CIO magazine article on Desktop Virtualization's 5 most important flavors) 

And this is a question that Cole M sent into Ask the Architect.  As always, the short answer is "It Depends", but I try to do a little better than that in the latest Ask the Architect Video. 

Daniel - Lead Architect

Follow me on Twitter: @djfeller

Follow the latest in desktop virtualization

Send Desktop Virtualization questions to: AskTheArchitect@Citrix.com

Did Brian Maddenmake a valid point about VDI and desktop virtualization that most people missed?  

Brian discussed a VDI€‰challenge, user-installed applications, which was in response to a desktop virtualization postI recently wrote about the same topic. Brian's premise was that each user needs to be able to install their own applications and should be allocated 2 virtual desktops:

1. First one locked down by IT
2. Second one is open where users would have full control

When I first read this I thought, well yes that would work but talk about a nightmare situation.  Many of the comments posted were extremely funny and I encourage you to read them (especially the one that said "Steve Ballmer must be smiling"). But seriously, if you think about what Brian is saying, it does have validity, if done correctly.

Sure there are tools/solutions that can allow users to install their own applications but we should not open the flood-gates and allow users to install whatever they desire. Not only are you looking at a management nightmare, but you are also looking at security risks, legal risks, and productivity risks.  What I can see happening is an environment that is suited to what the user needs. Something like the following...

1. Each user gets their IT-delivered desktop that includes all known corporate applications.  These applications are delivered into the desktop either through installation, streaming or hosting.  Users will inevitably try to install apps/plugins/tools into the corporate-delivered desktop.  The app will work until the user reboots (assuming shared image mode).  Once rebooted, the app is gone and the cycle starts again.  If the application is a new business requirement, there must be an IT process in place where users can request a new application. IT must have SLA's in place that allows them to assess the validity of the request, profile the application and deliver it to the virtual desktop in a timely manner (a few days to a week). Until the application is ready for delivery by IT, the user can continue to install or request a second virtual desktop (step 2 below).
2. Each user has the "ability" to self-service a second virtual desktop that can be used as a "playground".  Many power users have a need to install, test, evaluate different tools to make their jobs easier. Most users only need these applications for a few days or weeks, at least until a project is complete. Other users only need the application until IT is able to properly deliver the application into their corporate-delivered desktop.   This is where a second virtual desktop, i.e. a self-service desktop, could be requested. This is something like Brian recommended, 2 desktops. But the second desktop is only used if it is needed and requested through a self-service process. Of course because IT does not know what users will do to this desktop, proper security precautions must be taken into account.  With this option, users would have the ability to:
   1. Select the OS
   2. Select the life of the desktop (days, weeks or months)
   3. In the background, workflows are initiated that creates a new desktop, assign it to the user, and allow changes to be stored within the writable, user image.  When the timeframe expires, the desktop is deleted from existence.  

This option solves many of the challenges users experience in a virtual desktop world.  How to install temporary applications. How to use a new business application until IT is able to assess and deliver it properly.  

The point is that we must understand the users and their needs.  Most users can get along perfectly well with the applications delivered from IT.  But a sizeable portion of the user group needs autonomy, freedom, experimentation... A Playground. The one size desktop does not fit all.  Some user's might have two different desktops, others only 1.  We need to change the way we think about delivering desktops to users.  And in order to meet user expectations, we need systems (technical and process oriented) in place that can accommodate the users in a timely manner.

• Twitter: @djfeller
• Ask the Architect - Next-Generation site
• Questions - Then Ask The Architect
• See me talk about designing your XenDesktop solution on Citrix Live

Daniel - Lead Architect - Worldwide Consulting Solutions

With so many articles flying around about desktop virtualization and VDI, have you ever seen or heard of anyone actually implementing this solution? And even if you have, I bet you, like me, have many questions to ask.

Well, I've had the opportunity to sit down with Sandy Kingdon, a Dynamic Desktop architect for CSC. Sandy is working on a large XenDesktop implementation and I was able to speak with her about it. It is an interesting discussion and architecture in that it uses Citrix XenDesktop, VMware ESX and AppSense User Environment Management

• Current Capacity: 1,000 users
• End of Year Capacity plan: 10,000 users
• End of Project Capacity plan: 40,000 users
• Virtual desktop specifications: Based on customer analysis and experience
• Antivirus requirements and updates design
• Application integration with the user desktop images
• User-installed applications requirements and design
• End-point device configurations

This discussion was focused on the architecture, design considerations and experiences.  I can imagine as this project continues to grow to their 40,000 user goal we can have additional discussions on lessons learned, tips/tricks, etc. 

If you want to hear more and see what else we have going on around desktop virtualization architectures, I recommend you visit the Ask the Architect site. Also, if you or someone you know who is currently or already completed a desktop virtualization implementation, I'd be eager to hear from you.

• Sandy Kingdon (CSC) Podcast
• Ask the Architect - Next-Generation site
• Questions - Then Ask The Architect
• Twitter: @djfeller

Daniel - Lead Architect - Worldwide Consulting Solutions