Whether you are administrating, designing, building, optimizing or troubleshooting an existing or new XenDesktop environment/architecture, it’s important to know which components and services are involved, how they interact, and what is supposed to happen under normal circumstances.
Only then will you be able to quickly pinpoint any potential issues, or optimize current data flows and keep your users happy. The same applies when designing a completely new XenDesktop and/or XenApp Site; you need to have a good understanding of what is needed under which circumstances.
From a high-level perspective the FMA is built up around nine main components; however, it is within these components that the real magic happens. Take the services that make up the Delivery Controllers and VDAs, for example, but also technologies like Framehawk and ThinWire, Connection Leasing, Zones and concepts like Delivery Groups and Machine Catalogs, your Host Connections and so on.
The idea behind this project? Before commenting, read the introduction blog post here
Although each component and concept will be individually discussed (this will be the biggest chapter by far), as mentioned this book is not meant as an install-and-configure manual and as such I will not cover all aspects and configuration options and/or functionalities available per component/technology. Instead, I will focus on the infrastructural side of things and provide you with a more than basic understanding of how all these components and services fit together.
Made possible with the support of my sponsor IGEL
Consider this chapter a warm-up.
The nine main FMA components are:
- Analytics service.
- Broker service.
- Configuration service.
- AD Identity service.
- Configuration Logging service.
- Delegated Administration service.
- Machine Creation service.
- Host service.
- Environment Test service.
- Monitor service.
- StoreFront service.
Before we get into the main FMA components, I would first like to start with a short definition of a XenDesktop/ XenApp Site, since this is where all of our main and subcomponents will reside. It encompasses all Delivery Controllers, VDAs, Host Connections and all other components and technologies needed to host and virtualize our desktops and applications, which can then be managed and maintained as a single entity from Citrix Studio. See the image below.
FMA fact: Active Directory is required for the authentication and authorization of users in a Citrix environment. This includes DNS
XenDesktop Site main components
While this chapter will provide you with a global overview, the chapters ‘The FMA Core services’ and ‘The user login process’ will discuss in detail all of the primary FMA services, their individual tasks, and responsibilities, including a step-by-step overview of the entire user login and resource enumeration and launch process. Also, the ‘Troubleshooting the FMA’ chapter will handle troubleshooting using Scout in more detail.
FMA fact: Your Delivery Controllers can be considered as the heart of your FMA deployment.
The Delivery Controller is the real workhorse and centerpiece of the FMA and, as such, it has a lot of responsibilities. To name a few, it brokers (VDA) sessions, verifies user credentials and plays an important role during user login and resource enumeration as well as launch. It communicates with StoreFront and/or Web Interface, the underlying Host Connection (Hypervisor or cloud-based services), the Central Site database, and it also takes care of load-balancing hosted shared desktop connections. As of version 7.6, it includes and takes care of Connection Leasing as well, which will be discussed in more detail later on.
You could say that the Delivery Controller is, in fact, the heart of XenDesktop / XenApp. It houses all eleven primary FMA services (2018 update: 13 services) including the well-known XML service. Here they are:
- Analytics service.
- Broker service.
- Configuration service.
- AD Identity service.
- Configuration Logging service.
- Delegated Administration service.
- Machine Creation service.
- Host service.
- Environment Test service.
- Monitor service.
- StoreFront service.
- High Availability Server a.k.a. Secondary Broker Service (new)
- Configuration Synchronization Service (new)
Each service has its own specific responsibility. Note that the XML service isn’t mentioned since it is not FMA-specific. As highlighted, during the ‘FMA core services’ chapter we will have a closer look at each service individually, the XML service included, and how they all interact and communicate within the FMA. This will also include the evolution from an FMA services perspective, as well as FMA service groups and more.
Authentication and enumeration
When a user logs in, either internally through StoreFront or externally throughNetScaler, for example, as mentioned the Delivery Controller plays an important role during the user authentication and verification process, as well as with enumerating and launching user resources. This process is also referred to as connection brokering. A Delivery Controller has a direct and live connection with the Central Site database, which holds all static as well as dynamic (real-time) information within the Site.
As opposed to the Data Collectors in XenApp 6.5 and earlier, none of this information will be stored locally (no LHC, remember) and all Delivery Controllers will fully depend on the Central Site database to provide this information when needed. Communication between a Delivery Controller and the Central Site database is constant (heartbeat messages are exchanged every 20 seconds with a TTL of 40 seconds).
The Delivery Controller also plays a key role in controlling all registered desktop and server machines (to which your users connect) with regard to availability, load balancing, and power management, which includes starting and stopping virtual machines when needed: see also the next chapter on VDAs. It brokers connections between users and their virtual and/or physical desktops and applications while maintaining and optimizing these connections wherever and whenever needed using technologies like SessionReliability (Common Gateway Protocol), Auto Client Reconnect, ICA Keep-Alive messages, and workspace control. Note that power management is not available for physical machines, only virtual.
As an IT specialist, you are probably familiar with the saying ‘one is none’, as this applies to almost all infrastructural components that we‘techies’ have to deal with. The same applies to the Delivery Controller. If the server hosting the Delivery Controller role is unavailable, your users will not be able to be authenticated or verified; as a result, they will also not be able to access and/or launch any of their virtual desktops or published applications.
Therefore at least two Delivery Controller servers per Site should be deployed on different physical hosts (when virtualized) to prevent a single point of failure. All online Delivery Controllers within your Site will actively participate in handling user/session requests at any time (amongst other tasks), if one of the Controllers for whatever reason goes offline, one of the other Controllers will take over its tasks automatically and instantly. All Controllers within a Site have access to the same Central Site database and therefore are equally configured.
FMA fact: Your environment is as strong as its weakest link. Make sure to apply the ‘one is none’ rule wherever and whenever it makes sense.
A Delivery Controller is different from a Data Collector in many ways. Besides the absence of the Local Host Cache, Delivery Controllers do not communicate with each other, they cannot host any user sessions like a Data Collector can, and as such, they also do not have to run the same Operating System as the VDAstheymanage.See the next page for an overview (table) on some of the most important differences between the two.
Citrix Studio is the main management tool and console used to set up and configure XenDesktop and XenApp Sites. It can be installed on a Delivery Controller or separately on a management machine, for example. Since the Delivery Controller plays such an important role, Studio will also have a direct connection with one or multiple of your Delivery Controllers.
Below you will find an overview on some of the differences between a Delivery Controller and a Data Collector.
Delivery Controller vs. Data Collector
Some of the most important management and configuration activities that take place, either on or through your Delivery Controllers, are:
- Site Creation.
- Manage Delivery Controllers.
- Manage Host C
- Machine provisioning.
- Manage AppDisks.
- Manage Zones.
- Connection Leasing.
- Publish desktops and applications.
- Assign resources to users.
- Configure Site-wide policies.
- Manage user sessions.
- Direct database communication.
- Delegated Administration.
- VDA registration.
- Power management.
- Load balancing.
- Licensing statics.
- Configure App-V infrastructure.
- Troubleshooting (Scout).
- Monitoring
Most of the above Studio management activities will be discussed in more detail throughout several of the upcoming chapters.
Delivery Controller server sizing
To give you an indication of what might be needed resource-wise, have a look at the following table. Citrix testing has shown that a relatively light virtual machine configuration can handle up to 5000 desktops per Delivery Controller per hour with regard to user authentication, enumeration, and resources launch.
Delivery Controller server sizing
The following Operating Systems are officially supported and tested by Citrix to run the Delivery Controller role:
- Windows Server 2012 R2, Standard and Datacenter Editions.
- Windows Server 2012, Standard and Datacenter Editions.
- Windows Server 2008 R2 SP1, Standard, Enterprise, and Datacenter Editions.
- As mentioned, your Delivery Controllers have a lot of responsibilities and can, therefore, be seen as the heart of your FMA deployment.
- Always deploy at least two Delivery Controllers per Site, and if you can per Zone as well. A minimum of one Controller per Zone is needed in the case of a WAN link failure.
- Virtualizing your Delivery Controller makes them more flexible, especially in bigger environments. Adding extra DCs or compute resources will be a breeze.
- Almost all Site traffic goes directly through your Delivery Controllers down to the Central Site database and vice versa.
- Try to keep your Delivery Controllers physically close to your database server and any Host Connections you might have set up.
- Delivery Controllers are fundamentally different from Data Collectors: remember that. No LHC, direct database communication, no communication between Delivery Controllers, service-and agent (VDA)-based, and so on.
- StoreFront directly communicates with one of your Delivery Controllers during the user authentication, application enumeration, and launch process. You can configure your StoreFront server with a NetScaler load balancer VIP address, which will load balance the connections to the Delivery Controllers within the NetScaler VIP.
