One of the biggest challenges with desktop transformation is what to do with all of the applications. IT cannot manage all of these applications nor should we expect them to. For some time, I’ve provided an application delivery strategy that focused on a few categories for applications and an appropriate delivery strategy.  With Personal vDisk, do we throw the model out the window and simply say that all applications are done with Personal vDisk? It should work, but it isn’t a great strategy. I suggest we stick to the original recommendations for 3 of the 4 categories as follows:

But what do we do with the anomalous applications?

1. Retire the applications that haven’t been used in some time (I suggest 6+ months).
2. Get rid of the applications that are different versions, unless there is a need for an older version.

These two steps will greatly reduce the number of Anomalous applications you have to consider. The remaining applications are where your environment will be unique. You have the following options

• Install/Host applications from XenApp
• Install applications into desktop
• Stream applications to desktop
• Personal vDisk the applications

Guess what? All 4 options are correct for anomalous! These will not break your environment, but it will impact it by requiring more XenApp servers, more desktop images, more streamed packages or more more hardware for VDI users.

Which option is the right one? It depends on the skills and resources you have within your organization as well as what type of virtual desktop the users of the application are using:

1. Application only used by a subset of Shared Desktop Users: Install into a Worker Group and publish the application
2. Application used by Shared Desktop Users and VDI users: Install into a Worker Group and publish the application
3. Application used by only a subset of VDI users: choose one of the three options based on your skillset
   1. New Image: Appropriate for organizations that have strong image management skills
   2. Stream: Appropriate for organizations that have strong application streaming skills (XenApp Streaming or App-V)
   3. Personal vDisk: Appropriate for remainder of organizations

The updated model looks like the following (this is the first major update to the model in 3+ years)

The thing to remember, all models work for Anomalous, you just have to decide what you want to do. And you will most likely be doing a combination of the models. Think about it. If I have an application used by VDI and Shared desktop users, I will most likely host the application. But if the application is only used by VDI users, I might utilize Personal vDisk.

Daniel

XenDesktop Design Handbook

I’ve been a proponent of a desktop operating system and of desktop virtualization. Being a workshifting Citrite (what we call Citrix Employees), I use a VDI desktop every day. In fact, I’m creating this blog in my VDI desktop. Many months ago in another blog, I discussed we shouldn’t ignore or dismiss the desktop operating system yet. I said we need to focus on the users and not so much on the technology.

As I see it, the current desktop model allows users to consolidate all of their resources into a single repository. It could be better. For my job, I usually have 4-5 simultaneous projects where I am actively working on materials daily. I’m also a member of many virtual teams (more than I can typically remember) where I’m active on a weekly/monthly basis. So what happens is this:

1. I have many browser favorites defined to each team’s sites
2. I have many OneNote notebooks with bits of information for each project/virtual team. Many of these are from email discussions that I want to keep
3. I have shortcuts after shortcuts linking me to the projects/virtual teams’ files.
4. I get emails for each project and virtual team constantly, but many are out of context as it is difficult to remember what this is in reference to. I save many of these into my OneNote notebooks for reference.
5. I use Outlook to organize my delivery dates for different items for the different projects and teams.
6. I get a new application that is for one of the virtual teams

I don’t think I’m alone in these challenges. There is a lot for me to maintain as I’m sure many others do the same thing. There is a lot going on. My Windows 7 virtual desktop pulls all of these things together.

At Citrix Synergy 2012, I was listening to the keynote and watching the demo of Podio. I started to wonder if Podio is the next step in the evolution of the desktop. Can Podio consolidate all of my resources together better than a desktop can? If I were to go full throttle into Podio for my work, it might look something like the following

• Each project or virtual team would have a designated workspace that I’ve subscribed to. All discussions would happen within Podio.
• Any piece of information or file created, referenced, or reviewed for the project or virtual team would be incorporated into the Podio workspace
• Any application needed for the project or virtual team would be integrated into the workspace
• All milestones, timelines, people associated with the project/virtual team should be defined within the workspace
• The experience should be the same for my iPad, my personal Windows laptop, my home PC, my phone, etc.

If these things happen, Podio might be the next generation desktop for me. Podio not only consolidates all of my resources into one location, but Podio also organizes these resources into projects or virtual teams. If all of my projects and many of these virtual teams move to Podio, does that mean I will spend most of my day within Podio and less time in Outlook? Do I still need a Windows desktop? This is something I’m going to try.

Who would have thought the desktop could get interesting J

Daniel Feller

