Citrix Virtual Apps and Desktops — architecture, use cases and the differences between XenApp and XenDesktop

1. Introduction

Citrix Virtual Apps and Desktops (CVAD) is a platform for centrally delivering applications, full virtual desktops and access to physical computers to users. The application or desktop runs in a data center, in the cloud or on a company computer, while an interactive image of the session and input data are transmitted to the user’s device.

The solution enables access from various devices and locations while keeping applications and data under the organization’s control. It can operate as:

• Citrix Virtual Apps and Desktops — a management infrastructure maintained on-premises by the organization;
• Citrix DaaS — a cloud service in which Citrix maintains the control layer, while the organization manages application resources and desktops in selected resource locations.

The names XenApp and XenDesktop are historical names. The product line was renamed Citrix Virtual Apps and Desktops, but these terms are still widely used in organizations, in documentation of older versions, in component names and in technical conversations.

Table of contents

2. The key concept: central execution, remote presentation

3. XenApp and XenDesktop — where the names come from

4. Detailed technology differences: XenApp vs XenDesktop

4.1. XenApp: shared multi-session host

4.2. XenDesktop: single-session VDI; 4.3. Publishing applications from VDI

5. Citrix Virtual Apps and Desktops architecture

6. How session launch works

7. Advantages of the solution

8. Purpose and typical deployment scenarios

9. Choosing the delivery model

10. CVAD on-premises vs Citrix DaaS

11. Security and best practices

12. Limitations and risks

13. Pre-deployment checklist

14. How to choose between Virtual Apps and Virtual Desktops; 15. Glossary; 16. Summary

17. Sources — official vendor documentation

2. The key concept: central execution, remote presentation

In a typical scenario the application does not run on the user’s laptop. It runs on a machine with the Virtual Delivery Agent (VDA) installed. The user works with the Citrix Workspace app application, which receives the session image and passes the keyboard, mouse, audio, clipboard, printers or other permitted devices to it.

Citrix HDX technologies optimize the remote environment for, among other things, graphics, multimedia, audio, peripheral devices and changing network conditions.

3. XenApp and XenDesktop — where the names come from

Historically these were two products aimed at different models of delivering resources:

• XenApp developed the Server-Based Computing model: many user sessions ran simultaneously on a shared server system. Single applications were most often published, but a full server desktop could also be delivered.
• XenDesktop was aimed at Virtual Desktop Infrastructure (VDI): the user received a single desktop based on a desktop operating system, running on a virtual or physical machine. The desktop could be shared in a pool or assigned to a specific user.

From the 7.x generation onward, XenApp and XenDesktop used the shared FlexCast Management Architecture (FMA) and shared management components. The later rename to Citrix Virtual Apps and Desktops reflected the merging of both models into one platform.

The key takeaway

The difference should not be oversimplified to the sentence “XenApp delivers applications and XenDesktop delivers desktops”. A more precise distinction is:

• XenApp mainly used a shared multi-session system on which many users work at the same time;
• XenDesktop mainly used a single-session system, in which one active user session occupies one machine or one operating system instance.

XenApp could publish an entire server desktop, and XenDesktop could deliver applications running on a desktop virtual machine. What matters is therefore the model of sessions, isolation and resources, not how the resource looks in the user portal.

4.1. XenApp: shared multi-session host

Many isolated user sessions run on a single server or multi-session system. Each session has its own desktop, processes and profile, but users share the system kernel, installed applications, CPU and host memory.

Key consequences:

• a high number of users per host and favorable economics,
• central installation and updating of applications,
• the need to test multi-session compatibility,
• limited freedom for users to install software,
• the need to control load so that one session does not degrade the work of the others,
• a host failure affects all sessions running on it.

A published application can look like a local application: the user does not have to see the full server desktop. The program window is presented on the end device, although the process runs on the VDA.

4.2. XenDesktop: single-session VDI

