Troubleshooting Citrix Xendesktop

Chapter 1. Getting Started – Understanding Citrix XenDesktop^® and its Architecture

Before we get involved in learning the tools and concepts required for troubleshooting the Citrix XenDesktop environment, it's always a good idea to start from the basics. So, let's take a look at the basic concepts of XenDesktop and its architecture. Citrix XenDesktop is an Enterprise-grade application and desktop virtualization solution that gives Citrix administrators the ability to centrally manage and host applications and virtual machines in a datacenter while delivering to endusers a complete desktop high-definition (HDX) experience.

Note

HDX technology provides users with a high-definition experience for virtual apps and desktops, on any device or network with enhancements to work with voice, video, and 3D-graphics applications.

In a traditional desktop environment, system administrators often tend to restrict certain users from having administrative privileges to install and uninstall personal sets of software on the office desktops. To centrally manage the environment and enterprise applications, many system administrators often choose a terminal server environment to provide a stable and lockdown desktop environment using Citrix XenApp.

Desktop virtualization provides many advantages that are similar to the terminal server environment with additional features and the flexibility to lock down images using the shared image concept and persistent desktops for users who like to have administrative rights on their desktops.

In this chapter, we will cover:

Desktop virtualization
Hosted Shared Desktop versus Hosted Virtual Desktop
The Citrix FlexCast delivery technology
The modular framework architecture
Machine creation services versus provisioning services
What's new in XenDesktop 7.x?

Hosted Shared Desktops (HSD) versus Hosted Virtual Desktops (HVD)

Instead of going through the XenDesktop architecture, we would like to explain the difference between the two desktop delivery platforms HSD and HVD. This is a common question that is asked by every system administrator whenever there is a discussion on the most suitable desktop delivery platform for the enterprises.

The selection of the desktop delivery platform depends on the requirements of the enterprise. Some choose Hosted Shared Desktops or server-based computing (XenApp) over Hosted Virtual Desktop (XenDesktop), where a single server desktop is shared between multiple users and the environment is locked using Active Directory GPOs.

XenApp is a cost-effective platform as compared to XenDesktop and many small to mid-sized enterprises prefer to choose XenApp due to its cost benefits and less complexity.

However, the preceding model does pose some risks to the environment as the same server is being shared by multiple users and a proper design plan is required to configure a proper HSD or XenApp published desktop environment.

Many enterprises have security and other user-level dependencies where they prefer to go with Hosted Virtual Desktop solutions. Hosted Virtual Desktop or XenDesktop runs on the Windows 7 or Windows 8 operating system as a virtual machine hosted on a datacenter. In this model, a single user connects to a single desktop and, therefore, there is a very low risk of the desktop configuration getting impacted for all users.

Note

XenDesktop 7.x and the preceding versions also enable you to deliver server-based desktops (HSD) along with HVD in one product suite. XenDesktop also provides HVD pooled desktops that work on a shared OS image concept that is similar to the HSD desktops with a difference of running a desktop operating system instead of a server operating system.

Let's take a look at the following table that will provide you with a fair idea of the requirements and recommendations of both the delivery platforms for your enterprise:

Customer Requirement	Delivery Platform
The user base needs to work on one or two applications and often need not do any updates or installations on their own.	Hosted Shared Desktop
The user base works on their own core set of applications for which they need to change system-level settings, installations, and so on.	Hosted Virtual Desktops (dedicated)
The user base works on MS Office and other content creation tools.	Hosted Shared Desktop
The user base needs to work on CPU and graphic-intensive applications that requires video rendering.	Hosted Virtual Desktop (Blade PCs)
The user base needs to have admin privileges to work on specific sets of applications.	Hosted Virtual Desktop (pooled)

You can always have a mixed set of desktop delivery platforms in your environment focused on the customer requirements.

XenDesktop^® and its architectural components

XenDesktop provides us with a desktop delivery platform by integrating several distributed components to deliver the best user experience for the VDI infrastructure.

The high level XenDesktop architecture includes the following key components:

Receiver: The Citrix Receiver is a replacement of the Citrix ICA client, which you will have been using from the MetaFrame times. This was transformed from Program Neighborhood Agent to the Citrix Online plugin to the now so called Citrix Receiver.
HDX technology: This provides the user with a high-definition experience for virtual apps and desktops on any devices and networks with enhancements to work with voice, video, and 3D graphic applications.
NetScaler Gateway: Citrix NetScaler Gateway provides a secure remote access to users accessing the Citrix published apps and desktops from anywhere and on any device by connecting to Citrix Receiver.
Database: Microsoft SQL Server is the only supported database.
License server: You must already have been aware of this component for a long time. To work with the Citrix range of products, you must have at least one Citrix License server in your environment, to provide you with the Citrix licenses.
Virtual Delivery Agent (VDA): The Virtual Desktop Agent needs to be installed on the virtual machines to which all the users will be connected. It enables the machines to register themselves with the controllers and manage the HDX connection between the machines and the user devices. There are two types of VDA agents available:
- VDA agent for the Windows Server OS
- VDA agent for the Windows Desktop OS
StoreFront: Citrix StoreFront is the replacement of the Citrix Web Interface product. It provides a similar functionality with some enhancements that provide access to published apps or desktops as per user needs.
XenDesktop Controller: Access to all the apps and desktops are centrally managed by the Controller server.
Citrix Director: The Director provides a real-time dashboard supplying diagnostic information for users, applications, and desktops. This is commonly used as the first level of troubleshooting.
EdgeSight: If you require historical trending data for analysis and performance, then EdgeSight is the tool for you provided by Citrix, free of cost, with the Platinum license. You can also look at the more capable tool provided by Citrix, until recently called Citrix Insight, which succeeded EdgeSight.
Citrix Studio: It's one of the management consoles that provide a simple GUI interface to create and manage desktops and apps.

