Begin your XenDesktop blueprint with your users

The users matter first.

This is why we have a blueprint for XenDesktop 7 because we want to avoid starting wrong. We want to make sure that the first thing we focus on are the users.

Think about it this way, when building a house, one of the first things you have to figure out is what type of a house do you want/need (bungalow, cottage, mansion, split level, etc). Sometimes, you might determine that you don’t need a house and end up with a condo or apartment. To make this decision, you have to look at yourself and understand your needs (how much space, size of yard, number of bedrooms, etc). When defining your needs, you must not only look at today, but also look at what you anticipate the future to hold, because most of us don’t want to move houses every year.

The exact same thing takes place with a virtual desktop solution… Figuring out what type of resources you need (notice that I didn’t say “what type of desktop you need” because not everyone requires a desktop just like not everyone needs a house).

With so many housing options, many times people get stuck in simply trying to figure out what kind of house they need, or they come up with 3-4 options and can’t make that final decision. Again, the same thing happens with desktop virtualization, do I need a non-persistent, persistent or applications.

The thing we tried to accomplish with the blueprint is to provide a starting place based on numerous successful implementations. For example, what if an organization was trying to better protect information through centralization for 3 user groups with the following characteristics:

Call center users focused on getting through a large call volume as quickly as possible with as few distractions as possible.

Engineers who need to do a lot of trial and error and are often looking for alternatives to their current tools that aren’t optimal

Road warriors who are always on the go and sporadically need to enter or review a piece of information contained within a small number of applications.

Based on this scenario, we can start to create our conceptual architecture based on the framework we defined in the earlier blog.

Simply understanding your user’s high-level requirements and the overall goal of the organization helps us to start creating our conceptual architecture. Based on these three user groups, we have the following:

  • Because we want to centralize our data, we are looking at a hosted model for our three user groups:
    • Road Warriors -> On-Demand Apps
    • Call Center -> Shared (non-persistent model)
    • Engineers -> Personal (persistent model)
  • We also know that the users will need to be presented with their resources, which is provided by StoreFront. Although we know we will need StoreFront, we don’t know the details of it yet, which is better defined in the Access and Control layers.
  • Because we have these types of resources, we know this requires us to have delivery controller and infrastructure controllers. But we don’t know the details of these yet until we reach the Control layer of the design.

Stay tuned for the Access Layer…
Daniel – Lead Architect

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.