Tag Archives: XenDesktop 7

XenApp Best Practice #2: Optimize

On many moonless evenings, I will be outside, next to my telescope snapping pictures of clusters, nebula and galaxies for my astrophotography hobby. But there is a balance of creating a great image vs just wasting time. Once it gets past 2am or the temperature drops below 0 Fahrenheit, I’m done. But do I have enough pictures to create an OK photo or a great photo?

You see, in order to take a photo of deep sky objects, you need to let your camera capture a lot of light by keeping the shutter open for many minutes at a time. Of course, at the same time, you also build up noise on the imaging chip.Here is an example of a single, 90 second image of M27 – The Dumbbell Nebula


If you take and stack multiple images together, you increase the signal while reducing the noise. This is a stack of 29 frames, each 2 minutes in length for a total of 58 minutes

M27 - The Dumbbell Nebula

The image got quite a bit clearer. The signal got stronger and the noise was reduced.  Of course, the more images you take and stack, the stronger signal you achieve, but the noise is only reduced by the square root of the number of images. Don’t worry, I’m not going to go into the math for this because this graph makes the concept very clear


As I take more frames, the noise decreases. But in order to have the noise drop by another factor, I have to take many, many, many more pictures. Now I will spend hours of time capturing the extra images, processing the images and all for a minimal improvement in image quality. And while I’m outside using the telescope, I run the risk of getting frost bite (true story), going into hypothermia or get eaten by a bear a wolf or a moose (Yah sure you betcha. don-chya-no I in da Minnesoda)

The same concept holds true for XenApp and XenDesktop deployments. You can optimize and then you can optimize.

There are hundreds of ways you can better optimize XenApp. Some of these are easy, proven and will have a noticeable, positive impact on either the user experience or resource utilization. But there becomes a point of diminishing returns. For example, what benefit will I get if I disable a Windows service? Most likely, not much. And in fact, the more you tweak, the greater the possibility of doing something hazardous to your system’s health. I’ve heard many times that someone turned off some innocuous Windows service only to find out a few months later that a new application or update requires that service.

Does this mean stick with the default configuration? OMG NO.

Start with the big items. Start with those items that are proven and have been shown to improve the experience or reduce utilization without potentially harming the system stability. I’m talking about things like

  1. Provisioning Services RAM Cache: This will not only reduce storage utilization, but it will actually improve the user experience.       In the simplest terms I can provide… Disk is slow, RAM is fast. Use RAM. 🙂
  2. Microsoft Lync/Skype for Business optimization: As we see more people make video calls with Lync and Skype for Business, we see a hit on our processor. Using this XenApp/XenDesktop feature, we are able to drastically reduce resource consumption on our host servers.
  3. Session Prelaunch: Logon complaints might be one of the most common issues for any system, and I’m not even talking about XenApp/XenDesktop. But at least with XenApp, we can overcome the logon delays with Session Prelaunch
  4. Policy Templates: XenApp and XenDesktop have a very powerful policy engine, allowing you to match the user experience with the scenario. If you are external, you get this, if you are external on this device with this configuration, you can do that, if you belong to this group, you can do something else, if you are on this subnet, this desktop group, have this tag, then you get this config, and if your iOS device is jailbroken, you can only do this one thing. It is very powerful, which means many implementations don’t configure anything. Again, a great starting place is to use the latest policy templates in XenApp & XenDesktop 7.6 Feature Pack 3, as they are tailored for a specific use case.

Now don’t get me wrong, you can go and tweak the system as much as your heart’s desire, but at a minimum, you should focus on those items that can have a big impact.

XenApp Best Practice #2: For the best combination of user experience and resource consumption, optimize appropriately

Daniel ()
XenApp Best Practices
XenApp Videos


Sizing XenDesktop 7 App Edition VMs

In the Mobilizing Windows applications for 500 users design guide, we made the recommendation to allocate 8vCPUs for each virtual XenDesktop 7 App Edition host (formerly known as XenApp). Spreading this out across a server with two Intel Xeon E5-2690 @2.9GHz processors and 192 GB of RAM, we were yielding about 200 users per physical server and roughly 50 users per virtual server.

Of course, the design guide is the end result of a lot of testing by the Citrix Solutions Lab. During the tests, we had the Solutions Lab compare many (and I mean many) different configurations where they changed the number of vCPU, RAM size, and RAM allocation (dynamic/static) as well as a few other things. We ended up with the following:

A few interesting things:

  1. Dynamic vs static RAM in Hyper-V appeared to have little, if any, impact on overall scalability. The only time when the RAM allocation had a negative impact was when not enough RAM was allocated (no surprise there).
  2. The 8vCPU and the 4vCPU configurations resulted in very similar user concurrency levels. Get ready… The battle is about to begin as to whether we should use 8 or 4 vCPU. (Is anyone else besides me having flashbacks to 2009?)

A few years ago, we debated about using 2vCPU or 4vCPU for XenApp 5 virtual machines. A few years later, the debate is resurfacing but this time, the numbers have doubled: 4 or 8. Here is what you should be thinking about… VMs are getting bigger because the hardware is getting faster, RAM is getting cheaper and the hypervisors are getting better (Nick Rintalan provided a pretty good overview on some of the reasoning for this during his discussion on NUMA cores in his XenApp Scalability v2013 Part 2 blog). The whole point is that none of this is new. It has been going on for a long time and will continue to do so.

