Learn about product name changes here.
Citrix Virtual Apps and Desktops are virtualization solutions that give IT control of virtual machines, applications, licensing, and security while providing anywhere access for any device.
Citrix Virtual Apps and Desktops 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.
Citrix Virtual Apps and Desktops share a unified architecture called FlexCast Management Architecture (FMA). FMA’s key features are the ability to run multiple versions of Citrix Virtual Apps or Citrix Virtual Desktops from a single Site and integrated provisioning.
This article is most helpful if you’re new to Citrix Virtual Apps and Desktops. If you currently have a 6.x or earlier XenApp farm, or a XenDesktop 5.6 or earlier site, see Changes in 7.x, too.
This illustration shows the key components in a typical deployment, which is called a Site.
The Delivery Controller is the central management component of a 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 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 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.
At least one Microsoft SQL Server database is required for every 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 in turn 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. VDAs also verify that a Citrix license is available for the user or session, and apply policies that are 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.
StoreFront authenticates users 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 that users have a consistent experience across multiple devices.
Citrix Workspace app
Installed on user devices and other endpoints (such as virtual desktops), Citrix Workspace app provides users with quick, secure, self-service access to documents, applications, and desktops. Citrix Workspace app provides on-demand access to Windows, Web, and Software as a Service (SaaS) applications. For devices that cannot install the device-specific Citrix Workspace app software, Citrix Workspace app for HTML5 provides a connection through an HTML5-compatible web browser.
Studio is the management console where you configure and manage your Citrix Virtual Apps and Desktops deployment. Studio eliminates the need for separate management consoles for managing delivery of applications and desktops. Studio provides wizards to guide you through environment setup, creating 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.
Here’s a Studio overview.
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 Citrix Virtual Apps or Citrix Virtual Desktops Sites.
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.
Historical Site data from the Monitor Service in the Controller.
Director uses the ICA performance and heuristics data captured by the Citrix Gateway device to build analytics from the data and then presents it to the administrators.
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. A Site must have 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, as well as VMs you use to host the Citrix Virtual Apps and Desktops components. A hypervisor is installed on a host computer dedicated entirely to running the hypervisor and hosting virtual machines.
Citrix Virtual Apps and Desktops support various hypervisors and cloud services.
Although many deployments require a hypervisor, you don’t need one to provide Remote PC Access. A hypervisor is also not required when you are using Provisioning Services (PVS) to provision VMs.
For more information, see:
- Network ports.
- Windows services in Citrix Virtual Apps and Desktops components: Configure user rights.
- Supported hypervisors and cloud services: System requirements.
The following additional components, not shown in the illustration above, can also be included in Citrix Virtual Apps and Desktops deployments. For more information, see their documentation.
Citrix Provisioning (formerly Provisioning Services) 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 devices. 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.
When users connect from outside the corporate firewall, Citrix Virtual Apps and Desktops can use Citrix Gateway (formerly Access Gateway and NetScaler Gateway) technology to secure these connections with TLS. The Citrix Gateway or VPX virtual appliance is an SSL VPN appliance that is deployed in the demilitarized zone (DMZ). It provides a single secure point of access through the corporate firewall.
In deployments where virtual desktops are delivered to users at remote locations such as branch offices, Citrix SD-WAN technology can be employed to optimize performance. Repeaters accelerate performance across wide-area networks. With repeaters in the network, users in the branch office experience LAN-like performance over the WAN. Citrix SD-WAN can prioritize different parts of the user experience so that, 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, dramatically 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 using StoreFront, their credentials pass through to the Broker Service on the Controller. The Broker Service then obtains 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 Workspace app installed on the user’s device, or a StoreFront 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 a Broker Service. Citrix recommends that administrators place an SSL certificate on StoreFront to encrypt the credentials coming from Citrix Workspace app.
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 Workspace app 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 Workspace app. A set of required parameters is collected on StoreFront. These parameters are then sent to Citrix Workspace app either as part of the Citrix-Workspace-app-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 Workspace app, StoreFront, and Controller).
The connection between Citrix Workspace app 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 then sends this information to the Site database and starts logging data in the monitoring database.
How data access works
Every Citrix Virtual Apps and Desktops 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 the same data plus historical data stored in the Monitoring database. It 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; 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 Citrix Gateway to get information on the HDX data.
Deliver desktops and applications
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 machines in the catalogs), and which users can access them. Optionally, you can then create Application Groups to manage collections of applications.
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 your users. All 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 (Citrix Provisioning 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 with a server operating system. Used for delivering Citrix Virtual Apps published apps (also known as server-based hosted applications) and Citrix Virtual Apps published desktops (also known as server-hosted desktops). These machines allow multiple users to connect to them at one time.
- Desktop OS machines: Virtual or physical machines with a desktop operating system. Used for delivering VDI desktops (desktops running desktop OSs that can optionally be personalized), VM-hosted apps (applications from desktop OSs), and hosted physical desktops. Only one user at a time can connect to each of these desktops.
- Remote PC Access: Enables remote users to access their physical office PCs from any device running Citrix Workspace app. The office PCs are managed through the Citrix Virtual Desktops deployment, and require user devices to be specified in a whitelist.
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 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.