31/07/2019 Citrix XenApp and XenDesktop 7.

15 LTSR Architecture and Components - ShabazTech

Citrix XenApp and XenDesktop 7.15 LTSR Architecture and Components

l Shabaz November 5, 2017 v 0 Comments

m Citrix, Xendesktop 7.15 LTSR Citrix, Xendesktop 7.15 LTSR

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.

https://shabaztech.com/citrix-xenapp-xendesktop-7-15-ltsr-architecture-components/ 1/8
31/07/2019 Citrix XenApp and XenDesktop 7.15 LTSR Architecture and Components - ShabazTech

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
https://shabaztech.com/citrix-xenapp-xendesktop-7-15-ltsr-architecture-components/ 2/8
31/07/2019 Citrix XenApp and XenDesktop 7.15 LTSR Architecture and Components - ShabazTech

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.

https://shabaztech.com/citrix-xenapp-xendesktop-7-15-ltsr-architecture-components/ 3/8
31/07/2019 Citrix XenApp and XenDesktop 7.15 LTSR Architecture and Components - ShabazTech

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.

https://shabaztech.com/citrix-xenapp-xendesktop-7-15-ltsr-architecture-components/ 4/8
31/07/2019 Citrix XenApp and XenDesktop 7.15 LTSR Architecture and Components - ShabazTech

• 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.

https://shabaztech.com/citrix-xenapp-xendesktop-7-15-ltsr-architecture-components/ 5/8
31/07/2019 Citrix XenApp and XenDesktop 7.15 LTSR Architecture and Components - ShabazTech

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

https://shabaztech.com/citrix-xenapp-xendesktop-7-15-ltsr-architecture-components/ 6/8
31/07/2019 Citrix XenApp and XenDesktop 7.15 LTSR Architecture and Components - ShabazTech

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

https://shabaztech.com/citrix-xenapp-xendesktop-7-15-ltsr-architecture-components/ 7/8
31/07/2019 Citrix XenApp and XenDesktop 7.15 LTSR Architecture and Components - ShabazTech

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).

(Visited 7,416 time, 11 visit today)

← Previous post Next post →

https://shabaztech.com/citrix-xenapp-xendesktop-7-15-ltsr-architecture-components/ 8/8