XenDesktop Design Handbook

• Host Risk: At the base level, we have a hypervisor host (XenServer, Hyper-V or vSphere). Depending on the hardware and user workload, I’ll be running somewhere between 50-100 virtual Windows 7 desktops on each host. If the host has a catastrophic failure, those desktops go offline. Users will try to reconnect and they will be sent to other hosts. This is why we recommend N+1 at a minimum. If you lose one host, you should have at least one extra one to take over. If you lose a host, you can expect most of those users to try to reconnect immediately. Trying to support 50-100 connections is easy.
• Pool/Cluster Risk: One level higher than the host is a group of hosts in a pool or cluster. You will probably have around 800 desktops in a pool/cluster if we assume you have 10 hosts in a cluster. What happens if we lose the cluster? Depending on the type of failure, you will have one of the following:
  • Connection Failure: If you have a failure where the pool/cluster controller fails, you won’t be able to launch new desktops, but currently active users will be unaware of any issues.
  • Pool/Cluster Failure: If you lose an entire pool/cluster, you have to find a place for those 800 desktop users. Again, if you have N+1 fault tolerance, you probably have spare capacity within your entire environment. You also need to make sure your infrastructure can support 800 users trying to connect simultaneously. This still isn’t that big of a connection storm.
• XenDesktop Site Risk: One level higher that the pool/cluster is a XenDesktop Site. A site could contain 20,000 desktops or more. But what happens if we lose an entire site for some unknown reason? This is rare, but anything can happen. Remember, once users are connected, they can work unless their host fails. But if the site experiences a catastrophic issue during the logon storm we should have an N+1 fault tolerant solution, which means we have to find a place within our environment to support 20,000 extra desktops that will only be used for fault tolerance.

Hopefully, this all makes sense so far. But 20,000 desktops is a huge number. The amount of hardware required to support an N+1 solution for 20,000 desktops is a lot. What if we create four XenDesktop sites with only 5,000 desktops? I’m still supporting 20,000 desktops, but because they are in different XenDesktop sites, the overall risk is greatly reduced. If something happens to one site, it shouldn’t impact the other three sites. Those 5,000 users in the failed site can be balanced across the other sites or into a 5^th site that is only used in the event of a major failure (active/passive deployment).

A comment I always hear with this approach is now I have to manage 4 or 5 XenDesktop sites. You do have to manage more sites, but you really aren’t managing additional components. With proper processes and scripts, many of these management tasks can be simplified.

Just because XenDesktop 5.x can support tens of thousands of desktops, you need to determine if that is indeed the best approach for your business.

Daniel – Lead Architect
XenDesktop Design Handbook

Let’s say you need 100 servers (192GB RAM) to host virtual desktops for 7500 users. Those 100 servers will reach maximum capacity (CPU and Memory) when they host 75 virtual desktops VMs (2.5GB RAM). For fault tolerance, you go with the N+10% formula where you will have 10% more servers than you need. That means you really have 110 servers.

As I spread the load across 110 servers, my server concurrency drops from 75 users per server to 68. That also lowers my RAM usage from 187GB to 170GB. I paid for the RAM, so I want to use the RAM.

In this example, being conservative, I will configure the upper memory threshold for the desktops to 2.8GB RAM each and the lower to be 2.5GB (which is what I determined these users must have).

Based on the example, during normal production mode, my desktops are not overcommitting RAM. However, during an outage (planned or unplanned), my servers will be required to host additional desktop VMs. As no RAM is free, the desktop VMs are overcommitting, although spread across the entire server and the entire environment, the impact is small and likely to go unnoticed. Additionally, the overcommitting only occurs during an outage. So day-to-day operations continue to run smoothly and provide a good user experience (at least from a RAM perspective).

What have you used on your deployments?

Daniel

XD Design Handbook

Unfortunately, trying to explain my point in 140 characters wouldn’t do it justice but a blog is a start.

The key point is that we need to focus on the users. When you look at how users work with these systems, you understand what they need in order to work effectively. We look at the applications as a way to get to the data. We decide if the user needs access to the application, and it is either granted or denied. If we ignored the desktop interface, things would be much easier. I already have a desktop interface, so why do I need another. My local desktop interface has my own applications, so simply let me subscribe to virtual applications. This would alleviate the user-installed application challenge. If you only focus on the applications, you are missing an important aspect because this model doesn’t work for everyone. Let me give you some examples for and against having the desktop interface delivered:

