- Cumulative Update 6 (CU 6)
- Cumulative Update 5 (CU5)
- Cumulative Update 4 (CU4)
- Cumulative Update 3 (CU3)
- Cumulative Update 2 (CU2)
- Cumulative Update 1 (CU1)
- Long Term Service Release (LTSR)
- Features not in this release
- Known issues
- System requirements
- Technical overview
- Install and upgrade analytics
- Prepare to install
- Prepare the virtualization environment - VMware
- Prepare the virtualization environment - Microsoft System Center Virtual Machine Manager
- Prepare for using Microsoft System Center Configuration Manager
- Install using the graphical interface
- Install using the command line
- Create a Site
- Install or remove Virtual Delivery Agents using scripts
- Install VDAs using the standalone package
- Machine catalogs
- Delivery groups
- XenApp published apps and desktops
- VM hosted apps
- VDI desktops
- Remote PC Access
- Local App Access and URL redirection
- Server VDI
- Remove components
Upgrades and migration
- Install and upgrade analytics
- Upgrade a deployment
- Migrate XenApp 6.x
- Install and upgrade analytics
- Migrate XenDesktop 4
- Work with policies
- Policy templates
- Create policies
- Compare, prioritize, model, and troubleshoot policies
- Default policy settings
Policy settings reference
- ICA policy settings
- Load management policy settings
- Profile management policy settings
- Receiver policy settings
- Virtual Delivery Agent policy settings
- Virtual IP policy settings
- Configure COM Port and LPT Port Redirection settings using the registry
- Connector for Configuration Manager 2012 policy settings
- Connections and resources
- Connection leasing
- Virtual IP and virtual loopback
- Secondary database locations
- Delivery Controller environment
- Session management
- Using Search in Studio
- IPv4/IPv6 support
- Client folder redirection
- Personal vDisk 7.x (Excluded from LTSR)
- User profiles
- Get started with Session Recording
- Grant access rights to users
- Create and activate recording policies
- Disable or enable recording
- Configure the connection to the Session Recording Server
- Create notification messages
- Enable custom event recording
- Enable or disable live session playback and playback
- Enable or disable playback protection
- Enable and disable digital signing
- Specify where recordings are stored
- Specify file size for recordings
- View recordings
- Troubleshoot Session Recording
- Reference - Manage your database records
- Third Party Notices
- Personal vDisk
- Configuration Logging
- Monitor Service OData API
- XenApp and XenDesktop SDK
- Citrix VDI Best Practices for XenApp and XenDesktop 7.6 LTSR
- Third party notices
May 28, 2016
XenApp and XenDesktop are virtualization solutions that give IT control of virtual machines, applications, licensing, and security while providing anywhere access for any device.
XenApp and XenDesktop allow:
- End users to run applications and desktops independently of the device’s operating system and interface.
- Administrators to manage the network and provide or restrict access from selected devices or from all devices.
- Administrators to manage an entire network from a single data center.
XenApp and XenDesktop share a unified architecture called FlexCast Management Architecture (FMA). FMA’s key features are the ability to run multiple versions of XenApp or XenDesktop from a single Site and integrated provisioning.
A typical XenApp or XenDesktop environment consists of a few key technology components, which interact when users connect to applications and desktops, and log data about Site activity.
A software client that is installed on the user device, supplies the connection to the virtual machine via TCP port 80 or 443, and communicates with StoreFront using the StoreFront Service API.
The interface that authenticates users, manages applications and desktops, and hosts the application store. StoreFront communicates with the Delivery Controller using XML. Delivery Controller The central management component of a XenApp or XenDesktop Site that consists of services that manage resources, applications, and desktops; and optimize and balance the loads of user connections. Virtual Delivery Agent (VDA) An agent that is installed on machines running Windows Server or Windows desktop operating systems that allows these machines and the resources they host to be made available to users. The VDA-installed machines running Windows Server OS allow the machine to host multiple connections for multiple users and are connected to users on one of the following ports:
- TCP port 80 or port 443 if SSL is enabled
- TCP port 2598, if Citrix Gateway Protocol (CGP) is enabled, which enables session reliability
- TCP port 1494 if CGP is disabled or if the user is connecting with a legacy client
A Delivery Controller service that tracks which users are logged in and where, what session resources the users have, and if users need to reconnect to existing applications. The Broker Service executes PowerShell and communicates with the Broker agent over TCP port 80. It does not have the option to use TCP port 443.
An agent that hosts multiple plugins and collects real-time data. The Broker agent is located on the VDA and is connected to the Controller by TCP port 80. It does not have the option to use TCP port 443.
A Delivery Controller component that collects historical data and puts it in the Site database by default. The Monitor Service communicates on TCP port 80 or 443.
Bundled user information that is required to connect to the VDA.
A Microsoft SQL database that stores data for the Delivery Controller, such as site policies, machine catalogs, and delivery groups.
A data-access solution that provides secure access inside or outside the LAN’s firewall with additional credentials.
A web-based tool that allows administers access to real-time data from the Broker agent, historical data from the Site database, and HDX data from NetScaler for troubleshooting and support. Director communicates with the Controller on TCP port 80 or 443.
A management console that allows administers to configure and manage Sites, and gives access to real-time data from the Broker agent. Studio communicates with the Controller on TCP port 80.
XenApp and XenDesktop Sites are made up of machines with dedicated roles that allow for scalability, high availability, and failover, and provide a solution that is secure by design. A XenApp or XenDesktop Site consists of VDA-installed Windows servers and desktop machines, and the Delivery Controller, which manages access.
The VDA enables users to connect to desktops and applications. It is installed on server or desktop machines within the data center for most delivery methods, but it can also be installed on physical PCs for Remote PC Access.
The Controller is made up of independent Windows services that manage resources, applications, and desktops, and optimize and balance user connections. Each Site has one or more Controllers, and because sessions are dependent on latency, bandwidth, and network reliability, all Controllers ideally should be on the same LAN.
Users never directly access the Controller. The VDA serves as an intermediary between users and the Controller. When users log on to the Site using StoreFront, their credentials are passed through to the Broker Service, which obtains their profiles and available resources based on the policies set for them.
To start a XenApp or XenDesktop session, the user connects either via Citrix Receiver, which is installed on the user’s device, or via Receiver for Web (RFW).
Within Receiver, the user selects the physical or virtual desktop or virtual application that is needed.
The user’s credentials move through this pathway to access the Controller, which determines what resources are needed by communicating with a Broker Service. It is recommended for administrators to put a SSL certificate on StoreFront to encrypt the credentials coming from Receiver.
The Broker Service determines which desktops and applications the user is allowed to access.
Once the credentials are verified, the information about available apps or desktops is sent back to the user through the StoreFront-Receiver pathway. When the user selects applications or desktops from this list, that information goes back down the pathway to the Controller, which determines the proper VDA to host the specific applications or desktop.
The Controller sends a message to the VDA with the user’s credentials and sends all the data about the user and the connection to the VDA. The VDA accepts the connection and sends the information back through the same pathways all the way to Receiver. Receiver bundles up all the information that has been generated in the session to create Independent Computing Architecture (ICA). file on the user’s device if Receiver is installed locally or on RFW if accessed through the web. As long as the Site was properly set up, the credentials remain encrypted throughout this process.
The ICA file is copied to the user’s device and establishes a direct connection between the device and the ICA stack running on the VDA. This connection bypasses the management infrastructure: Receiver, StoreFront, and Controller.
The connection between Receiver and the VDA uses the Citrix Gateway Protocol (CGP). If a connection is lost, the Session Reliability feature enables the user to reconnect to the VDA rather than having to relaunch through the management infrastructure. Session Reliability can be enabled or disabled in Studio.
Once the client connects to the VDA, the VDA notifies the Controller that the user is logged on, and the Controller sends this information to the Site database and starts logging data in the Monitoring database.
Every XenApp or XenDesktop session produces data that IT can access through Studio or Director. Studio allows administrators to access real-time data from the Broker Agent to better manage sites. Director has access to the same real-time data plus historical data stored in the Monitoring database as well as HDX data from NetScaler Gateway for help-desk support and troubleshooting purposes.
Within the Controller, the Broker Service reports session data for every session on the virtual machine providing real-time data. The Monitor Service also tracks the real-time data and stores it as historical data in the Monitoring database.
Studio can communicate only with the Broker Service; therefore, it has access only to real-time data. Director communicates with the Broker Service (through a plugin in the Broker Agent) to access the Site database.
Director can also access NetScaler Gateway to get information on the HDX data.