Install, stream, host, Oh My!!! 

Many of you have heard me talk about the different ways to deliver applications into a virtual desktop: installing, streaming, hosting and VM-hosting.  As with all options in life, each one of these has their pros/cons.  However, I recently found a way to remove one of the cons out of the equation for installed applications.

Although we like to say "No" to installing applications, for some organizations and applications it might still makes sense. It is easier (because we are used to it), installing supports every application, and it gives the fastest application launch time compared to any other option.  My recommendation has been to install your common applications in your golden desktop image.  If everyone needs the applications, then just install it to give the users the fastest experience possible. 

Makes sense so far. But what about those applications that we want to run on the desktop but do not stream?  We would install them. But unfortunately, when you install an application into a desktop image, everyone who uses that image will see the application - D'oh!  This is probably not something most people will want to happen.  Why am I seeing this application if I don't need it? Most administrators when faced with this situation, would take the most logical course of action... Build a new desktop image for a particular group of users.  Sounds reasonable, but this now requires you to maintain a different image with additional locally installed applications.  The maintenance requirements starts to increase exponentially. 

BUT, what if you could use a single image and put all of your installed applications into that image while still allowing the users to see only what they need to see?  Seems like we could reduce the number of desktop images.  It is possible and it can be summed up in two works: Published Content.

Published Content is a little used feature in XenApp. Instead of publishing applications, you essentially publish content which are links, URLs, shortcuts.  If we publish a shortcut link to the installed application, we can determine which users will see icon.  When a user selects the icon, which is pointing to the executable file on the desktop, the application starts immediately.  And with the use of Dazzle, we can allow the users to configure their start menu with the icons as they see fit. 

Of course this doesn't do anything for those users who are smart enough to go searching on the local virtual desktop C: drive and can find the physical executable file.  But you can use Active Directory policies to disable certain users from executing certain applications.  (User Configuration - Administrative Templates - System - Don't run specified Windows applications)

Of course to set this up, you have to get the application installed, publish content, and set an Active Directory security policy. But once it is configured, you have one less desktop image to maintain and adding/removing users to a particular application just involves adding/removing users from a particular Active Directory group membership. 

Now you have another option in your bag of tricks.  Hope it helps

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 Fan Page: Ask The Architect

Are you using Windows 7 yet? Has your organization migrated yet?  Have you been reading all there is to know about Windows 7 migrations?  Then I must ask why you didn't attend the Ask the Architect TechTalk on February 25th.  Not only did we talk about the expected challenges most will face during the migration, but we also focused on how we can overcome these like we've never been able to do before, thanks to advances in technology like desktop virtualization and application virtualization. 

First, if you want to hear what was discussed, it's not too late. You can watch the Windows 7 Migration recording.  The great thing about the recording is that you can repeat sections over and over again. To get an idea of the topics covered, the following is the Q&A from the live event:

Q: How do you suggest we migrate from physical profile to virtual profile as we have no virtual desktops yet

A: You can' migrate from Win XP to Win 7 profiles. You have to pull sections from the old profile and import them into the new profile via with tools like Citrix Profile Management or AppSense.  Of course, you have to test as some of the locations might change between OS versions. If you want a lot more information regarding profiles, then I suggest you attend this upcoming Ask the Architect TechTalk about Profiles.

Q: How does USMT tool fit into migrating with XenDesktop?

A: The User State Migration Tool would be difficult to use in this scenario.  As I've seen it used, it essentially snapshots your Windows XP image and then has Windows 7 link into the old image.  This means we would have to store all of the Windows XP items from all of your users, this could be a lot of space.  Also, I always prefer to start users with a clean slate when moving to a new operating system to help optimize their environment.  Of course, we would pull a few important items over, but it is still more optimized than if you would try to reuse the entire environment. 

Q: In my company (tele-marketing) we are using an application which requires the use of audio-resources, will it work fine with virtual desktops ?

A: Sound does work with XenDesktop virtual desktops. You can even use microphones and have 2-way conversations within the virtual desktop. However, not knowing the applications/audio requirements you will really need to test the application to make sure it performs as expected.

Q: What about IE6 to IE8 app incompatibility when you move to Win7.  We find lots of apps not compatible with IE8.  Same for vendor apps.

A: Unfortunately, you will need to find a way to run IE6. Since Windows 7 already has IE8 installed, you really can't move backwards.  You have two other options:

Option 1: Use a hosted IE6 from a Windows 2003 XenApp server.

