In this blog post we will review the architectural components that XenApp And XenDesktop 7.15 Long Term Service Release comprise. Many of the old components that XenApp 6.5 and 6.0 comprised of, are done away with, and components that were part of XenDesktop 5.6 make up the backbone of XenApp (and XenDesktop) 7.1x. This is done to provide a common architecture and a unified management experience for both products. As a matter of fact, in the earliest releases of XenDesktop 7.x, XenApp was completely merged into XenDesktop.
In the 7.1x versions, it doesn’t matter which of the products you install. What matters is the license type you purchase and install. A XenApp license gives you access to features that previously were exclusive to XenApp, namely server-based hosted applications and desktops. While a XenDesktop license gives you access to both XenApp and XenDesktop features (VDI, Remote PC Access and Hosted physical desktops).
XenApp and XenDesktop Feature Matrix
Keep in mind this write up holds true only for On-Premises and Hybrid Cloud deployments. I’ll try to do a write up on pure cloud deployments in a future blog post.
In the illustration below you can see how the core components of a typical XenApp/XenDesktop 7.15 LTSR site interoperate. Citrix Director can be placed on either client-side or the server-side of the network.
Flexcast Management Architecture
While XenApp 6.5 relied on the Independent Management Architecture, XenApp (and XenDesktop) 7.1x relies on the Flexcast Management Architecture. FMA is the underlying architecture which defines and allows interoperability and management modularity across Citrix application and desktop virtualization technologies. FMA requires that you must be in a domain to deploy a site.
Site
A site is the name you give to a XenApp or XenDesktop deployment, it’s the highest level item in XenApp/XenDesktop 7.15 LTSR. It comprises the components used in a XenApp/XenDesktop deployment, such as Delivery Controllers, Virtual Delivery Agents, Host Connections, and the Machine Catalogs and Delivery Groups you create and manage. The site is created after you install the Delivery Controller, and then it can be populated with VDAs (through Machine Catalogs), Delivery Groups, and other components and configurations (such as policies and administrative roles). Simply put, a site is the equivalent of a XenApp 6.5 farm.
Zone
Zones were introduced in XD 7.7, before version 7.7 you had to deploy multi-site environments if you had widely-dispersed locations connected by a WAN in your enterprise, where each site had to be managed independently. Zones can help administrators consolidate multi-site environments into a single site, and thus reduce the administrative overhead. Zones can help users in remote regions connect to resources within a single site, without necessarily forcing their connections to traverse large segments of the WAN. Citrix recommends a maximum of 50 zones per site, and if the network latency of the different zones is high, then a multi-site environment is still recommended.
There are two types of Zones, primary and satellite. A site always has one primary zone, and its created automatically when you create the site. You can create one or more satellite zones once the site has been created. The primary zone has the default name “Primary,” which contains the SQL Server Site database, Studio, Director, StoreFront, License Server, NetScaler Gateway and rest of the components required for a XenDesktop 7.15 site. The Site database should always be in the primary zone. A satellite zone can contain one or more Machine Catalogs, Controllers, StoreFront servers, Host Connections, and NetScaler Gateway servers.
Delivery Controller
Delivery Controllers are the management components of the site. The Delivery Controllers distribute desktops and applications, manage user access, and optimize and load-balance user connections to Virtual Delivery Agents. They also keep track of which users are logged on and where, what session resources the users have, and if users need to reconnect to existing applications. Delivery Controllers communicate with the VDAs through the Broker Service. The Broker Service executes PowerShell and communicates with the Broker agent (on the VDAs) over TCP port 80. It does not have the option to use TCP port 443.
If the deployment includes virtual machines hosted on a hypervisor or cloud service, then the Delivery Controllers also communicate with the hypervisor through a host connection. TCP ports 443 (vSphere, AWS, Azure, and Xenserver) and 8100 (Microsoft SCVMM) are used for this purpose. Hypervisors also partake in brokering operations and load-balancing of user connections by notifying the Delivery Controllers about the status of virtual machines in Delivery Groups, when users request resources (applications and desktops).
You can decide to deploy a single or several Delivery Controllers, depending on the size of your site. Remote Desktop Services is not required on the servers acting as controllers, and the Delivery Controllers do not have to run the same OS as the VDAs they manage.
When installing a Controller, a SQL Server Express database is installed by default for use with the Local Host Cache feature.
Virtual Delivery Agent
The Virtual Delivery Agent is installed on machines to which users will connect. It enables the machines to register with Delivery Controllers, so the VDA and the resources its hosting can be made available to users. VDAs establish and manage the ICA/HDX connection between the machines and the user devices, verify that a Citrix license is available for the user or session, and apply whatever policies have been configured for the session. The VDA communicates session information to the Broker Service in the Controller through the broker agent included in the VDA. XenApp and XenDesktop include VDAs for Windows server and desktop operating systems. VDAs for Windows server operating systems allow multiple users to connect to the server at one time. VDAs for Windows desktops allow only one user to connect to the desktop at a time.
Database
Only Microsoft SQL databases are supported. In version 7.15 LTSR, the database is not a single point of failure, as there is Local Host Cache on the Delivery Controllers. But Citrix still highly recommend a fault tolerant configuration for the database.
There are three types of databases.
• Site Configuration, This database is used to store the configuration information (Policies, Machine Catalogs, Delivery Groups and so on) and session information (what user is logged on to which VDA, what resources are currently in use etc.) for the XenApp/XenDesktop site.
• Configuration Logging, Stores information about site configuration changes and administrative activities.
• Monitoring, Stores data used by Citrix Director, such as session and connection information.
Local Host Cache
The Local Host Cache feature allows connection brokering operations in a site to continue even when the site database is unavailable. The data in the LHC is stored into a Microsoft SQL Server Express LocalDB database on the Delivery Controller. Every two minutes the Delivery Controller checks if configuration changes have been made in the site database. If changes have been made, the LocalDB database will be recreated entirely to contain (new and old) configuration information from the site database.
When an outage occurs the Delivery Controller will use the LHC to perform brokering operations. That is, connect users to appropriate Virtual Delivery Agents (new and existing connections/sessions). If your site has multiple Controllers, only one of them will perform brokering operations during an outage. The Delivery Controllers elect which one of them will perform this duty. There is no time limit imposed for operating in outage mode. But since no data is replicated from the LHC to the site database, obviously you can not make any changes to the site while its operating in outage mode.
This is merely a rudimentary description of how the Local Host Cache works, if you want a detailed explanation on this feature, you can click here.
Btw, although the connection leasing feature is still supported in 7.15 LTSR, it has been deprecated and will be removed in newer versions of the product.
StoreFront
StoreFront has replaced the Citrix Web Interface. StoreFront provides users access to one or more Site(s) hosting the XenApp and XenDesktop resources and manages the stores of desktops and applications that users access. It also keeps track of users’ application subscriptions, shortcut names, and other data to ensure users have a consistent experience across multiple devices. StoreFront communicates with the Delivery Controller using XML over TCP port 80/443. Users can access their resources through a standard web browser or through the Citrix Receiver. Unlike Web Interface, StoreFront also partakes in the authentication process.
Citrix Receiver
The Receiver is a software client that is installed on the end user device, and enables access to applications and desktops delivered through Citrix XenApp and XenDesktop (through the ICA protocol). Receiver is platform and device agnostic, meaning that there is a Citrix Receiver for just about every device out there, from Windows to Linux-based thin clients and to mobile devices running iOS and Android. For devices that cannot install Receiver software, Receiver for HTML5 provides a connection through a HTML5-compatible web browser.
Citrix Studio
This is the management console used to manage the XenApp or XenDesktop site. You use it to perform management tasks such as, create and configure a XenApp/XenDesktop site, deliver applications and desktops, configure policies, create administrative roles and scopes, and so on. You can also use Studio to allocate and track Citrix licenses for your site. Studio gets the information it displays from the Broker Service in the Delivery Controller. Citrix Studio communicates with the Delivery Controllers on TCP port 80.
Citrix Director
Director is a web-based tool that is used to monitor and troubleshoot the XenDesktop deployment. It allows administrators to track user activity, identify performance bottlenecks, and perform support tasks for end users. One Director deployment can connect to and monitor multiple XenApp/XenDesktop Sites. Director communicates with the Controller on TCP port 80 or 443.
Director shows real-time session data from the Broker Service in the Controller, which includes data the Broker Service gets from the broker agent in the VDA, and historical site data from Monitor Service in the Controller. Director also gives you the option to view and interact with a user’s session using Windows Remote Assistance.
Citrix License Server
The License server communicates with the Delivery Controller to manage licensing for each user’s session and with Studio to allocate license files. There are two types of licenses,
• User/Device, A user license allows a single user access from an unlimited number of devices, while a device license allows an unlimited number of users access from a single device. The license server will decide for you if you’ll use a user or a device license, and it will ensure that the smallest amount of licenses required are allocated.
• Concurrent, This type of licenses are not tied to a specific user or machine. The License is rather tied to a specific user/device combination, and its valid for the duration of the session. If the session ends, the license is returned to the license pool. If a user connects from two different devices, he will consume two licenses.
In XD 7.15 LTSR you can use concurrent and/or user/device licenses within the same site, configured on a per Delivery Group basis, through Multi-type Licensing.
Machine Catalogs
Collections of virtual or physical machines can be managed as an entity called a machine catalog. All machines in a machine catalog have the same operating system and the same VDA installed. Typically, you create a master image and use it to provision identical virtual machines in the catalog through Citrix Machine Creation Services or Citrix Provisioning Services. But you can also manually provision machines, by using third-party Electronic Software Distribution tools, such as Microsoft SCCM. Any machine which’s resources that you want to make accessible to users, must be member of a machine catalog.
You set up the (resources on) machines you want to make available to users with machine catalogs, but you designate which users have access to those resources with Delivery Groups.
Delivery Groups
Resources on collection of machines selected from one or more machine catalogs are made available to users by said machines being added to Delivery Groups. The Delivery Group specifies which users can access resources (Desktops and/or Applications) on those machines. Each Delivery Group can contain machines from more than one Machine Catalog, and each catalog can contribute machines to more than one Delivery Group, but a single machine can be used in only one Delivery Group and not be added to several Delivery Groups.
If machines from more than one catalog are added to a Delivery Group, then all catalogs must contain machines with the same machine type (Server OS, Desktop OS or Remote PC Access).
Application Groups
With Application Groups you can manage collections of applications as a single entity. Application Groups are not required, but rather entirely optional. They are an alternative to adding the same applications to multiple Delivery Groups. Application Groups can be created for applications shared across different Delivery Groups or used by a subset of users within Delivery Groups. This feature was introduced in XenDesktop 7.9
Host Connections
The Host Connection is optional, but highly recommended if you have Virtual Delivery Agents installed on virtual machines, which, let’s face it, most configurations will have. You can auto-provision and manage virtual machines through the host connection. The host connection will connect the site to cloud or on-premises Hypervisors, and utilize the management software (SCVMM, vCenter etc.) of said hypervisors to auto-provision and manage virtual machines running on those hypervisors.
Hypervisors also partake in brokering operations and load-balancing of user connections by notifying the Delivery Controllers about the status of virtual machines in Delivery Groups, when users request resources (applications and desktops).