Each active user works on a separate operating system. It can be a machine from a pool or an assigned machine. This provides stronger isolation and greater compatibility with desktop applications, but requires more infrastructure resources.

The most common VDI models:

1. Random pooled, non-persistent — at each logon the user receives an available machine from the pool. System changes are discarded after a restart; user data requires a separate profile and storage mechanism.
2. Static non-persistent — the user returns to the same assigned machine, but system changes can still be removed after a restart.
3. Static persistent — the user receives an assigned machine and keeps changes. The model provides the greatest personalization, but increases maintenance cost and the risk of configuration drift.
4. Remote PC Access — the Citrix broker provides secure remote access to an employee’s physical computer, without moving its environment to a classic VDI machine.

4.3. Publishing applications from VDI

The platform can deliver a single application running on a single-session machine. This is useful when the application:

• does not work correctly on a shared server system,
• requires a specific desktop Windows system,
• conflicts with other applications,
• requires stronger isolation at the system level.

The user then sees only the application window, as in the Virtual Apps model, but underneath an entire single-session machine is consumed.

5. Citrix Virtual Apps and Desktops architecture

Delivery Controller

The central brokering and management component. It authenticates and authorizes access to resources, selects the right VDA, tracks sessions and mediates connection setup. In a production environment at least two controllers should be deployed for resilience and scaling.

Virtual Delivery Agent (VDA)

An agent installed on the machine that delivers an application or desktop. It registers with the Delivery Controller, starts the session and enforces Citrix policies. The main types are:

• multi-session VDA — many users on one system;
• single-session VDA — one user per machine;
• Linux VDA — for supported Linux distributions;
• a variant intended for Remote PC Access.

StoreFront / Citrix Workspace

The layer that presents the assigned applications and desktops to the user. StoreFront is a component maintained by the customer, while Citrix DaaS environments can use access services offered in the cloud.

Citrix Workspace app

The client on the user’s device. It handles logon, the presentation of resources and the launch of HDX sessions. Browser access can be an alternative, but the range of features depends on the client and platform used.

Citrix Gateway

Provides controlled access from external networks. It can integrate multi-factor authentication and secure the connection between the user and the Citrix environment. Depending on the model, either a customer-owned Citrix Gateway/NetScaler or the Citrix Gateway Service is used.

Studio / Web Studio

The administration console used to create machine catalogs and Delivery Groups, publish applications and desktops, and configure policies. Web Studio is the web-based generation of the management console.

Director / Monitor

An operational tool for administrators and the service desk. It allows analysis of logons, active sessions, connection errors, performance and user experience, and lets support staff take support actions.

Databases

In on-premises CVAD the Site database stores the deployment configuration, and additional databases can serve monitoring and Configuration Logging. SQL availability is critical for the operation of the control layer. In Citrix DaaS the control layer databases are maintained by the Citrix service.

Machine Catalog and Delivery Group

• Machine Catalog groups machines of a similar system type, management method and purpose.
• Delivery Group defines which machines and which applications or desktops are available to specific users and groups.

MCS and Citrix Provisioning

The platform offers mechanisms for building many machines from a common image:

• Machine Creation Services (MCS) — creating and managing machines through integration with a hypervisor or cloud;
• Citrix Provisioning (PVS) — streaming delivery of the system image to many target machines.

The choice depends on the platform, scale, operational requirements, team skills and the expected update model.

6. How session launch works

1. The user opens Citrix Workspace app or a web portal.
2. The access layer authenticates the user and shows the permitted resources.
3. The user selects an application or desktop.
4. The Delivery Controller checks entitlements and selects a suitable, available VDA.
5. The connection setup parameters are sent to the client.
6. Citrix Workspace app establishes the HDX session with the VDA — directly or through Citrix Gateway.
7. The application runs on the VDA, and the user receives the remote session interface.
8. Session data is available to monitoring and support tools.

7. Advantages of the solution

