XenApp and XenDesktop


Designing a desktop virtualization solution is simply a matter of following a proven process and aligning technical decisions with organizational and user requirements. Without the standardized and proven process, architects tend to randomly jump from topic to topic, which leads to confusion and mistakes. The recommended approach focuses on working through five distinct layers:

Five layer design model image

The top three layers are designed for each user group independently, which were identified during the user segmentation section of the assess phase. These layers define the users’ resources and how users access their resources. Upon completion of these three layers, the foundational layers (control and hardware) are designed for the entire solution.

This process guides the design thinking in that decisions made higher up impact lower level design decisions.

Layer 0: Conceptual Architecture

The conceptual architecture helps define the overarching strategies for the entire solution based on business objectives and organizational structure.

Although an organization’s conceptual architecture will change over the coming years, it is worthwhile to start the design phase by defining the long-term objectives around delivery models and the physical, geographical distribution of solution.

Decision: Delivery Model

A XenDesktop and XenApp solution can take on many delivery forms. The organization’s business objectives help select the right approach. Even though the infrastructure remains the same for all delivery models, the local IT team’s management scope changes.

  • On Premises - All components hosted from the organization’s local data center. The onpremises model requires the local IT team to manage every aspect of the solution.

On-premises architecture image

  • Public Cloud - All components hosted from a public cloud infrastructure using Infrastructure as a Service (IaaS). The public cloud model eliminates hardware management from the local IT team‘s management scope.

Public cloud architecture image

  • Hybrid Cloud - A single implementation executes from an on-premises data center as well as the public cloud. Even though components of the solution are using different hosting providers, the entire solution is a single solution using the same code and managed as a single entity. The local IT team continues to manage all aspects of the solution except for the hardware associated with the cloud-hosted resources.

Hybrid cloud architecutre image

  • Citrix Cloud - The XenApp and XenDesktop Service offering from Citrix Cloud breaks a typical deployment into multiple management domains. The access and control layer components are hosted and managed in the Citrix cloud by Citrix while the resource layer components continues to be managed by the local IT team either as an on-premises, public cloud or hybrid cloud model. Citrix manages the hardware, sizing and updates to the access and control components while the local IT team manages the resources. In addition, if the public cloud hosts the resources, the local IT team does not have to manage the resource hardware. Citrix Cloud continues to expand the number of offerings to help solve specific user cases. To learn more and understand the full array of offerings, please explore the workspace services within the Citrix Cloud.

Citrix cloud architecture image

Decision: Site Topology

A XenApp and XenDesktop site groups desktops and applications together to form a single architectural and management entity. All persistent and dynamic data for the site, including site configuration, desktop assignments, and session state, is stored in a site’s database.

A site can be contained within a single location, span across multiple locations or be a partial location. Through rigorous testing, a single XenApp/XenDesktop site can support 40,000 or more concurrent sessions.

Delivery site 1 image

Delivery site 2 image

Delivery site 3 image

Zones subdivide single sites, often associated with geographical locations. There are several factors to consider when determining the overall topology of the XenApp and XenDesktop solution:

  • Risk Tolerance – Create multiple XenDesktop sites to minimize the impact from a site-wide outage. For example, corruption of the XenDesktop site database could affect site-wide availability. For many organizations, the decreased risk from implementing multiple sites outweighs the additional management overhead and supporting infrastructure required.

Experience from the Field

Finance – A large financial institution hosts 10,000 desktops from a single datacenter. To reduce risk, it was decided that no site should exceed 5,000 desktops. Therefore, despite the desktops being connected by a fast and redundant network, two sites were created.

  • Security – Although delegated administration is available, high-security organizations may require complete separation between environments to demonstrate compliance with specific service level agreements.

Experience from the Field

Retail – A retail organization required complete separation for employees responsible for managing financial data. To meet this requirement, two separate sites were created within the same datacenter – one for t he financial employees and a second for all other employees.

  • Administrative Boundaries – Due to billing/charge back requirements or how IT is structured, multiple sites might be required to separate administrative boundaries.

  • Geographical Connectivity – Although the implementation of zones does allow a single site to span geographical locations, there must be enough bandwidth between the satellite zone and primary zone for the site database to capture the session information. Higher latency or larger zones impacts response times for the user.

Variable XenApp and XenDesktop 7.13 XenApp and XenDesktop 7.11
Latency (ms) 90 250
Concurrent requests 48 48
Average response time 3.7 7.6
Brokering requests per second 12.6 6.3
Time to launch 10,000 users 13 minutes 26 minutes
Session count Max concurrent sessions launches Min site-to-site bandwidth Max site-to-site round trip latency
Less than 50 20 1 Mbps 250 ms
50 to 500 25 1.5 Mbps 100 ms
500 to 1,000 30 2 Mbps 50 ms
1,000 to 3,000 60 8 Mbps 10 ms
Over 3,000 60 8 Mbps 5 ms

In general, administrators should minimize the number of XenDesktop sites and zones to reduce architectural complexity and administrative effort.

Decision: Image Management Strategy

A XenApp and XenDesktop solution requires the creation and management of master images. Organizations must decide early what strategy to pursue for image management.

Installed Images

An installed image requires the administrator to install the operating system and applications for each image. This approach is straightforward but creates a duplication of effort as the admin installs the same operating system and core applications across multiple master images.

Maintaining master images also includes duplication of effort as the same operating system version and core applications are part of multiple images, each requiring the same update process.

Scripted Images

Administrators can automate many of the tasks associated with installed images with scripting or automation tools. Many operating system and application installs support automated scripting, which mitigates the duplication of effort impact on the administrator’s time with installed images.

Unfortunately, learning, creating, and maintaining a scripting framework for the entire image is challenging and time consuming. Scripting an entire build takes time and often results in unexpected failures if directory structures change, processes take too long to complete or a filename changes.

Layered Images

Each unique operating system (Windows 10, Windows 2012R2 and Windows 2016), platform (XenApp/XenDesktop 7.13 VDA, XenApp/XenDesktop 7.14 VDA and XenApp/XenDesktop 7.15 VDA) and application (Microsoft Office, Adobe Acrobat, Google Chrome and Mozilla Firefox) is a layer. A master image is the merging of one operating system layer, one platform and many applications.

A layered image approach eliminates the duplication of effort challenges associated with installed and scripted images. Each unique layer is available to any master image. When an application requires an update, that layer receives the updates and all master images utilizing the layer receives the update. If an organization requires ten unique Windows 10 images, each of the ten images shares the same Windows 10 layer. When the administrator needs to upgrade the VDA from version 7.14 to 7.15 across ten images, the administrator only updates a single platform layer.

Initially, the layered image approach does require more time to deploy because the administrator must build the organization’s library of layers. However, once the layers are available, the time to maintain the images is drastically reduced.