Note

For detailed information on the XenDesktop architecture, please read Getting Started with XenDesktop 7.x, Craig Thomas Ellrod, Packt Publishing.

MCS versus PVS™

Anyone who has worked on XenDesktop will have definitely heard the terms: MCS and PVS. You have to choose either MCS or PVS to deploy VDI in an Enterprise environment. This is one of the major concerns for every organization, which they would like to be answered by a Citrix solution architect while working on a desktop virtualization project:

Which delivery technology is better, MCS or PVS?

Now, let's start by learning some basics about these two technologies.

Machine Creation Service (MCS) provides the simplest functionality for the creation and maintenance of desktop catalogs. A step-by-step walkthrough on how to create/configure this feature can be found in the XenDesktop 7.x install guide. You can easily download this guide from http://www.citrix.com.

MCS-based deployment will have the following characteristics:

A master image is prepared from a standard VM with all the customized apps and software that an admin wants in his virtual desktop.
A master image file (.vmdk or .vhd depending on the supported hypervisors Hyper-V, XenServer, or VMware ESXi) is stored in the central datastores attached to the hypervisor pool.
The admin provides custom settings for vCPU, memory, HDD, and many more.
VMs are created as linked clones with at least two disks attached to them; a base OS disk and a personality disk containing the machine-related information.
One difference disk will be attached to the VMs that are used to store and write the information to the VM. The disk used is as thin as provisioned (it needs to be checked for storage compatibility, if it is supported) and the disk size will grow along with your base disk to the maximum if required.
A personal vDisk can also be attached to each VM to store persistent changes for users.

There are four types of resource catalog that MCS offers:

Pooled-Random: This is most commonly used for standard users. Here, the desktops are assigned randomly. When the user logs off, the desktop becomes free and is available for another user. Any changes made to the desktops are undone on reboot.
Pooled-Static: These desktops are for task workers who need the same desktop every time they log on. These desktops are assigned to a single user and on user logoff this desktop is not free for other users. On rebooting, any changes made to these desktops are undone like Pooled-Random.
Dedicated or personal desktops: These desktops are meant to provide persistence to users and are recommended for task workers who need their own set of apps and control on their desktops. These are permanently assigned to a single user. When the user logs off, these desktops are not available in the pool for other users. All the changes made remain intact with subsequent reboots.
XenApp based Shared Desktops: You have been using these desktops since the old MetaFrame Presentation server model. These are the hosted server-based published desktops where the server desktop is made available to the users to be shared with a set of users simultaneously.
Tip
You can also club pooled desktops with a personal vDisk to provide persistency to user-level changes.

The following diagram outlines the basic architecture of MCS:

Provisioning Service (PVS) infrastructure is a result of Citrix acquiring Ardence, which is based out of Virginia, US. Ardence developed a boot program called the Ardence boot program that works on the PXE TFTP technology on which PVS streaming works. If you have worked on PVS previously, you must have heard of the major component ARDBP32.BIN being used for streaming in PVS, it still has the first three initials from Ardence.

PVS is a software streaming technology that Citrix uses to provide on-demand streaming of operating system content in real time from a single shared-disk residing anywhere on the network. Apart from the on-demand streaming, PVS simplifies image management as you don't have to manage images separately. Single-image management simplifies everything and you don't need to purchase any desktop deployment tools to manage this image.

Provisioning Services manages all writes to the vDisks with PVS write cache when using a vDisk in Standard mode (it is often called the read-only mode). You can configure the location of your write cache as follows:

Cache on provisioning server (with or without persistence)
Cache on target device RAM
Cache on target device RAM with overflow to HDD
Cache on target device hard drive (with or without persistence)

One of the most commonly used methods to store a write cache is to store it in the target device hard drive. There is a very good reason to follow this approach as it keeps the write location close to the target device, which actually minimizes the additional load on the PVS servers and also minimizes the load on the network.

Refer to the following diagram for the basic PVS architecture:

PVS architecture

Refer to the following diagram for the basic PVS communication flow:

PVS communication flow

A PVS-based device can have three types of disks attached to it:

The base OS shared disk is placed at the central PVS vDisk store and is streamed on each VM using PXE boot or BDM. You won't find this disk on the VM configuration on hypervisor, as this is streamed to VM either via PXE boot using either TFTP from a vDisk store or using BDM ISO.
Note
Boot device manager (BDM) is a utility that provides an optional method for providing IP and boot information to target devices. With this method, when the target device is booted, it fetches the boot information directly from the boot device. So, the target device would use this information to locate and boot from the required provisioning server.
The write cache disk, unless you have set the write cache on the PVS server or the device RAM.
A personal vDisk.

XenDesktop offers four types of resource catalog with PVS. The first three are the same as the first three resource catalogs that MCS offers, which we covered earlier in this section; that is, Pooled-Random, Pooled-Static, and XenApp-based Shared Desktops. The last one is Remote PC Access, which is a regular Windows desktop that is assigned to a single user which can be accessed locally or remotely.

Note

We can utilize a personal vDisk or persistent cache to permanently store the changes made by users. The changes remain permanent after reboot as well.