Centralization of applications and images

Applications can be installed and updated in a central image instead of separately on each end device. This reduces configuration differences and speeds up the distribution of changes.

Safer access to data

Business data can remain in a controlled data center or cloud. What reaches the user’s device is primarily the interactive image of the session. Policies can restrict the clipboard, local drives, printing, USB and other data exchange channels.

Access from many devices and locations

Users can access the same set of applications from company computers, personal computers, mobile devices, terminals and browsers — within the limits of the organization’s policies.

Infrastructure cost optimization

The multi-session model lets many users share a host, which usually gives higher density than VDI. The organization can match the delivery model to the user profile instead of assigning every user a full virtual machine.

A consistent work environment

Profiles, policies and shared images make it easier to ensure a uniform configuration. The user can get a similar environment regardless of the end device.

Flexible delivery models

A single platform can simultaneously support published applications, shared desktops, persistent and non-persistent VDI, VM-hosted applications, Linux and Remote PC Access.

Scaling and automation

Integration with hypervisors and clouds makes it possible to create catalogs from a master image, manage machine power and scale resources according to demand.

Operational support

Director/Monitor and logon and session data make it easier to analyze problems with performance, connections and user experience.

8. Purpose and typical deployment scenarios

Publishing business applications

Best suited for ERP, financial and administrative applications or older Windows programs that must be maintained centrally and made available to many users.

Preferred model: Virtual Apps on a multi-session system, if the application is compatible with it.

Call centers and task workers

Employees use a small, standard set of applications and do not require individual system configuration.

Preferred model: a shared desktop or multi-session applications.

Hybrid and remote work

The organization wants to provide controlled access to applications without copying data to personal or less well-managed devices.

Preferred model: Virtual Apps, VDI or Remote PC Access, depending on the user’s needs.

Contractors and partners

External users need access only to specific applications for a limited time.

Preferred model: published applications with precise access policies, MFA and restricted device channels.

Users who require personalization

Developers, analysts, designers or specialists need their own tools, configuration or resources.

Preferred model: static VDI, often persistent, after analyzing hardware and security requirements.

Applications incompatible with multi-session

The application requires a desktop operating system, has conflicting dependencies or does not support multiple users on one host.

Preferred model: a VM-hosted app or a full VDI desktop.

Secure access to office computers

The organization wants to enable employees to access physical workstations remotely without changing their environment.

Preferred model: Remote PC Access.

Operational resilience and fast workstation setup

Central images and access from various devices can support emergency work, interchangeability of end devices and fast user onboarding.

11. Security and best practices

• Use MFA for external access and privileged accounts.
• Deliver sessions through Citrix Gateway or an appropriate access service; do not publish VDAs directly to the internet.
• Segment the management layer, user access, VDAs, databases and the provisioning infrastructure.
• Apply the principle of least privilege in delegated administration and Delivery Groups.
• Limit redirection of the clipboard, drives, USB and printers to actual business needs.
• Update the control layer, VDAs, Workspace app, StoreFront and Gateway according to the supported path.
• Protect master images: scan them, version them and test them before publishing.
• Do not store user data solely on the non-persistent system disk of a VDI.
• Monitor unusual logons, VDA registration failures, logon delays and administrative changes.
• Design Delivery Controllers, StoreFront, Gateway, SQL and dependent components with redundancy.
• Test Local Host Cache or other continuity mechanisms appropriate for the model and version in use.

12. Limitations and risks

• The platform has many components and requires a deliberate design of dependencies.
• Underestimating CPU, RAM, IOPS or user profiles quickly affects session quality.
• Applications can behave differently in a multi-session environment; they require functional and performance testing.
• VDI provides greater isolation, but usually increases the cost of compute, storage and operating system licenses.
• Persistent VDI can lead to configuration drift and make updates harder.
• Non-persistent VDI requires proper separation of the system, profile and user data.
• A single failure of a shared component — for example Gateway, StoreFront, SQL or a profile — can affect many users.
• Good HDX performance does not remove the limitations of poor connectivity; latency, packet loss and bandwidth still matter.
• Microsoft RDS, Windows, Citrix and business application licenses must be verified for the chosen model.

