When is RDS/XenApp not enough?

Posted: December 1, 2011 in Uncategorized, XenApp
2

When working on desktop transformation designs, many start with the VDI (personal) model. I tend to go for the RDS (Shared) model. There are many reasons why, but mainly it is because

  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

 

iPad + Windows 7 = Uncomfortable

Posted: November 9, 2011 in Uncategorized
1

When starting to transform a desktop, many people get stuck at one of the first decisions: What type of virtual desktop should I implement? (VDI, RDS, Local VM, etc) There are so many options for so many use cases that we are stuck analyzing our users until we confuse ourselves even more. The problem is we are trying to start by dealing with all of these exceptions. We let all of these unique use cases confuse and stall our efforts. This is why when doing desktop transformation; you need to start with the easiest use cases first. This isn’t because we can’t do the difficult use cases; it is that as the project team, you need to show progress. And the easiest use cases will allow you to show success quickly.

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

XenApp is The First Step.

Posted: November 4, 2011 in Uncategorized
Tags: , ,
0

I’ve heard many people talk about how to start their desktop transformation projects when they are looking at 5000 desktops. How do you even begin? The number of desktops, users and applications is so overwhelming many can’t even figure out how to begin. The desktop environment is so vast that making any change looks impossible. But it isn’t impossible if you start correctly.

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 9th 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

Ask the Architects in Barcelona

Posted: October 6, 2011 in Uncategorized
1

If you could ask a Citrix consulting architect a question, what would it be? Would you ask a specific design question about your environment? Or would you focus on better understanding a XenDesktop concept? Or would you ask them who their favorite Star Trek captain is (Benjamin Sisko)? What if you could ask 8 architects? Well, Synergy Barcelona is your chance. Not going to Barcelona? Don’t stop reading yet.

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

How we decided between Kaviza, XenDesktop or XenApp

Posted: September 14, 2011 in Uncategorized
Tags: , ,
12

I’ve been absent from the blogging world for some time due to summer holiday and working on two different projects with two new technologies (Kaviza and CloudStack). In the future, I’m might be able to talk about CloudStack items, but today the focus is on Kaviza.

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

XenDesktop Kaviza
Server Specs VMs
Server 1 8 cores

96 GB RAM
  • VM 1: SQL Database / License Server (2vCPU,2GB RAM)
  • VM 2-51: Windows 7 Virtual Desktop (2vCPU, 1.5 GB RAM)
  • VM 1: Kaviza kMGR VM (1vCPU, 1 GB RAM)
  • VM 2-51: Windows 7 Virtual Desktop (2vCPU, 1.5 GB RAM)
Server 2 8 cores

96 GB RAM
  • VM 1: SQL Database / License Server (2vCPU,2GB RAM)
  • VM 2-51: Windows 7 Virtual Desktop (2vCPU, 1.5 GB RAM)
  • VM 1: Kaviza kMGR VM (1vCPU, 1 GB RAM)
  • VM 2-51: Windows 7 Virtual Desktop (2vCPU, 1.5 GB RAM)
Server 3 8 cores

96 GB RAM
  • VM 1: XenDesktop Controller / Web Interface (2vCPU, 2GB RAM)
  • VM 2-51: Windows 7 Virtual Desktop (2vCPU, 1.5 GB RAM)
  • VM 1: Kaviza kMGR VM (1vCPU, 1 GB RAM)
  • VM 2-51: Windows 7 Virtual Desktop (2vCPU, 1.5 GB RAM)
Server 4 8 cores

96 GB RAM
  • VM 1: XenDesktop Controller / Web Interface (2vCPU, 2GB RAM)
  • VM 2-51: Windows 7 Virtual Desktop (2vCPU, 1.5 GB RAM)
  • VM 1: Kaviza kMGR VM (1vCPU, 1 GB RAM)
  • VM 2-51: Windows 7 Virtual Desktop (2vCPU, 1.5 GB RAM)
Server 5 8 cores

96 GB RAM
  • VM 1-50: Windows 7 Virtual Desktop (2vCPU, 1.5 GB RAM)
  • VM 1: Kaviza kMGR VM (1vCPU, 1 GB RAM)
  • VM 2-51: Windows 7 Virtual Desktop (2vCPU, 1.5 GB RAM)

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.

Older Entries
Newer Entries