Technical overview 编辑

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

Key XenApp and XenDesktop components

This article is most helpful if you’re new to XenApp or XenDesktop. If you currently have a 6.x or earlier XenApp farm, or a XenDesktop 5.6 or earlier site, see the Changes in 7.x article, too.

This illustration shows the key components in a typical deployment, which is called a Site.

Delivery Controller:

The Delivery Controller is the central management component of a XenApp or XenDesktop Site. Each Site has one or more Delivery Controllers. It is installed on at least one server in the data center. For Site reliability and availability, Controllers should be installed on more than one server. If your deployment includes virtual machines hosted on a hypervisor or cloud service, the Controller services communicate with it to distribute applications and desktops, authenticate and manage user access, broker connections between users and their virtual desktops and applications, optimize use connections, and load-balance these connections.

The Controller’s Broker Service tracks which users are logged on and where, what session resources the users have, and if users need to reconnect to existing applications. The Broker Service executes PowerShell cmdlets and communicates with a broker agent on the VDAs over TCP port 80. It does not have the option to use TCP port 443.

The Monitor Service collects historical data and places it in the Monitor database. This service uses TCP port 80 or 443.

Data from the Controller services is stored in the Site database.

The Controller manages the state of desktops, starting and stopping them based on demand and administrative configuration. In some editions, the Controller allows you to install Profile Management to manage user personalization settings in virtualized or physical Windows environments.

Database:

At least one Microsoft SQL Server database is required for every XenApp or XenDesktop Site to store configuration and session information. This database stores the data collected and managed by the services that make up the Controller. Install the database within your data center, and ensure it has a persistent connection to the Controller. The Site also uses a Configuration Logging database and a Monitoring database. By default, those databases are installed in the same location as the Site database, but you can change this.

Virtual Delivery Agent (VDA):

The VDA is installed on each physical or virtual machine in your Site that you make available to users. Those machines deliver applications or desktops. The VDA enables the machine to register with the Controller, which allows the machine and the resources it is hosting to be made available to users. VDAs establish and manage the connection between the machine and the user device, 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 in the VDA. The broker agent hosts multiple plugins and collects real-time data. It communicates with the Controller over TCP port 80.

The word “VDA” is often used to refer to the agent as well as the machine on which it is installed.

VDAs are available 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 desktop operating systems allow only one user to connect to the desktop at a time. Linux VDAs are also available.

Citrix StoreFront:

StoreFront authenticates users to Sites hosting resources, and manages stores of desktops and applications that users access. It can host your enterprise application store, which gives users self-service access to the desktops and applications that you make available to them. It also keeps track of users’ application subscriptions, shortcut names, and other data. This helps ensure users have a consistent experience across multiple devices.

Citrix Receiver:

Installed on user devices and other endpoints (such as virtual desktops), Citrix Receiver provides users with quick, secure, self-service access to documents, applications, and desktops from any of the user’s devices, including smartphones, tablets, and PCs. Citrix Receiver provides on-demand access to Windows, Web, and Software as a Service (SaaS) applications. For devices that cannot install Citrix Receiver software, Citrix Receiver for HTML5 provides a connection through a HTML5-compatible web browser.

Citrix Studio:

Studio is the management console that enables you to configure and manage your XenApp and XenDesktop deployment. This console eliminates the need for separate management consoles to manage delivery of applications and desktops. Studio provides wizards to guide you through environment setup, creating your workloads to host applications and desktops, and assigning applications and desktops to users. 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 Controller, communicating over TCP port 80.

For more information, click this graphic:

Citrix Director:

Director is a web-based tool that enables IT support and help desk teams to monitor an environment, troubleshoot issues before they become system-critical, and perform support tasks for end users. You can use one Director deployment to connect to and monitor multiple XenApp or XenDesktop Sites.

Director displays:

Real-time session data from the Broker Service in the Controller. This includes data the Broker Service gets from the broker agent in the VDA.

Historical Site data from the Monitor Service in the Controller.

Data about HDX traffic (also known as ICA traffic) captured by HDX Insight from the NetScaler, if your deployment includes a NetScaler and your XenApp or XenDesktop edition includes HDX Insight.

You can also view and interact with a user’s sessions through Director, using Windows Remote Assistance.

Citrix License Server:

The License Server manages your Citrix product licenses. It communicates with the Controller to manage licensing for each user’s session and with Studio to allocate license files. You must create at least one license server to store and manage your license files.

Hypervisor or cloud service:

The hypervisor or cloud service hosts the virtual machines in your Site. These can be the VMs you use to host applications and desktops, and VMs you use to host the XenApp and XenDesktop components. A hypervisor is installed on a host computer dedicated entirely to running the hypervisor and hosting virtual machines.

XenApp and XenDesktop support various hypervisors and cloud services.

