vCloud Automation Cetner 5.2 – vCAC 5.2 and Citrix XenDesktop Demystified

Caution: Articles written for technical not grammatical accuracy, If poor grammar offends you proceed with caution ;-)

I have seen a rise in questions regarding vCAC 5.x and integration with XenDesktop. This article is not a step by step on how to configure integration with XenDesktop, but information on capabilities and use cases for integration.

Supported XenDesktop Versions:

• XenDesktop 4.0 (Only VMware Hypervisor and vCAC VDI agent must be installed on a 32-bit host.)
• XenDesktop 5.0 (SP1 (Supported on VMware and XenServer)
• XenDesktop 5.5 (Supported on VMware and XenServer)

To integrate with XenDesktop vCAC uses a VDI agent. The VDI agent communicates with the XenDesktop powershell API to interact with XenDesktop. The XenDesktop API in version 4.0 only works with 32-bit hosts and so vCAC requires a 32-bit host to run the XenDesktop API and the vCAC VDI Agent on. If you have all 64-bit then you will need to deploy a 32-bit host for integration. Version 5.0 SP1 and 5.5 do not have this limitation.

Things to be aware of

• The vCenter endpoint hostname that is configured in XenDesktop must match the vCenter endpoint hostnameconfigured in vCAC.
• If you have multiple XenDesktop Servers located in different datacenters that are connected to different vCenter servers you will need to have all the vCenter servers setup in vCAC as endpoints.
• Groups who have access to desktop blueprints for Virtual Desktops that will be registered to a XenDesktop broker, need to have a reservation against the appropriate compute resource that corresponds to the environment in which they will be created.

If we look at a single datacenter with one vSphere cluster and a XenDesktop Broker. A group within vCAC will have a reservation against the cluster that is configured within XenDesk to host the virtual desktop instance. If we now look at two datacetners each with a seperate XenDesktop instance. A group that needs to register a virtual desktop against both XenDesktop servers will need a reservation against both vSphere Clusters.

Key benefits to using vCAC with XenDesktop

• vCAC allows you to put leases on deployed desktops. If you need assign someone a desktop for 30 days, at the end of the 30days it will be destroyed and not left hanging around.
• vCAC allows you to invoke approvals for desktop requests as well as limit the total number of desktops a user can have.
• vCAC can help you put policy’s around who can have what type of desktop including the resources assigned to the desktop.
• vCAC automates the deployment of the desktop, thick or thin into the appropriate virtual environment based on the desktop that is requested and the group of the user that requested it. This includes the network the desktop is to be placed on.
• vCAC automates the registration of the desktop as well as assigning the user to the desktop in the XenDesktop Broker.

The true benefit of using vCAC with XenDesktop is vCAC’s ability to fully automate the management of the virtual desktops in the environment. vCAC can leverage policy to first determine which Desktop images a user should be able to select and then again using policy determine where it can be placed for that particular user. Through the use of blueprints you can configure lease policies, number of allowed desktops, approval policies, resource thresholds, as well as give users the ability to perform management tasks on their desktops if you choose. Management tasks would include power on, power off, reboot, and others.

vCAC allows you to present only the appropriate desktop for specific groups. An example would be providing the development blueprints that were built specifically for development and finance with desktops specific to finance. To take it a step further you may only want finance desktops to be provisioned into a special sox compliant environment and only want dev desktops placed in a development environment that has all the other development resources the developers need.

These are some of the basic out of the box use cases. With a little customization you can do some pretty cool stuff like provision a desktop on the fly when an employee from out of town badges into the office. Or use the HR system to look up where a remote worker resides, then compare that to the available datacenters and determine the best location to place their VM. If you have a large scale XenDesktop deployment you are surely familiar with the challenges of scale in determining what a user needs and where there desktop should be placed.