• iPad: I don’t want to use the Windows desktop interface on my iPad as it doesn’t feel natural (Windows 8 might change this, but will wait before deciding). On the iPad, I just want to get to one or two of my applications. So in this case, I want to ignore the desktop interface.
• Work-shifting: I work remotely on my company-owned laptop (Windows 7). If IT only gave me applications, things would feel unnatural. They could populate my start menu with my apps, but it wouldn’t feel right. I would need 2 Windows Explorers (one on my personal desktop and one for my virtualized environment). I would need two browsers (one for my personal and one for my virtual). Which one do I use? I’m not on the internal network, so I need to make sure I use the right one. Not user friendly and very unnatural. In this case, the Windows desktop is a requirement as it makes the user experience better.
• BYO: A user brings their device and uses it at work. From a technical perspective, delivering virtualized applications would work fine. Unfortunately, we aren’t looking at the user perspective. A user will not want corporate applications on there. They don’t want those applications to consume hard drive space, nor do they want it polluting their start menu. Virtualizing the applications could overcome these issues, but the user’s perception is that the applications are local. Even training the users about application virtualization would not be enough as many users believe big brother is still watching. Plus, there will be confusion of having the corporate web browser and your local web browser (I hope you are using the right one, or you might get into trouble). Users in a BYO program want to use their own device, but still be given a “Corporate” environment to work on.
• Local Corporate Device: You have a physical desktop (running Windows 7) located on the corporate WAN, so why do I want to deliver another desktop interface on the one I already have? You probably don’t, so simply deliver applications.

We love to talk about being able to do all of these cool things with virtualization and what the future will hold, but people tend to ignore the typical user and their perspective. This perspective and the comfort of using the system are what makes things succeed or fail. If the solution doesn’t feel natural, it won’t work. And I say that only focusing on applications and ignoring the desktop interface, you are ignoring the user and only thinking about some pie in the sky utopia.

If we treat the desktop interface (XP, Windows 7, RDS) as an application, you must assess the need for the interface using the same criteria you use for applications (end point device, user usage requirements, location, etc). If you treat the desktop as a desktop, you will surely go down the road believing the desktop interface is irrelevant only to find that users are unhappy with the application virtualization solution, thus killing user acceptance.

Not everyone requires a corporate-delivered desktop interface, but many do and we cannot ignore this need.

Daniel – Lead Architect
XenDesktop Design Handbook

1. Scalability: Most agree that a shared desktop environment achieves better scalability than personal desktop environments.
2. Storage: Due to the shared operating system, the impact on storage is mostly a non-issue
3. Security: Although a desktop can be secured, I typically find that people do a better job securing desktops in the shared model

Like I said, I usually start with the XenApp model, but as we all know, one size does not fit all. There are occasions where the personal desktop model is required. Every time I say this, I get many questions asking what for the user requirements that XenApp cannot provide. Here is a start:

1. Reboot control: Can you imagine if you let users reboot a XenApp server. Talk about a great way to tick off your coworkers
2. Admin rights: I hate to say it, but some users require admin rights. Doing this on a shared desktop will cause many issues.
3. Specialized hardware: Some users need powerful graphics cards or sound cards. It is often easier to do this in a personal (VDI) model
4. Backgrounds: Many users want a picture of Homer Simpson on their desktop background. Silly, that can be done with shared or personal. This is NOT a valid requirement to go to a personal desktop.

Of course, I’ll save the most common one for last…

1. User Applications: Certain users need to install their own applications. Doing this on a shared model is scary, but on a personal model, makes a lot of sense.

What other areas do you see are viable user requirements that would dictate the need for a Personal (VDI) desktop instead of using the Shared (RDS) model?

Daniel – Lead Architect
XenDesktop Design Handbook

Honestly, when looking at the easiest use cases, it is a pretty safe bet to go with a shared desktop model (RDS/XenApp). Although many don’t talk about the shared desktop model much because everyone is so focused on VDI, it is an approach that is tried and tested. In fact, I remember working with an organization in 1998 that was doing desktops on the predecessor of RDS/XenApp, which was called Windows NT 4.0 Terminal Services Edition with MetaFrame 1.0. And guess what… It worked

Of course you can find loads of information talking about how the shared desktop model is more scalable than the personal desktop (VDI) model, but one aspect that is always missing is Comfort.

Oh my, one of these “marketing” words right? Yes, but here is what I mean.

