Desktop virtualization(sometimes called client virtualization), as a concept, separates a personal computer desktop environment from a physical machine using the client–server model of computing. To check about what is VDI, Click Here

Client Hypervisor:

A client hypervisor is a hypervisor that resides on a laptop, PC or other client device. A hypervisor is a program that allows multiple operating systems to share a single hardware host.

XenDesktop Terminology and Definitions:

• Farms are now called Sites (Servers that point to same database are grouped together called sites). Deployment of XenDesktop in a single geographical location may be called as a site.
• Catalogs are collections of user desktops managed as a single entity. If we want to publish VMs created by vCenter, then they can be called vCenter catalog, similarly If we want to publish VMs created by Xenserver, then they can be called XenServer catalog. Basically catalogs define Where the desktops come from. Catalogs specify virtual machines (VMs) or physical computers that host user desktops, the Active Directory computer accounts assigned to those VMs or computers, and, in some cases, the master VM that is copied to create the user desktops.
• Desktop Groups are created from one or more catalogs. Desktop groups define how desktops get used, and who uses them. For more info about desktop groups, Click Here. A single desktop group can contain desktops from a number of catalogs rather than being limited, as in earlier versions, to a single hypervisor pool. Also, a single desktop group can be published to users so that a single user may access multiple desktops in the group, and a single desktop may be assigned for use by multiple users. Desktops can also be assigned to client machines, rather than users, if required.
• A host is the infrastructure on which desktops are hosted, which comprises of hypervisors (resource pools or clusters), storage, XenServer, Vmware ESX etc. (OR)A host is a representation of a XenServer pool (or ESX or SCVMM cluster), with storage and a virtual network, where you create and store virtual machines (VMs) for your user desktops. This infrastructure allows you to efficiently manage the distribution of VMs in your hypervisor infrastructure. A host connection represents the credentials and address needed to access the host; these can be used by more than one host.
• Desktop Studio is the new MMC 3.0 based management console used to configure and manage XenDesktop sites.

XenDesktop provides the ability to dynamically create virtual desktops (created in a central pool) which can then be accessed directly by users from their computers using remote technologies provided in conjunction with the Citrix Receiver. The key components in this solution are:

• Web Interface
• Controller
• Hypervisor
• SQL Database

Web Interface

The Web Interface provides the entry point for the user to initiate a connection to a virtual desktop. The Web Interface is a portal which can be tailored to suit corporate tastes and can provide access to other Citrix based services.

Hypervisor

Citrix XenServer, VMware vSphere (ESX) and Microsoft Hyper-V can provide the hypervisor technology for virtual desktops which are created in a data centre and then accessed remotely by users. XenServer is based on virtualisation technology acquired from Xen and redeveloped by Citrix. XenDesktop uses an open architecture allowing it to be used with different hypervisors such as Microsoft (Hyper-V), Citrix XenServer and VMware (ESX). The hypervisor provides a pool of desktops known as the ‘Hypervisor Pool’, which are made available remotely to end users.

Controller

The controller (previously known as the Desktop Delivery Controller) brokers user access to desktops through the integration with existing authentication services such as Microsoft’s Active Directory. The Controller is the server-side component that is responsible for communicating with your virtualization infrastructure to create new desktops, distributing desktops to users, managing user access through policies and power managing desktops. A number of Controllers are grouped together (mostly for redundancy purposes) to form a XenDesktop Site and MCS is one component of the Controller and is responsible for a subset of the listed actions, particularly the creation and deletion of VMs and differencing disks. The controller monitors the connection state between the users and their desktops and can be configured to select particular desktops (dedicated) or to use a ‘pool’ of similar desktops. The controller also includes the ‘Machine Creation Service’, a cut down version of Provisioning Services (PVS) which allows provisioning of virtual machines to hypervisor pools. The full version of Provisioning Services allows provisioning to physical desktops aswell as hypervisor pools in comparison.

XenDesktop Site

The term ‘Site’ replaces the term ‘Farm’ which Citrix used with previous versions and with their presentation server (XenApp) product. The site concept has some similarity with the Active Directory Site concept, where the connectivity within a site, dictates the boundaries of a site. A XenDesktop site contains the hypervisor pool, which contains the virtual desktops which are accessed remotely by end users.

Desktop Studio

Desktop Studio provides the management interface which allows for the configuration and management of XenDesktop deployments. Desktop Studio includes various wizards which can guide administrators through the process of setting up a XenDesktop environment, creating desktops and assigning desktops to users.

Desktop Director

Enables 1st Line (level-1) and 2nd Line (level-2) IT Support staff to monitor XenDesktop deployments and perform day-to-day maintenance tasks. Support staff can also view and interact with a user’s session, using Microsoft Remote Assistance, to troubleshoot problems.Citrix online plug-in The Citrix online plug-in is installed on user devices and enables direct ICA connections from user devices to virtual desktops.

XenDesktop Licensing

XenDesktop is licensed in either per user or per device mode for all Enterprise, Platinum and VDI editions, with the VDI edition including an additional concurrent user (CCU) licensing option. There is also an Express edition designed for technology professionals to quickly deploy a ‘Proof of Concept’ (POC) environment to evaluate XenDesktop. The Express edition is limited to 10 licenses.

SQL Database

A SQL Database is required to host information from the XenDesktop site. For resilience, it is recommended some form of clustering is used to ensure the availability of the database. Posted in QIPEOPLE

Key Architectural Differences:

In addition to the new features, note the following differences in XenDesktop 5’s design and the consequences of these:

• No IMA data store. XenDesktop 5 no longer uses the IMA data store as the central database in which to store configuration information. Instead, a Microsoft SQL Server database is used as the data store for both configuration and session information. This means:
  • Database requirements are different: Microsoft Access and Oracle are no longer supported databases.
  • Terminal Services is no longer required on servers running the controller.
  • There is no longer a dedicated zone master. In previous XenDesktop versions, there was a zone master/data collector responsible for user connection requests and communication with hypervisors. In XenDesktop 5, this function is distributed evenly across all controllers in the site.
  • Due to reliance on Microsoft SQL Server, to ensure failover should the database become unavailable, you must use either SQL clustering or mirroring, or deploy the database as a virtual machine and use your hypervisor’s high availability features instead. For more information about planning for high availability, see High Availability Planning.
• Registry-based discovery. The default mechanism for desktops to find controllers is now registry-based. An Active Directory Organizational Unit is no longer required, although you can still use Active Directory-based registration. Active Directory is still needed in a XenDesktop deployment for authentication and authorization, therefore machines need to be domain-joined regardless of whether you use registry-based discovery or not.
• SDKs. XenDesktop 5 provides a new PowerShell SDK which allows you to perform the same tasks as you would with the Desktop Studio console. You can also perform tasks with the SDK that you cannot do with the console, such as assigning an IP address to a desktop, rather than a user name. Desktop Studio is built upon the PowerShell SDK; you can display the PowerShell in use in the console. For more information about using the SDK, see Using the XenDesktop SDK and the PowerShell cmdlets. Note that the new PowerShell SDK is not compatible with the SDK associated with previous XenDesktop releases.

Check out the  Citrix Knowledge Center Articles: CTX121478, CTX117452, CTX125177, CTX123058 for more info about XenDesktop. posted in Citrix eDocs