Taking Virtual Desktop Optimization Too Far

I’ve been spending a lot of time focusing on the lessons learned with Windows 7 migration. There are plenty of articles about optimizing the Windows 7 image (I’ve even authored a few of them in my Windows 7 Optimization section). However, I am left to wonder if some of these recommendations go too far.

Most users want to personalize their desktop. They want to configure their own backgrounds. They want to configure their themes. They want desktop sounds to alert them of email messages. So why are we recommending that we disable all of these features?

To save resources. Yes. That is the answer, but is it a good strategy? Disabling this functionality will save some network and system resources but the cost is user acceptance. User acceptance is going to make or break the desktop virtualization solution. You don’t believe me? Look at your own desktop. Did you customize the background? Sounds? Themes? What else? What would you say if you couldn’t do these things?

What would you say if Microsoft or Apple lacked this personalization functionality? They wouldn’t hear the end of it. They would be criticized by every person that touches the OS. So why am I seeing so many Windows 7 optimization guides recommend doing just that?

There is nothing wrong with optimizing the desktop, but these optimizations should not impact the overall acceptance level from our users.

Daniel – Lead Architect


Deciding How to Integrate Applications into a Virtual Desktop

A customer asked me, in fact many customers have asked me this question, “I’ve got a XenApp environment and I want to add virtual desktops for my users. What is the best way to integrate the applications?” My response, “It depends”.

And like all things in the IT world, most decisions do depend on many factors like:

  • Are the applications used by many users?
  • Are there a lot of dependencies?
  • Are we dealing with legacy or new applications (16bit, 32bit, 64bit)?
  • Do these applications need to be available offline?

This is only a few questions that should be part of your application integration portion of the virtual desktop design. If we go back to the example where an organization has most of the applications hosted on XenApp and they implement virtual desktops would they keep the applications on XenApp or move? If you keep all of the applications where they are, and you provide your users with a Windows 7 virtual desktop, then why do they need this Windows 7 virtual desktop if all it is, is a nice front-end to the applications? If you wanted to give your users a virtual desktop, you might be better off with a Hosted Shared Desktop made to look like Windows 7.

However, most organizations are not to this point with XenApp. Many have a few applications on XenApp and a massive number of the end points. This is where the analysis questions come into play. The first thing I like to do is create a high-level categorization of the applications to get started. I’ve been using the following for a few years now and it provides a great way to begin.

Application Categories



Resource Intensive

Technically Challenging

Common apps needed by all users Unique custom built apps

Uncertified Terminal Services support

Have heavy system requirements Large, complex apps with many moving parts and dependencies

Frequent updates

Example Microsoft Office (Word, Excel, PowerPoint, Outlook), Adobe Acrobat CAD/CAM, data processing Epic, Cerner, SAP
Primary Delivery Method Installed on Desktop Virtualized on Desktop Virtualized on Desktop Installed on Server
Alternative Delivery Method Virtualized on Desktop Installed on Server

Installed on Desktop

Installed on Server

To go further, you need to align user requirements with application characteristics. This is where I suggest you read the Application Integration Planning Guide that was just added to the XenDesktop Design Handbook. BTW, the handbook now supports offline syncing. Check it out. Once you select “Enable Offline”, go into your “ToGo Kits” and download the tool. Now you don’t have to go back to the site. Just launch the app and sync. Cool

Daniel – Lead Architect

Consolidate for Small Scale

The Ask the Architect email inbox is getting quite large and I’ve received some great questions. I thought I would answer a question around the small-medium business (SMB) space, as it relates directly to a recently delivered Virtual Desktops for the SMB TechTalk and the reference design included within the XenDesktop Design Handbook.

Namely, the SMB white paper focuses on use cases of 200-500 desktops, but what if you only have 50-100 desktops? Do you need all of the servers? Yes in that you will need the components if you plan to do single images but no you won’t need all of the physical hardware. For example, in the reference design, there were the following infrastructure components:

  1. XenDesktop Controller/Web Interface (*2)
  2. Data Store/License Server
  3. Provisioning Server (*2)
  4. NetScaler VPX (*2)

Of course all of these are virtual servers. If we are talking about 50-100 desktops, one virtual server could easily contain items 1, 2, and 3. Ideally, you would have a second VM, on a different physical server, which would contain 1 and 3 to allow you to have some level of fault tolerance (this is a decision you have to figure out). If you don’t need intelligent load balancing, remove the NetScaler VPX. Even if you need secure remote access, you could either get an Access Gateway virtual appliance or run Secure Gateway.

Once that is done, just distribute your windows desktops across the remaining servers.

It basically comes down to this… Nothing is preventing you from putting all of these items on one virtual server. If you are sub-100 desktops, that might be the best way to go to better consolidation. If it was me, I would still follow the guidelines in the TechTalk and white paper as making these separate VMs. You still get consolidation but have greater flexibility for potential future changes and can better optimize the OS for the role it is being asked to do.

