XenDesktop - Required and optional components
There are many components involved in a XenDesktop environment. Some are required. Some are optional. Some are optional, though recommended for best practice and functionality.
As with any infrastructure component, a XenDesktop environment should be designed utilizing an N+1 model. N+1 is a design model in which systems are built with redundancy. As an example, heavily utilized web based store fronts have multiple web servers available to spread around connections and to ensure that the failure of any one single server does not render the environment unavailable.
Desktop Delivery Controller
The Desktop Delivery Controller (DDC) is the core XenDesktop service. The DDC manages and controls access to the desktops via an agent known as the Virtual Desktop Agent (VDA). When a desktop boots to Windows, the VDA registers with the DDC knows the the state of the desktop (on, off, idle, et cetera). A single DDC can handle a couple thousand desktops, though planning for two is recommended for best practice.
Farm information is stored in a database. XenDesktop 4 supports a variety of databases, including Access and Microsoft SQL. However, with XenDesktop 5 Citrix now only supports Microsoft SQL. SQL Server Express can be utilized and is included with an installation of XenDesktop 5, though a clustered SQL Server environment is recommended, which is a feature not available with SQL Server Express.
Also worth mentioning is the criticality of the database. Unlike XenApp, which can more-or-less function without the database (although some functionality is lost), XenDesktop 5 cannot function without the database. For this reason a redundant database system is highly recommended.
A License Server is required to keep track of license utilization in a XenDesktop environment. The same License Server can also be used to manage license utilization for other Citrix productions, including XenApp and Provisioning Services.
Web Interface (WI) serves as the portal to the XenDesktop environment. Users connect to the Web Interface to gain access to hosted desktops. WI utilizes IIS and can accept connections over HTTP or HTTPS. HTTPS sites will require an SSL certificate either from an internal Certificate Authority or from a well-known third party Certificate Authority (e.g. RapidSSL, Verisign, etc). Only a single Web Interface server is required, though two is recommended for redundancy.
Hypervisors are needed to host virtual desktops. XenDesktop supports XenServer, VMWare ESX, and Hyper-V. The choice of which hypervisor to use is one of personal choice. I usually recommend XenServer for those purchasing XenDesktop licensing as XenServer is included. A second reason is to eliminate finger pointing. Should a support issue arise only one company is called. Multiple hypervisors will likely be needed for any deployment number more than a few dozen desktops, and again observe the standard N+1 model to ensure the hypervisor pool can sustain the loss of a host without negatively impacting performance.
A hypervisor is only listed as required as I am focusing on deploying XenDesktop in a virtual environment in which the Windows desktop will run in a virtual machine. If you are instead using physical machines (e.g. blades) then obviously a hypervisor won’t be necessary.
The Receiver is the client used to connect to hosted desktops. Citrix offers two clients: a Web client and a XenApp Services client. The Web client is used to direct users to a logon page through their web browser. This is a good option for kiosk workstations or when the user does not need to interact with the local workstation. The XenApp Services client is used to place icons to hosted desktops on the users Start Menu and/or Desktop. This is a good option if the user will still require access to their local workstation.
Provisioning Services (PVS) is utilized to stream the contents of a hard disk from a virtual hard disk (vDisk) to physical and virtual computers. Although PVS has always been optional, it was required for anything more than basic virtualized desktop deployments with XenDesktop 4 and thus was treated as more-or-less required. With XenDesktop 5 Citrix has introduced Machine Creation Services which has the ability to deliver pooled non-volatile desktops, somewhat taking the place of PVS. Still, PVS needs to be considered if delivering access to volatile desktops and for the ability to stream XenApp servers.
While XenDesktop is used to deliver hosted desktops, XenApp is used to deliver hosted applications. There are three methods of integrating XenApp and XenDesktop.
- No XenApp. All applications are installed within the XenDesktop image.
- All applications are delivered with XenApp with XenDesktop delivering a vanilla OS (“Vanilla” is a casual term that implies unmodified, no applications installed, no special drivers or features).
- A hybrid of the two. I find this to be the most common setup. When using a hybrid approach common applications to be accessed by all users, such as Microsoft Office, are installed within the desktop image. Applications to be used by a limited number of users are delivered via XenApp.
Many of the services in a typical XenDesktop environment rely upon a single IP or hostname for connectivity. For example, connecting to Web Interface involves pointing users to a single URL, though in a highly available environment two Web Interface servers should be available. Instead of pointing users directly to either Web Interface server they should be pointed to a Virtual IP residing on a load balancer. The load balancer monitors the state of the Web Interface servers and directs users accordingly. Citrix offers several products to fulfill this purpose, including the Access Gateway and NetScaler.
Citrix is about delivering desktops and applications from anywhere at any time. That means providing access to the virtual desktop environment to users not on the local network is vital. This can be accomplished using Citrix’s Secure Gateway or with the more robust Access Gateway. Whatever solution is selected should reside in a DMZ to better protect the private network.
A VLAN is important if utilizing Provisioning Services to stream vDisks. Interruptions in the stream can cause the streamed operating system to fail. For this reason the streaming network should be isolated by use of a VLAN or an isolated data switch.
Windows profile management is important in any environment, and even more so when using non-volatile virtual desktops. When a user logs in to a non-volatile desktop they have no cached profile, so profile bloat (a common problem) will lead to long logon teams. At a minimum, basic Windows Roaming Profiles should be implemented to allow for user personalization, such as Internet Explorer Favorites, My Documents, and Desktop icons. Redirected profiles can help alleviate profile bloat as portions of the profile can be moved to the user’s home directory. Also consider using a third party product, such as Citrix’s Profile Manager.
Shared storage, such as a SAN, is important for high availability. Virtual machines residing on a SAN can take advantage of live motion (e.g. XenServer’s XenMotion) to move between hypervisor hosts. Shared storage is also important when using Provisioning Services to allow the Target Device (i.e. the computer receiving the vDisk stream) to retain some persistent data, usually the Write Cache, log files, and EdgeSight data.
Posted in Citrix Virtuoso
Want to learn more on Citrix Automations and solutions???
Subscribe to get our latest content by email.