The hypervisor helped us reduce our physical footprint by allowing us to better utilize our physical hardware. Now, with better technology, we are able to reduce our virtual footprint because the technology is able to support larger VM sizes.

Daniel – Lead Architect

Just the Apps

We get so excited with the thought of VDI, we often forget to take a step back and focus on what we are trying to do. Here is a recent example…

We need to find a way to get an application to our users. Our first problem is that many of our users are not local, which makes installation a challenge. The second problem is that many users want to use the application on non-traditional devices (tablets) because it is more convenient. We’ve heard that VDI can help us with this. What will it take?

First, this is a good question, but unfortunately, the person has already decided on a solution without understanding what is possible. I can’t blame the person for already believing that VDI is the right answer because the marketing teams that are focused on VDI have done a great job blanketing us with the VDI message. And unless you are knowledgeable about the functionality with different products, you might miss the nuances and buy something you weren’t expecting.

If I were to make a recommendation with this particular customer, I would steer them to XenDesktop 7 App Edition (for those of us who have been around for some time, I’m referring to XenApp), which basically delivers an application to a user instead of the entire desktop. This solution aligns closely with what the user needs.

But what will it take for 500 users? Not much… just three physical servers using two Intel Xeon E5-2690 @2.9GHz with 192 GB of RAM.

Of course many will think this is all theoretical. But to prove this isn’t simply fairytales and unicorns, we built, tested and validated this Design guide to mobilize windows apps in the Citrix Solutions Lab (I will provide more gory details in a future blog).

When we go through the numbers and incorporate it into our 5-layer conceptual model, we get the following (Read about the XenDesktop 7 blueprint to better understand the 5-layer architecture).

This solution gets you the following:

  1. Delivery of almost any Windows-based application to any endpoint to any location without requiring the application to be rewritten for the numerous types of endpoint device types and form factors.
  2. Traffic is protected within SSL as it crosses over public network connections with NetScaler Gateway
  3. An environment, capable of supporting 500 concurrent users, with only 21 virtual servers (Note that VDI would require over 500 virtual machines).
  4. Most importantly, the entire environment is using standard local storage. There is nothing special about the local storage as each physical server includes (8) 300GB SAS drives spinning at 15,000 RPMs configured with RAID 10.

Of course this is just conceptual, so what does the physical architecture look like?

  • 3 physical servers required to support 500 users, with each RDS host supporting roughly 50 users. If more users are required, another server is added resembling the “Server 3” config. We don’t have to worry about scaling the Access and Control layer components for some time as they have low utilization.
  • Three different VLANs for DMZ, VM, and Management traffic. I know some of you will point out the risk with putting the NetScaler Gateway VPX on internal servers and having the VLAN for that VM go to the DMZ. Depending on the size and complexity of your infrastructure, this might be a non-issue as long as you have the proper configuration and lockdown procedures.
  • Access Layer and Control Layer configured with N+1 availability in that if one component fails, a secondary component is available to take over the load.

When trying to decide what to do in your own environment, remember to look before you leap.

If you want to read the entire design, check out the Design guide to mobilize windows apps

Daniel – Lead Architect

Control layer in the XenDesktop 7 Blueprint

Control, control, you must learn control! – Yoda

The control layer is about creating a single, cohesive foundation for the solution that supports the user-layers (users, access and resources).


You can NOT do the control layer if you haven’t defined your user layer, access layer and resource layer. The control layer of the XenDesktop 7 blueprint is subdivided into

  1. Access Controllers – responsible for providing the connectivity to the resources as defined by the Access Layer
  2. Desktop Controllers – manage and maintain the virtualized resources for the environment
  3. Infrastructure Controllers – standard infrastructure components

The point of the control layer is to define what and how many servers/devices you need to support the user layers. This is based on the size of the user groups as well as the overall design for those user groups.

The first part of the control layer focuses on the access controllers, which should not be confused with the access layer. The access layer defines the access policies, which are associated with each user group. The access controllers are the devices that allows you to implement those policies. If all of your users are local and you do not require a remote access policy, then there you will not require a NetScaler Gateway access controller.

The second part is on the desktop delivery controllers. The delivery controllers make sure you are assigned to the right resource. They make sure the resource is ready. And they make sure the resources are updated appropriately. With XenDesktop 7, this bucket of controllers was reduced in size. You will no longer see XenApp controllers (zone data collectors) because the “XenApp servers” in XenDesktop 7 utilize the same framework. This means XenDesktop users and XenApp users rely on the same desktop delivery controller!

And finally, the last part of the control layer deals with the other components, the supporting cast of characters which includes database servers, licensing server and hypervisor controller servers (vCenter, SCVMM, XenServer) Note: XenServer doesn’t really have a dedicated controller like vSphere and Hyper-V.

When we update the conceptual architecture to now include our control layer, you get the following:

As you see, almost everything begins with 2 instances so that we have some level of fault tolerance in that if one instance fails, we have a second instance to handle the load. Licensing only has 1 instance because there is a built in 30 day grace period, so who cares if it fails. You got 30 days to get licensing running again before users notice.
Daniel – Lead Architect

Extending the blueprint to focus on your resource layer




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

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