Daniel – Lead Architect

How to Avoid Turning Your XenApp into Frankenstein

I just got done watching Mary Shelley’s Frankenstein the other day. You  know how the story goes. Victor Frankenstein putting pieces together to create something new. It works, but it is not what Victor expected. In fact, it is so horrible that it scares everyone and destroys all who stand in its way.

I also just got done having a discussion around virtual desktops. In this discussion, an organization using XenApp is asking the $1,000,000 question “How can I add virtual desktops to my XenApp implementation?”

It is actually quite easy, you create a virtual desktop, install Citrix Receiver, and away you go.  Great, right?  If we just add pieces together without thinking about things properly, we might end up with our own Frankenstein in the data center. Let me ask you a question. If you go down this route, then why in the world do you need a desktop if all of your applications are running as hosted XenApp applications?

Virtual desktops are going to allow us to get broader adoption of the virtualization solution throughout the organization. Applications are only part of the entire solution.  Users are more comfortable working in a desktop environment, so let’s give it to them. But how?

  • First, the integration is not hard, it just requires a proper analysis and design of your overall goals (this is the most common thing to do with a system design).
  • Second, we need to align our users needs with the solution (remember, one size does not fit all).
  • Third, we need to create an solution that is optimized and functional.

This is a great architectural discussion, which I’m sure you will get something out of.  The only caveat is you have to be registered for Synergy Berlin and attend the session SYN320 – Add virtual desktops to your XenApp implementation the easy way!

Hope to see you in Berlin

Daniel – Lead Architect

More to Availability than Live Migration

Anytime I’m in a discussion that deals with server or desktop virtualization, the topic usually heads to high availability. I usually get asked about live migration features like XenMotion. Honestly, there are many scenarios where it doesn’t make sense, but that is a discussion for later. What does matter is that your implementation continues to operate even if something has failed.

Let me give you an example of what I mean. When I design a XenDesktop environment, I typically recommend, at a minimum, two Provisioning Services server even if the environment is capable of running with a single server. We typically refer to this as N+1. The reason is that if one server fails, the other can take over the load. I’m hoping this isn’t a new idea for you as this is how many people deal with fault tolerance. However, how do we take this to the next level? How do we make our XenDesktop environment as bullet-proof as possible? Where do we need to focus our attention on?

Another example… I’ve seen many people do N+1 on their Web Interface servers. Again, this is a good practice. But now the question is how are those servers being load balanced? Are you using intelligent monitoring that checks not only availability but also that the service is functioning appropriately?

These are just two areas that will be covered in the Synergy Session “SYN208 Guaranteeing availability and scale for XenApp and XenDesktop deployments“.

  • When is this session? October 6, 17:30
  • Where is the session? Synergy Berlin
  • Why attend? Because it will be good

Looking forward to seeing you there

Daniel – Lead Architect

Fun TechTalk on XenDesktop Enterprise Design

One of the best things about my position is I get to talk to a lot of smart people, do some pretty cool things (like playing around with the iPad), and constantly learn. For example, any idea why you would modify the “Maximum Transition Rate”? Do you even have an idea what it is?

I learn about all of these things every day that helps in the overall XenDesktop architecture. I’ve come to realize that building a XenDesktop environment isn’t really that hard, but if you want to do it right so that it scales and is optimized, then you might want to brush up on the best practices. And because XenDesktop can use XenServer, Hyper-V and vSphere, the list gets longer. I’ve got some new stuff and goodies to share around storage, Provisioning services, XenServer, VMware vSphere, Microsoft Hyper-V, and Windows 7.

I thought I would share some of these recommendations with you in an upcoming Ask the Architect TechTalk (aren’t I nice? 🙂 ) Here are the wonderful details:

Oh, I almost forgot, that “Maximum Transition Rate” thingy. It is for the XenDesktop controller to determine how many simultaneous desktop startups it can do. We typically recommend the following

  • XenServer: 40
  • Hyper-V: 40
  • vSphere (without DRS): 40
  • vSphere (with DRS): 20

Attend the TechTalk and you will learn why DRS number is lower as well as many other goodies.

Daniel – Lead Architect

Screen savers and virtual desktops

If a tree falls in the forest and no one’s around, does it make a sound? If a screen saver is running and no one is watching, does it matter? You can debate me on the first question, but the second one is a definite YES.

You remember long ago when fancy screen savers were all the rage? You remember the flying toasters right (if not either I’m too old or you are too young)? What about the fish swimming leisurely across your big (14 inch) CRT monitor? We don’t put as much thought into screen savers as we used to, but they are still there. Most of us simply use the default ones within Windows 7, that is, if we have one at all. But what does the screen saver have to do with virtual desktops? Actually, screen savers have a lot to do with desktop virtualization, especially in the hosted VM-based VDI model (at least if you are trying to optimize your environment). Continue reading Screen savers and virtual desktops