The resource layers in the architecture are a way to group resources according to general functionality. Within each resource layer are specific XenDesktop components. Each component has a function and plays a role in the XenDesktop infrastructure. These components and their roles are discussed in the following section.
Citrix Receiver is a universal software client that provides secure, high-performance delivery of virtual desktops and applications to any device anywhere. Citrix Receiver is platform-agnostic, meaning that there is a receiver for just about every device out there, from Windows- to Linux-based thin clients to mobile devices including iOS and Android. In fact, some thin client vendors have performed close integration with the Citrix Ready program to embed the Citrix Receiver code directly into their homegrown operating system for seamless operation with XenDesktop.
Citrix Receiver must be installed on the end user client device in order to receive the desktop and applications from XenDesktop. It must also be installed on the virtual desktop in order to receive applications from the application servers (XenApp or XenDesktop), and this is taken care of for you automatically when installing the VDA on the virtual desktop machine.
Citrix Receiver provides users with self-service access to resources published on XenDesktop or XenApp servers. This software combines ease of deployment and uses and offers quick, secure access to hosted applications, desktops, and data.
A hypervisor is a thin operating system that hosts multiple instances of other operating systems. This concept of one hosting many is the fulcrum of the value of virtualization. XenDesktop is supported on three hypervisors—Citrix XenServer, VMware ESXi, and Microsoft Hyper-V.
Citrix NetScaler provides the frontend to XenDesktop resources. NetScaler is primarily an Application Delivery Controller (ADC) that can also perform load balancing. Its primary purpose for XenDesktop, however, is to provide the security for all communications using Secure Sockets Layer (SSL). Think of it this way: for those organizations that want to secure their communications, traffic comes into the NetScaler using encrypted SSL. You can choose not to use SSL, but it is not recommended.
Citrix StoreFront is the portal that authenticates users to site(s) hosting XenDesktop resources and manages stores of desktops and applications that users access. Active Directory does the actual authentication and interacts with StoreFront.
The Citrix Delivery Controller brokers access to desktops and applications and manages user access. Each site has one or more Delivery Controllers.
Citrix Studio is the management console that enables you to configure and manage your XenDesktop and XenApp deployment, eliminating the need for two separate management consoles for managing the delivery of desktops and applications.
Note
If you use provisioning services, also included in XenDesktop, then you need to use the provisioning server console to deploy the VMs on the hosting platform.
Studio provides various wizards to guide you through the process of setting up your environment, creating your workloads to host and assign applications and desktops, and assigning applications and desktops to users.
The Citrix License Server serves licenses. Every Citrix product and every XenDesktop user requires a Citrix license. Studio consults the License Server to check out and check in licenses.
The only exception is NetScaler, which is licensed from within NetScaler itself.
In XenDesktop, we use Microsoft SQL Server. The database is sometimes referred to as the data store. Almost everything in XenDesktop is database driven and the SQL database holds all state information, in addition to session and configuration information.
If the database server fails, existing connections to virtual desktops will continue to function until the user either logs off or disconnects from their virtual desktop. In XenDesktop version 7.6, Citrix introduced the Connection Leasing feature, which allows new connections to occur even if the database is unavailable. Citrix recommends you to implement SQL mirroring and clustering for high availability.
Microsoft Active Directory is required for authentication and authorization. Active Directory can also be used for controller discovery by desktops to discover the controllers within a site. Desktops determine which controllers are available by referring to information that controllers publish in Active Directory.
Note
If you don't want to use Active Directory for authentication, you can create an anonymous store in StoreFront and use local authentication.
Active Directory's built-in security infrastructure is used by desktops to verify that communications between controllers come from authorized controllers on the appropriate site. Active Directory's security infrastructure also ensures that the data exchanged by desktops and controllers is confidential.
Every machine in this architecture—virtual or physical, client, desktop, or server—requires an IP address. XenDesktop uses the Microsoft DHCP service to centrally manage IP addresses.
Every machine and service in XenDesktop needs a way to convert Fully Qualified Domain Names (FQDNs) into IP addresses so they can send packets out on the network and reach their destination. XenDesktop uses the Microsoft DNS service to do this.
A desktop is the instantiation of a complete Windows operating system, typically Windows XP, 7, or 8. In XenDesktop, we create the desktop VM and add the VDA to it so that it can work with XenDesktop and be delivered to clients. This will become the end user's virtual desktop.
A server is a virtual machine dedicated to performing one or more specific tasks on the XenDesktop site, for example, brokering connections (Delivery Controller). These virtual machines can be used to host applications. More importantly, these servers are used to host the important XenDesktop components such as StoreFront, Delivery Controller, Studio, Director, License Server, SQL Server, Active Directory, DHCP, and DNS.
All the XenDesktop components use storage. There are two types of storage in this architecture. First, there is SQL Server, which is used as the database for the XenDesktop components. Then, there are Virtual Disks (vDisks) and Personal Virtual Disks (PvDisks).
In a dedicated model, each user gets their own vDisk, which hosts the desktop OS. As you can imagine, the storage requirements for a dedicated vDisk model can grow quite substantially. In a pooled/shared model, several users share the same vDisk. There are other types of vDisk deployment models. The different types of vDisks are explained in the following table:
The concept of the PvDisk is powerful for the users. PvDisk provides a personalization feature for storing personal data from virtual desktops. Each user gets their own Personal vDisk that stores their user profile, data, and applications that are unique to them. They are smaller than OS vDisks. They allow you to scale by pooling and sharing vDisks among many users and giving them each their own smaller Personal vDisk. PvDisks are merged with vDisks at runtime—the appearance to the end user is seamless.
The Virtual Desktop Agent (VDA) has to be installed on the virtual machine to which users will be connecting. It enables the machines to register with controllers and manages the connection between the machines and the user devices. The VDA is installed on the operating system VM, such as Windows XP, 7, or 8, which gets served to the client. The VDA maintains a heartbeat with the Delivery Controller, updates policies, and registers with the Delivery Controller.