13. Pre-deployment checklist

User and application analysis

• User personas and their requirements have been defined.
• Applications, dependencies, licenses and required devices have been inventoried.
• Application compatibility with a multi-session system has been tested.
• It has been determined whether the user needs an application, a shared desktop, VDI or Remote PC Access.
• Requirements for personalization and data persistence have been established.

Design

• The on-premises or Citrix DaaS model has been chosen.
• HA has been designed for the access and control layers.
• CPU, RAM, GPU, IOPS, network and profile capacity have been estimated.
• MCS, PVS or another supported method of building machines has been chosen.
• Profiles, user data, printing and device redirection have been planned.
• Rules for external access, MFA and segmentation have been defined.

Pilot and production

• A pilot has been carried out with a representative group of users.
• Logon time, host utilization and HDX session quality have been measured.
• Failures of Controllers, StoreFront, Gateway, SQL and VDA hosts have been tested.
• Image versioning and a rollback procedure have been prepared.
• Monitoring and alert thresholds have been configured.
• First- and second-line support has been documented.

14. How to choose between Virtual Apps and Virtual Desktops

Start with the Virtual Apps model if the application works correctly on a multi-session system, users have similar needs, and the priority is density and central maintenance.

Choose Virtual Desktops if the user needs a separate system, greater personalization, an application incompatible with a server operating system, specific drivers or stronger isolation.

A hybrid model is usually the most practical: standard applications are published from shared hosts, and only those groups that actually require its capabilities receive VDI.

15. Glossary

• Citrix DaaS — a cloud service for delivering applications and desktops, previously called Citrix Virtual Apps and Desktops service.
• Delivery Controller — a component that brokers and manages sessions.
• Delivery Group — an assignment of machines and published resources to users.
• FMA — FlexCast Management Architecture, the common product architecture since the 7.x generation.
• HDX — a set of technologies that serve and optimize the user’s remote session.
• Hosted Shared Desktop — a full desktop delivered from a multi-session server system.
• Machine Catalog — a logical collection of similarly managed machines.
• MCS — Machine Creation Services.
• Multi-session OS — an operating system that serves many user sessions at the same time.
• Non-persistent — a model in which the user’s system changes are not permanently retained.
• Persistent — a model that retains changes on the assigned machine.
• PVS — Citrix Provisioning, delivery of the system image by streaming.
• Single-session OS — an operating system intended for one active user session.
• VDA — Virtual Delivery Agent installed on the machine that delivers applications or a desktop.
• VDI — Virtual Desktop Infrastructure.
• XenApp — the historical name of the technology for publishing applications and desktops from shared hosts.
• XenDesktop — the historical name of the technology for delivering individual VDI desktops.

16. Summary

Citrix Virtual Apps and Desktops combines two historical technology streams. XenApp provided high density thanks to many sessions on a shared server system. XenDesktop provided individual VDI desktops, greater isolation and personalization at the cost of higher infrastructure consumption.

Today both models are elements of a single platform. The most important design decision is not choosing an old product name, but matching the VDA type, system persistence, degree of personalization, isolation and method of publishing to a specific group of users.

17. Sources — official vendor documentation

1. Citrix Virtual Apps and Desktops — documentation hub

2. Technical overview — Citrix Virtual Apps and Desktops 2607 LTSR

3. Delivery methods — Virtual Apps, VM-hosted apps and VDI

4. Delivery Controllers

5. Citrix DaaS — overview

6. Citrix DaaS — technical security overview

7. XenApp and XenDesktop 7.15 LTSR — archived documentation

8. Citrix Product Matrix — product lifecycle