Option 2: Use published IE6 from a Windows XP desktop that is delivered as a VM Hosted Application via XenApp.

Q: what are the software options for streaming apps?

A: The two most common application streaming options are to use XenApp Application Streaming or Microsoft App-V.  Both can easily be integrated within the XenDesktop images.

These were just a few of the questions discussed during the Ask the Architect TechTalk.  If you want to hear more, then feel free to listen to the recorded webinar.

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 Fan Page: Ask The Architect

Total power often leads to corruption. No, I'm not talking about business or politics. I'm talking about desktops.  Have you been in a meeting where people talk about giving users admin rights to workstations. I have two words for you... Be afraid... Be very afraid...  OK that was 5 words, but the point is clear. Be afraid.

Many of the challenges with the traditional, distributed desktop operating environment are the lack of standard definitions and enforcement.  Most organizations strive for a secured and locked down desktop environment, but over time users were granted exceptions. Throughout the months and years, those exceptions became the new de facto standard.

Now, users have local admin rights. Thousands of unique applications are installed throughout the organization.  Every desktop configuration is unique.  This is an almost impossible situation for any IT organization to support.  This environment did not happen overnight; it took time.  Standards slipped because it was simply easier and faster to circumvent the standards instead of troubleshooting the issue.  Because of the lack of standards, the environment is so convoluted and complex, it is excruciatingly difficult to make any changes or updates without causing mass confusion.

That being said, can these types of organizations still use desktop virtualization? Yes. And they will see many of the benefits with desktop virtualization that have been discussed over and over again. It will just be more difficult to achieve than an organization who has the desktop standards in place and actively followed.

Many organizations look at desktop virtualization at being the solution to simplify the desktop operating environment.  Desktop virtualization is an enabler.

If done to the fullest extent, desktop virtualization is an enabler towards better IT management.  Desktop virtualization can enable an organization to discard the bad habits of the past  and replace them with best practices that can help an IT organization survive and succeed within an ever increasingly complex computing environment. In order to simplify the management of the desktop, reduce desktop operating costs, and achieve desktop virtualization success, the organization must have alignment in terms of:

• User rights: Users must have enough abilities to do their job, but this does not mean users should be a local administrator.  IT must be able to provide the users with the correct applications and resources when requested. If modifications are required, IT must be able to accommodate in a reasonable amount of time. If IT is unable to meet the agreed upon time frames, alternatives must be made available so users can continue to be productive, which might require an open, and temporary virtual desktop playground area where users can utilize these applications until IT integrates them into the mix. I discussed this in a previous blog about a virtual desktop playground.
• Applications: Allowing users to install their own applications into the corporate desktop image increases complexity and reduces the security of the system.  IT has no visibility into the application and is unable to plan upgrades, updates, or hardware refreshes. The applications could open up holes in the infrastructure that others could exploit.  The organization must gain control of the applications if the organization is going to be more flexible.
• Operating Procedures: IT must deliver the resources users require in an adequate amount of time. This involves the development of new IT processes and ways of working.  If a user requires an application, IT must find a way of either incorporating the application into the environment, or finding the user an acceptable alternative while working within the confines of the corporate standards.  

Simply moving to desktop virtualization will help us solve some of our challenges, but if you want to make a significant improvement in the way IT is seen within your organization, there must be a new approach.  Without clear definition of the operating standards, moving to a desktop virtualization solution will result in many of the same challenges observed with the traditional, distributed desktop operating model. Chaos.  Except this time it will be virtual chaos.

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

IOPS. One of the core design areas that will impact the overall performance and usability of a desktop virtualization solution.  How do we estimate IOPS? What impact will a user have on the storage infrastructure? Is estimating 30 IOPS per user good enough? Is it too high? Too low? This is the question Doug asked in the latest Ask the Architect Viewer Mail.  

If you use the 30 IOPS per user to design your storage, you should have enough capacity, but you are probably wasting a lot of money on capacity that you will not fully utilize.  

A user's impact to IOPS is based on four phases of a desktop's life cycle:

1. Boot
2. Logon
3. Work
4. Logoff

Each one of these phases has a different impact and they are discussed in the latest Ask the Architect Viewer Mail:

As always, if you have desktop virtualization questions, then send your questions to Ask the Architect.

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 great question came into the Ask the Architect email recently focused on storage and RAID configuration for XenDesktop environments. Essentially, what RAID configuration is most appropriate for XenDesktop:

• RAID 0
• RAID 1
• RAID 5
• RAID 10
  

As with most good things in life, the answer is it depends. It depends on reading/writing operations, fault tolerance requirements and storage space allocation.  Instead of writing about it, watch the latest Ask the Architect video below

As always, if you have desktop virtualization questions, then send your questions to Ask the Architect. 

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

Let's talk scalability again.  Scalability. One of my favorite topics (insert sarcastic tone here).  I like the scalability topic so much that I recently blogged about it when talking about the possible size of a XenDesktop farm.

But a new question came into the Ask the Architect wanting to know about scalability for XenDesktop. I'm happy to see that this question wasn't simply how many desktop can I get on a hypervisor, but actually wanted to understand the things that should be monitored to help guide you when you should add a new server or component. BRAVO!!!

Citrix Worldwide Consulting recently published a new white paper discussing how to design the XenDesktop environment in a modularized fashion.  This allows one to add components as the environment scales up. There aren't numbers in there because as with most things in life, you mileage will vary.  But to do an architecture correctly, one must understand what should be monitored so better decisions can be made regarding the allocation of additional resources. 

This Ask the Architect video explains these areas of focus. 

As always, if you have desktop virtualization questions, then send your questions to Ask the Architect. 

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 recently received a question regarding the integration of Microsoft App-V with a hosted-VM based VDI desktop within a XenDesktop infrastructure.  App-V, just like XenApp Streaming, creates an application profile where portions of the profile are delivered to the endpoint as needed.

The challenge is with this particular set of applications, they undergo frequent updates (daily).  Integrating the application layer requires:

• A configuration that keeps the cache intact across reboots (as this will speed up the application delivery aspect)
• A configuration that allows for seamless updates without requiring reboots or virtual desktop image updates
  

Because the virtual desktop is delivered from a single Provisioning services image, a persistent disk should be allocated for each VM as explained in the following Ask the Architecture Q & A video. 

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

The migration to the new operating system was a challenge. We had a mass of people going to each user's desktop to copy their data and rebuild the operating system.  We thought we planned appropriately but ran into all sorts of issues like:

• We didn't have the correct hardware drivers for some of the computers, which required searching the Internet and oftentimes using try and error until we found the right driver.  There were too  many occasions where we were unable to find a driver for the new operating system.  We just hoped the user wouldn't notice.
• We sometimes found out that not all of the hardware was compatible with the new operating system so we had to quickly find a new computers for some of our users. 
• During the application install, we often came to realize that some of the applications were incompatible.  Once we figured out how to get the application installed, we thought the mission was accomplished and moved onto the next user.  This took about an entire day to complete for 1-2 users. 
• We thought we finished with the user but because this was a new interface for the user and a new way of doing things the user ran into many issues. Many of their settings were gone and so were their icons.  So while we continued to migrate more users, we had to backtrack and help teach the users.
• When the next upgrade comes along, I'm going to take a sabbatical. 
  

This is not an example of a migration to Windows 7.  This is an example from Windows 3.1 to Windows 95.  The same could be said for migrations from Windows 98 to Windows 2000 or from Windows 2000 to Windows XP. 

Guess what?  Migration season has arrived again.

By all accounts, 2010-2011 will be the time when many organizations investigate how to move all of their users to the new Windows 7 operating system. We have to ask ourselves if we plan to follow history and repeat our steps, or will we try to do something different so the migration isn't as painful and long.  Let the past be our guide. We know what challenges we will encounter, so let us solve them before they hit again:

• Hardware: Desktop virtualization and Citrix FlexCast can solve these challenges because the virtual desktop is either hosted on a hypervisor (thus having the same configuration) or delivered to the newer generation of desktops via a local streamed desktop.  The images are pre-built and implemented in a matter of seconds instead of hours.
• Applications: We aren't limited with local installed applications on the desktop operating system.  We can install, stream or host the applications.  And in the rare event that these three options are not enough, we can use VM Hosted Applications on an older operating system.  The point is that from the user's perspective, the applications operate seamlessly.
• Personalization: We want to save the critical user data while discarding the irrelevant.  With personalization solutions, we can help ease the user's transition to Windows 7 by migrating portions of the personal environment. 
• Support: Once the migration is complete, users will have questions and issues.  We need to see what the user sees.  We need to detect issues before they impact the users.
  

We know we will migrate, but the question is how will we migrate to Windows 7. We already know the challenges we will face by doing the manual, physical migration. We know that desktop virtualization can solve these challenges.  So let's investigate desktop virtualization further by attending a one hour Ask the Architect TechTalk on Windows 7 Migration. 