Although many XenApp and XenDesktop deployments require a hypervisor, you don’t need one to provide Remote PC Access. You also don’t need a hypervisor when you are using Provisioning Services (PVS to provision VMs.

For more information about:

• Ports, see Network ports.
• Databases, see Databases.
• Windows services in XenApp and XenDesktop components, see Configure user rights.
• Supported hypervisors and cloud services, see System requirements.

Additional components

The following additional components, not shown in the illustration above, can also be included in XenApp or XenDesktop deployments. For more information, see their documentation.

Provisioning Services (PVS):

PVS is an optional component that is available with some editions. It provides an alternative to MCS for provisioning virtual machines. Whereas MCS creates copies of a master image, PVS streams the master image to user device. PVS doesn’t require a hypervisor to do this, so you can use it to host physical machines. PVS communicates with the Controller to provide users with resources.

NetScaler Gateway:

When users connect from outside the corporate firewall, XenApp and XenDesktop can use Citrix NetScaler Gateway (formerly Access Gateway) technology to secure these connections with TLS. The NetScaler Gateway or NetScaler VPX virtual appliance is an SSL VPN appliance that is deployed in the demilitarized zone (DMZ) to provide a single secure point of access through the corporate firewall.

NetScaler SD-WAN:

In deployments where virtual desktops are delivered to users at remote locations such as branch offices, Citrix NetScaler SD-WAN technology can be employed to optimize performance. (This technology was formerly Citrix CloudBridge, Branch Repeater, or WANScaler.) Repeaters accelerate performance across wide-area networks. With repeaters in the network, users in the branch office experience LAN-like performance over the WAN. NetScaler SD-WAN can prioritize different parts of the user experience. For example, the user experience does not degrade in the branch location when a large file or print job is sent over the network. HDX WAN optimization provides tokenized compression and data deduplication, reducing bandwidth requirements and improving performance.

How typical deployments work

A Site is 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 Site consists of VDA-installed 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 in 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. Because sessions are affected by 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 on the Controller. The Broker Service then obtains their profiles and available resources based on the policies set for them.

How user connections are handled

To start a session, the user connects either through Citrix Receiver, which is installed on the user’s device, or a StoreFront Citrix Receiver for Web site.

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 which resources are needed by communicating with the Broker Service. Citrix recommends that administrators place an SSL certificate on StoreFront to encrypt the credentials coming from Citrix Receiver.

The Broker Service determines which desktops and applications the user is allowed to access.

After the credentials are verified, information about available applications or desktops is sent back to the user through the StoreFront-Citrix Receiver pathway. When the user selects applications or desktops from this list, that information goes back down the pathway to the Controller. The Controller then 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 then 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 to Citrix Receiver. A set of required parameters is collected on StoreFront. These parameters are then sent to Citrix Receiver, either as part of the Receiver-StoreFront protocol conversation, or converted to an Independent Computing Architecture (ICA) file and downloaded. 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 (Citrix Receiver, StoreFront, and Controller).

The connection between Citrix 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 Citrix policies.

After the client connects to the VDA, the VDA notifies the Controller that the user is logged on. The Controller sends this information to the Site database and starts logging data in the Monitoring database.

How data access works

Every session produces data that IT can access through Studio or Director. Using Studio, administrators can access real-time data from the Broker Agent to manage sites. Director accesses to the same real-time data plus historical data stored in the Monitoring database. Director also accesses HDX data from NetScaler Gateway for help desk support and troubleshooting.

Within the Controller, the Broker Service reports session data for every session on the 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 communicates only with the Broker Service, so it accesses only 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.

Deliver desktops and applications: machine catalogs, Delivery Groups, and Application Groups

You set up the machines that will deliver applications and desktops with machine catalogs. Then, you create Delivery Groups that specify the applications and desktops that will be available (using some or all of the machines in the catalogs), and which users can access them.

Machine catalogs:

Machine catalogs are collections of virtual or physical machines that you manage as a single entity. These machines, and the application or virtual desktops on them, are the resources you provide to users. All of the machines in a catalog have the same operating system and the same VDA installed. They also have the same applications or virtual desktops.

Typically, you create a master image and use it to create identical VMs in the catalog. For VMs you can specify the provisioning method for the machines in that catalog: Citrix tools (PVS or MCS) or other tools. Alternatively, you can use your own existing images. In that case, you must manage target devices on an individual basis or collectively using third-party electronic software distribution (ESD) tools.

Valid machine types are:

• Server OS machines: Virtual or physical machines based on a server operating system. Used for delivering XenApp published apps (known as server-based hosted applications), and XenApp published desktops (known as server-hosted desktops). These machines allow multiple users to connect to them at one time.
• Desktop OS machines: Virtual or physical machines based on a desktop operating system. Used for delivering VDI desktops (can optionally be personalized), VM-hosted apps (applications from desktop OSs) and hosted physical desktops. Only one user at a time can connect each of these desktops.
• Remote PC Access: Enables remote users to access their physical office PCs from any device running Citrix Receiver. The office PCs are managed through the XenDesktop deployment, and require user devices to be specified in a whitelist.

For more information, see Create machine catalogs.

Delivery Groups:

Delivery Groups specify which users can access which applications and/or desktops on which machines. Delivery Groups contain machines from your machine catalogs, and Active Directory users who have access to your Site. You might assign users to your Delivery Groups by their Active Directory group, because Active Directory groups and Delivery Groups are ways to group users with similar requirements.

Each Delivery Group can contain machines from more than one catalog, and each catalog can contribute machines to more than one Delivery Group. However, each individual machine can only belong to one Delivery Group at a time.

You define which resources users in the Delivery Group can access. For example, to deliver different applications to different users, you might install all of the applications on the master image for one catalog and create enough machines in that catalog to distribute among several Delivery Groups. You can then configure each Delivery Group to deliver a different subset of applications that are installed on the machines.

For more information, see Create Delivery Groups.

Application Groups:

Application Groups provide application management and resource control advantages over using more Delivery Groups. Using the tag restriction feature, you can use your existing machines for more than one publishing task, saving the costs associated with deployment and managing additional machines. A tag restriction can be thought of as subdividing (or partitioning) the machines in a Delivery Group. Application Groups can also be helpful when isolating and troubleshooting a subset of machines in a Delivery Group.

For more information, see Create Application Groups.