If I do a personal desktop (VDI), I will get a Windows 7 desktop with applications and it will work. If I do a shared desktop (RDS/XenApp published desktop), I will get a “Windows 7″ desktop with applications and it will work. However, I also get something else. I can also access the applications seamlessly, where the desktop interface is hidden from the users view (some people call this a published application or seamless apps)

Many of you old-time XenApp users are thinking, big deal. We’ve done this for ages. Correct, we have, but now we have people trying to access the desktops/applications from tablets and phones. On my iPad or Android phone, I first had access to my Personal desktop (VDI). It worked, but it wasn’t comfortable and I’ve heard people say it was unnatural. I tend to agree. It was too hard to launch apps. If I’m trying to launch an app from the iPad, why do I want to first go to the Windows 7 desktop? Ummm, I don’t. I just want to launch an application. If I start with the shared desktop (RDS/XenApp), I get to choose between a full desktop and a single application, whereas the personal desktop (vdi) requires me to use the full desktop.

When starting desktop transformation, start with the shared desktop (RDS/XenApp). Work through the user groups that can work in a shared desktop environment. Once those groups are complete, we move onto the exceptions, which are probably fewer than you think. Stay tuned for more

Daniel – Lead Architect
XenDesktop Design Handbook

You have to learn to crawl before you can walk. You have to learn how to walk, before you can run. For those of you who are hosting applications via XenApp, you are already crawling. And learning to walk is pretty easy and takes little time.

Think about it, you have a hosted infrastructure built. You are using HDX. You already are managing your line of business applications. You have already started transforming your desktop; we just need to go a little further.

And those extra steps are what we will discuss during the next Ask the Architect TechTalk on November 9^th at 2PM Eastern Time.

Don’t forget to register and get it on your calendar. I’m looking forward to seeing you there.

Daniel – Lead Architect

As you might have seen, Citrix Consulting is presenting a 5-part series on desktop transformation. We are splitting the series up into the following concepts:

1. Desktop Transformation overview and user segmentation
2. Architecture design
3. Storage
4. User experience

The observant people reading will notice I only have 4 topics but it is a 5-part series. Unfortunately, most of the time at conferences you sit there listening with little time left to ask how things relate to you. Well in Barcelona, things are different. Part 5 (SYN310) is called “Ask the Architects”. We will have consulting storage experts, architecture experts, HDX experts and business experts on stage ready to answer your questions. Not only that, we will also be able to speak in English (UK), English (US), German, Spanish, Italian, and maybe a few others.

I hear some people already saying “But I can’t go to Synergy Barcelona because I went to Synergy San Francisco instead”. Well, you are not out of luck either. Feel free to post a question in the blog. If it ranks high enough, we will try to answer it in Barcelona and potentially future blogs. Hopefully, you are registered or are planning to register and I will see you there.

Daniel
Twitter: @djfeller
Blogs: VirtualFeller.com

The project I’ve been involved with is focused on delivering desktops for 200 concurrent users. We had three options: XenDesktop pooled desktops, XenApp hosted shared desktops, or Kaviza pooled desktops. Here is how we made our decision to go with Kaviza.

Skillset

The first thing we quickly realized was that the IT staff has no experience with a XenApp infrastructure. XenApp isn’t rocket science, but it does require a different way of looking at the desktop and managing the desktop because your users share the same running instance of the OS. For those of you who work with XenApp, you know what I’m talking about. Because of the required skillset to implement XenApp, this was the first option we removed from consideration.

Resource Requirements

The organization isn’t sitting on piles of cash, so we wanted to pick either XenDesktop or Kaviza that would require the fewest number of servers. First, we assumed:

1. Expectations are that each user will required roughly 1.5GB of RAM
2. Each user will be granted 2 vCPUs, although utilization will remain minimal

But guess what? The hardware requirements didn’t change

For XenDesktop, we have 4 VMs dedicated for management activities. For Kaviza, we have 5 (one for each server). Remember, we have 5 servers because we need one extra server in the event of a server failure. Based on our estimates, XenDesktop and Kaviza will require the same hardware footprint for 200 users.

Infrastructure Requirements

The final aspect we focused on was the infrastructure requirements. This might sound similar to the previous, but it is slightly different. By infrastructure, we mean the systems required to support XenDesktop or Kaviza. For XenDesktop, we have to build a SQL database, XenDesktop controllers, license server and Web Interface servers. Many of these items are automated to make installing and configuring easier, but with Kaviza, this functionality is contained within the Kaviza Manager. That means fewer technologies to support. And for this particular organization, that was the key criteria for going with Kaviza.