Extending the blueprint to focus on your resource layer


Users

Access

Resources

The Resources layer is the next stage of the blueprint.

Resources are the desktops and applications that we want to deliver to each user. This is also where many people get stuck because the perception is that there are a lot of options. There can be a lot of option until you start looking at it from a user group per user group perspective. Plus, when we look at the resources we want to deliver, we focus on a few core areas. If we look at our blueprint, we can break this down into 3 different user groups:

  • Road Warriors who we defined to use On-Demand Apps
  • Call Center users who will use the Shared (non-persistent) model
  • Engineers who use the Personal (persistent) model

Based on these groups, we define the following:

Road Warriors Call Center Engineers
Operating System Windows 2012 Windows 2012 Windows 7
Provisioning Method MCS MCS MCS
Corporate App Integration Installed into image Installed into image Installed into image
Personal App Integration Local App Access N/A Personal vDisk
Profile Citrix Profile Management
(standard config)
Citrix Profile Management
(standard config)
Citrix Profile Management
(standard config)
Policys(s) For users accessing through NetScaler Gateway: Optimized for WAN: Users Policy (Template)
For users NOT accessing through NetScaler Gateway: High-Definition User Experience Policy (Template)
For defined AD Groups: Mobile Experience policy (Custom)

And with this, we update our conceptual architecture as follows:

That’s all there is to the resource definition of the blueprint. Sure there are a lot of policies and profile settings you can manipulate, but why not start with the standard templates? These will cover a large percentage of use cases. If you need to customize then feel free to do so, but with the templates, you don’t have to start from the beginning.

Daniel – Lead Architect

Advertisements

Blueprint for Accessing your desktops and apps


Based on the XenDesktop 7 Blueprint, we have already created a definition of our user layer. The next step is to define how users will access their environment. Just like a house, you have doors and locks. In order to gain entry, you have to have the right keys for the right door.

Defining the access layer is basically focusing on the required access policies for internal vs. external users. What’s an access policy? It is simply defining the following 4 items:

  • Authentication point: Where do users first enter their credentials. Typically, this is either StoreFront or NetScaler Gateway.
  • Authentication policy: How many and what type of authentication must users provide before access is granted. Username, password, RADIUS, etc.
  • Session policy: Will different devices receive different levels of access? Some people want to provide a different access experience based on their device being either mobile (iOS, Android or Microsoft tablets and phones) or non-mobile (such as Windows, Mac®, Linux). In order to do this, the NetScaler Gateway must be able to determine the endpoint device type. This is accomplished by using the following expressions:
    • Mobile Devices: The expression is set to “REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver” which is given a higher priority than the non-Mobile device policy to ensure mobile devices are matched while non-Mobile devices are not.
    • Non-Mobile Devices: The expression is set to “ns_true” which signifies that it should apply to all traffic that is sent to it.
  • Session profile: What network connection will users be granted: Full VPN or ICA Proxy. Full VPN provides the endpoint with full access to the internal network while ICA Proxy only allows the ICA protocol access.

As you can imagine, there are many options for these 4 items, but here is what most people use

Users connecting from… Local, trusted network Remote, untrusted network
Authentication Point StoreFront NetScaler Gateway
Authentication Policy Simple authentication

(username and password)

Multi-factor authentication

(username, password and token)

Session Policy Not applicable Mobile and Non-Mobile
Session Profile Not applicable ICA Proxy

And with this, our diagram continues to evolve

We have now included the following:

  • User group location
  • User group end point device
  • Full Access layer communication
  • NetScaler added as an Access Controller in the Control Layer

Stay tuned for the Resource Layer…
Daniel – Lead Architect

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

Do you have your XenDesktop 7 Blueprint?


Here is a little secret… Most XenDesktop environments are extremely similar. In fact, if you ignore the numerous hardware combinations out there, the similarities increase greatly.

You have user groups (some internal and some external) that need access to some type of resource, whether it be a desktop or an application, which is supported on a standard set of controlling components all running on some type of hardware combination.

So why is desktop virtualization so complex? Because we made it that way by believing that every deployment must start from scratch.

Think about if you were going to have a house built. You would start with a high-level blueprint. The first thing you do is figure out what type of house you want built: a rambler, split level, 2-story, etc., but it will have the same fundamental components (HVAC, electrical, plumbing, framing, roofing, etc). However, the first things you think about shouldn’t be the electrical wiring. It would be insane to start here because you don’t even know where the walls are going to be located that will contain the wires. So tell me why when doing desktop virtualization do people start with storage or servers?

This is why we have a XenDesktop 7 blueprint. To guide you on your way towards creating a desktop virtualization solution, every XenDesktop 7 solution has 5 parts:

1. User Layer – Defines the unique user groups and overall requirements.

2. Access Layer – Defines how each user group will gain access to their resources with a focus on secure access policies and desktop/application stores.

3. Resource Layer – Defines the virtual desktops and applications assigned to each user group

4. Control Layer – Defines the underlying infrastructure required to support all users accessing their resources

5. Hardware Layer – Defines the physical implementation of the overall solution

This is the framework to understand how all layers build upon the previous layer. When you begin to develop your solution’s conceptual architecture, it begins to resemble the following:

As we work through the layers in future blogs, we will see how this structure will take shape and what decisions you really need to make.

Stay tuned…
Daniel – Lead Architect