Remember, the distance between insanity and genius is measured only by success.  So if you want to be a genius, you need to know how to effectively create a desktop virtualization solution that can ease your Windows 7 migration. 

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

Mario Andretti, the great race car driver, was once asked by a reporter if he was ever afraid when driving a formula one car and pushing the envelope through the duration of a race. Andretti answered: "If you're not uncomfortable, you're not going fast enough."
How quickly can you move your organization to a virtual desktop computing paradigm? At what speed are you comfortable and can you afford to do it slowly and gradually?
A little while ago, I read Brian Madden's piece on why customers DON'T want to implement VDI (http://bit.ly/8lE8YF), which made me think about these questions. After skimming through some of the comments, a pattern appears to emerge. Apart from the (perceived) technical complexities of a VDI solution, there is a lot of angst and politics involved, according to the commentators.
Today's IT departments are often organized along technical silos that reflect the departmentalized technical responsibilities of the client-server computing model.
Adding virtual desktops to a "classic" IT environment requires touching multiple silos. Technical architectures are spanning client and server operating systems, server virtualization, storage, application integration (or virtualization), thin client computing etc.
This is where the perception of complexity is coming from. In reality, building and running a virtual desktop solution is easier than the traditional model in many respects, but requires broadening one's knowledge to cover the areas unknown today. IT professionals are encouraged to embrace the relevant new areas as it positions them to assume leadership roles once the organization moves towards virtual desktops.
CIOs face a slightly different challenge. They must get the right skill set together in order to design and build a virtual desktop solution and then change the organization to align with the new computing model. This will inevitably involve retraining or replacing current employees and restructuring of the org chart. These are sometimes painful changes to make and should not be taken lightly. However, most CIOs and their C-level colleagues in an organization look at the promise of cost reductions associated with moving to virtual desktops. The ROI benefits of such a solution are based largely on reduced operating costs and cheaper hardware at the end point.
I stipulate that the most effective (from a cost / ROI point of view) way to implement virtual desktops is to go all out and shoot for a big-bang , wall to wall transition into virtual desktops. Instead of thinking about a small IT "project", think about "Phase 1" of the virtual desktop adoption. This approach has several distinct advantages over the often practiced, tippy-toe approach to a few users here and there:

1. If you are a CIO, it requires you to get your leadership together and plan a project carefully. Discipline in clear thinking at this stage makes all the difference - just like a smooth landing is preceded by a well executed approach. Enlist the help of outside consultants who have done this a couple of times to avoid re-inventing the wheel . This planning phase also allows for the identification of key people in the organization who have acquired some knowledge in the field and are positioned to run the operational aspects after the initial go-live.
2. While the actual go-live and the associated cultural transition is bigger, the big-bang approach limits the time of pain and suffering (lots of initial user questions, 24/7 user support, working the bugs out of the system and processes) to a relatively short period of time, compared to years of singing the roll-out blues.
3. Cost savings: If ROI is a major driver towards desktop virtualization, here's where the gravy will be. The faster the transition to a new organizational model, the faster the old silos can be broken down and support personnel can be reduced in number or retrained. Otherwise, the organization would need to keep most PC support technicians on staff for the large number of physical desktops and hire ADDITIONAL resources to support the virtual desktops.

In this context it is important to state that ROI benefits must be based on the actual CAPEX and OPEX reality, which is different in each company. Generic ROI calculators often assume industry-standard values for server and desktop support costs per unit and can vary significantly between organizations. Examining those operational costs closely can also help identify current areas of unnecessary redundancy and duplication.
In summary, the IT department leveraging virtual desktops as the primary and de-facto way of delivering applications and data to users features an org chart which is fundamentally different from today's reality in most organizations. The change can be painful - therefore, the successful transition is swift, well executed, and is planned with the end in mind.

I can already see some of our friends in the industry replying to this blog by stating that Citrix requires a risky wall-to-wall go-live in order for promised ROI/TCO benefits to materialize.
No, that's not what I am saying. ROI calculators are great tools if used properly in the context of actual values in an organization. Generic statements are often based on industry averages and must be validated before delivering realistic projections. Some of our friend's VDI solutions actually don't significantly reduce or eliminate the desktop support team at all - it just moves their work to the datacenter. Unlike the virtual desktop approach supported by Citrix FlexCast (as little as one desktop image for all users, solid application virtualization, streamed operating systems to the end-point, etc.), VDI still has one desktop for every user and doesn't leverage the "power of one". The problem just moved to the datacenter, but didn't fundamentally change. Not bold enough! I am not even saying that your organization will achieve a specific ROI on your virtual desktop implementation. Too much depends on your current operating model, cost structure, and use cases. All I am saying is that whatever ROI /TCO you calculated , you should strive to changing the computing model fast - otherwise you risk cost overruns and therefore reduced ROI benefits.
Again - start with the end in mind and pledge to replace all physical desktops with virtual ones by a certain date .

Citrix actually offers a couple of things that support you in your resolution:

• XenDestkop 4 Trade-up program for XenApp customers: Get a better trade-up ratio if you trade ALL of your XenApp licenses: http://bit.ly/4EIM0u
• 1,000 Desktops. 90 Days. In production: A fast deployment methodology offered exclusively by Citrix Consulting to get a scalable architecture in place and have a significant number of users in production in a short period of time: http://bit.ly/4E4iih
• A modular design approach to the virtual desktop solution provided by Citrix Consulting Solutions: http://support.citrix.com/article/CTX124087
• Enterprise Licensing Program. Specific discounts - the more you buy, the larger the discount. This should help with the wall-to-wall approach: http://bit.ly/8TNoJS
• Citrix Consulting architects will continue to cover topics on planning and executing the transition on these pages in the future.

Please share your thoughts and comments.
Follow me on twitter @florianbecker

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

Well, OK, that's a bit fanciful but we can certainly help.

Citrix Worldwide Consulting Solutions is focused on gathering and compiling information from the field so that we can share the information with you, the hardworking men and women tasked with bridging the gap between the CIO's vision and IT's reality. Where the "desktops hit the ether" as it were.

Working closely with our team of worldwide consultants we have put together a Modularized Reference Architecture for XenDesktop that can be used as a blueprint for architecting successful XenDesktop implementations. This is the real thing. All of the design considerations and methodologies in this document have been proven in the field and verified in the Citrix Solutions Center lab.

The concept of a modularized approach is built on the notion that each customer is unique but that many share a core set of requirements and objectives. A modularized approach solves for these core requirements by creating a platform that is highly resilient, flexible and scalable. With the platform in place we use a set of discrete modules to customize the platform to suit each customer's individual needs and objectives. Sounds simple enough, right? Check it out and let us know what you think.

The document "A Modular Approach to XenDesktop Architecture" is available for download here.
To learn more about the companion Citrix Consulting Offering "90 Day XenDesktop Implementation Methodology" click here.

Al Grandville

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

'It depends'.That's the answer to the question "How many desktops will I get on a Server?", "Which FlexCast model should I use?" and the ever popular "Are you going to finish that?" OK, that last one's a joke but the first two aren't. As part of Citrix's consulting team I get to travel the world and talk to all manner of customers who want answers to these questions. Of course, it would be nice if the answers were straightforward ones like "75", "VM Hosted Desktops" and "No", but you can have the rest if you like" but they aren't. Creating solutions that are tailored to each customer's environment and that take into account business objectives, constraints and expectations takes careful analysis and thoughtful consideration. Not everyone runs the same set of applications nor do they all have the same budget considerations, infrastructure challenges or tolerance for system downtime. XenDesktop is a feature rich, sophisticated, enterprise platform that is capable of solving a wide array of business challenges. It's not a vending machine that dispenses desktops. I mean, don't get me wrong, we could roll one physical server into a datacenter and start delivering desktops in just a few hours. In fact, we do it all of the time when we set up Proof of Concepts(POC's). It's just never a good idea to promote your POC to Production and there are very good reasons for that. While many IT projects impact the users there are few with the potential of being as impactful as a move to virtualized desktops. The most successful XenDesktop projects are the ones where a detailed design and plan are in place before the implementation phase of the project begins. My team "Citrix Worldwide Consulting Solutions" is focused on gathering real world intelligence from the field and disseminating it in the form of White Papers, Tech Talks, Design Guides, Reference Architecture, etc ...

If a XenDesktop implementation is in your future please take a look at:
XenDesktop Design Handbook
Designing an Enterprise XenDesktop Solution
1,000 Virtual Desktop Users in 90 Days LIVE

We are also putting the finishing touches on a new White Paper that details a Modularized Approach to XenDesktop Architecture which we will make available shortly.

Al Grandville

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