Designing the New FlexCast® Management Architecture

Tune and optimize the performance of your farms with the new improved XenApp® architecture.

This article written by Luca Dentella, the author of Citrix® XenApp® 7.x Performance Essentials, teaches us how to design a XenApp architecture. It also helps us get acquainted to the key features of the new FlexCast Management Architecture. We learn about the layers as well.

The design of a XenApp infrastructure is a complex task that requires good knowledge of XenApp components. Making the right decisions in the design phase may also greatly help system administrators to expand XenApp farms to satisfy new business requirements or to improve the user experience.

In this article, you will learn about the following:

  • The key features of the new FlexCast Management Architecture
  • The five-layer model
  • Sizing each layer's components
  • Implementing and using Machine Creation Services to deploy new worker servers in minutes
  • The difference between XenApp 6.5 and 7.5

(For more resources related to this topic, see here.)

FlexCast® Management Architecture

With XenApp 7.5, Citrix adopted the same architecture that was introduced in XenDesktop 5 and refined in XenDesktop 7, namely, FlexCast Management Architecture (FMA).

FMA is primarily made up of Delivery Controllers and agents. Delivery agents are installed on all virtual and/or physical machines that host and publish resources (named worker servers), while the controllers manage users, resources, configurations, and store them in a central SQL server database.

Unlike the previous versions of XenApp, the delivery agent now communicates only with the controllers in the Site and does not need to access the Site's database or license server directly, as illustrated in the following figure:

Citrix® XenApp® 7.x Performance Essentials

Overview of FlexCast infrastructure's elements

The main advantage of this architectural change is that now only one underlying infrastructure is used by XenApp and XenDesktop. Therefore, the overall solution might include both published applications and virtual desktops, leveraging the same infrastructure elements.

XenApp administrators who have moved to version 7.5 might be a bit confused; there are no more zones or data collectors. By the end of this article, you will find a table that maps concepts and terms from XenApp 6.x to the new ones in XenApp 7.5.

The five-layer model

When designing a new infrastructure, a common mistake is trying to focus on everything at once. A better and suggested approach is to divide the solution into layers and then analyze, size, and make decisions, one level at a time.

FlexCast Management Architecture can be divided into the following five layers:

  • User layer: This defines user groups and locations
  • Access layer: This defines how users access the resources
  • Resource layer: This defines which resources are assigned to the given users
  • Control layer: This defines the components required to run the solution
  • Hardware layer: This defines the physical elements where the software components run

The power of a FlexCast architecture is that it's extremely flexible; different users can have their own set of policies and resources, but everything is managed by a single, integrated control layer, as shown in the following figure:

Citrix® XenApp® 7.x Performance Essentials

The five-layer model of FlexCast Management Architecture

The user layer

The need for a new application delivery solution normally comes from user requirements.

The minimum information that must be collected is as follows:

  • What users need access to (business applications, a personalized desktop environment, and so on)
  • What endpoints the users will use (personal devices, thin clients, smartphones, and so on)
  • Where users connect from (company's internal network, unreliable external networks, and so on)

User groups can access more than one resource at a time. For example, office workers can access a shared desktop environment with some common office applications that are installed, and in addition, use some hosted applications.

The access layer

The access layer defines how users gain access to their resources based on where the user is located and the security policies of the organization.

The infrastructure components that provide access to resources are as follows:

  • StoreFront (Web Interface 5.4 is still supported to offer customers additional time to migrate to StoreFront)
  • NetScaler Gateway

The following figure demonstrates the access layer:

Citrix® XenApp® 7.x Performance Essentials

FlexCast Management Architecture—the access layer


Internal users access a StoreFront store using Citrix Receiver that is installed on their endpoints or via the StoreFront web interface. StoreFront also offers a receiver for HTML5 that does not require any installation on the user's device.

Upon successful authentication, StoreFront contacts a Delivery Controller to receive the list of available resources and allows the users to mark some of them as favorites.

StoreFront requires Windows 2008 R2 SP1 or later, with Microsoft Internet Information Services (IIS) and the .NET framework. Even if it can be installed on a server that runs other components, my suggestion is to install it on at least two dedicated servers with a load balancer in front of them to provide high availability.

Users' subscriptions are automatically synchronized between all the StoreFront servers.

StoreFront is the entry point of your XenApp infrastructure. To correctly size its servers, you will need to estimate or measure the maximum number of concurrent logins (if your infrastructure mainly serves internal users, most of the logins will happen in the morning, when users arrive at office).

From my experience, StoreFront does not require a lot of hardware resources: a server with two CPUs and 4 GB of memory is enough for up to 1,000 user connections per hour.

NetScaler Gateway™

Remote users connect and authenticate to NetScaler Gateway, which is located within the network's DMZ.

NetScaler Gateway is available both as a hardware appliance (MPX) and a virtual appliance (VPX); the virtual appliance delivers the same features and functionalities as that of the physical one. The main difference between VPX and MPX is about SSL; MPX has dedicated offload capabilities.

An MPX appliance has a single, dual-core processor and 4 GB of memory, while the virtual appliance that can be run on VMware ESXi, Microsoft Hyper-V, and XenServer, requires at least 2 virtual CPUs, 4 GB of memory and 20 GB of disk space.

NetScaler Gateway establishes a secure SSL channel with the user's device, and all the traffic is encapsulated in that channel.

Upon successful validation, NetScaler forwards the user request to the internal StoreFront servers that then generates a list of the available resources that is passed back to the user through NetScaler Gateway.

When the user launches a resource, all the traffic between the server that hosts the resource and the user's device is again encapsulated in the SSL channel.

To provide high availability, you can deploy two NetScaler Gateway appliances in a failover clustering configuration; so, if the primary active appliance fails, the secondary one becomes active. The HA feature is native and part of the NetScaler license; it does not require any external clustering solutions (Microsoft Cluster…).

Access policies

In most environments, there are different security policies based on the users' locations; for example, users in the internal network can authenticate using only the username and password, while external users might need to enter a token code as well (multifactor authentication).

In NetScaler Gateway, you can configure session policies to differentiate between incoming connections by analyzing elements such as IP addresses, HTTP headers, SSL certificates, and so on. Moreover, you can also combine different expressions using logical operators (OR and AND), use built-in functions to test whether the client is running the most updated antivirus, and perform string matching with the power of regular expressions.

Policies do not take actions. They provide the logic to evaluate traffic. To perform an operation based on a policy's evaluation, you have to configure actions and profiles and associate them with policies. Policies can be applied at user, group, and server levels; all the applicable policies are inspected, and the one with the lowest priority wins.

Actions are steps that NetScaler takes; for example, you can allow an incoming connection if it matches the associated policy and deny it if not.

Profiles are collections of settings, for example, the session timeout (in minutes) or the Web interface / Storefront server URL.

To help system administrators create the correct policies and profiles for most common clients (Citrix Receiver, Receiver for Web, Clientless Access, and so on), Quick Configuration Wizard is automatically executed the first time you configure NetScaler Gateway.

The resource layer

A XenApp infrastructure is designed and implemented to offer resources to the users.

XenApp offers different strategies to deliver applications. The choice of the correct strategy has a high impact on the infrastructure.


This article teaches us about the sizing components of different layers. We also learn about the architecture's design and its main features. This helps us design the architecture in a better way.

Resources for Article:

Further resources on this subject:

Books to Consider

The Professional Woman’s Guide to Managing Men
$ 14.99
Mastering Management Styles: Expert Guidance for Managers
$ 14.99
Practical Change Management for IT Projects
$ 39.99
comments powered by Disqus