In this blog post we will review the architectural components that XenApp And XenDesktop 7.6 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.x and 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. But let’s not delve into those details. As is the case with Citrix products, great as they are, the backstory has a tendency to get a bit cluttered. 🙂
Basically, from what I’ve gathered, now 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 XenApp/XenDesktop 7.6 LTSR, in newer versions of the products, some things are slightly different. I’ll try to do a write up on the latest Long Term Service Release (7.15), later this year.
In the illustration below you can see how the core components of a typical XenApp/XenDesktop 7.6 LTSR site interoperate.
Flexcast Management Architecture
While XenApp 6.5 relied on the Independent Management Architecture, XenApp (and XenDesktop) 7.x and 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.
A site is the name you give to a XenApp or XenDesktop deployment, it’s the highest level item in XenApp/XenDesktop 7.6 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.
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. 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 Machine Creation Services are used to provision virtual machines, then the Delivery Controllers also communicate with hypervisors through a host connection, to manage and deploy Virtual Delivery Agents. TCP ports 443 (Vsphere and Xenserver) and 8100 (Microsoft SCVMM) are used for this purpose.
You can decide to deploy a single or several Delivery Controllers, depending on the size of your site. Delivery Controllers communicate only with the database and not with each other. If a Delivery Controller is offline for whatever reason, it will not affect other Controllers in the 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.
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. 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.
Only Microsoft SQL databases are supported. In version 7.6 LTSR, the database is actually a single point of failure, as there is no Local Host Cache on the Delivery Controllers (this has changed in the newer versions, as the Local Host Cache has been reintroduced). For this reason, a fault tolerant configuration is highly recommended for the database. If the database server fails, existing connections to VDAs will continue to function until a user either logs off or disconnects from a virtual desktop, new connections cannot be established if the database server is unavailable. (New connections to resources that the user launched in the previous two weeks are still possible to make through the connection leasing feature, which is enabled by default)
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. As mentioned earlier, the site is only available if this database is available.
• Configuration Logging, Stores information about site configuration changes and administrative activities.
• Monitoring, Stores data used by Citrix Director, such as session and connection information.
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. 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.
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.
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.
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 Microsoft 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.
Only one type of license can be used within a site, so you have to choose between user/device or concurrent. XenApp only supports concurrent licenses, while XenDesktop supports both types. Of course if you install XenDesktop licenses (Platinum or Enterprise edition), then you have access to both XenApp and XenDesktop features.
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 you want to provide to users with machine catalogs, but you designate which users have access to these resources with Delivery Groups.
Resources on collection of machines selected from one or more machine catalogs are made available to users by being added to Delivery Groups. The Delivery Group specifies which users can access resources on those machines, and the applications available to those users. 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).
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.