Integrating Citrix XenDesktop 5 with VMware vCenter

I am a big believer in combining best-of-breed technologies to achieve best possible solution. Citrix XenDesktop 5 is very powerful desktop virtualization software packed with features and functionality. However, XenDesktop requires a virtual infrastructure, and VMware's vSphere is without a doubt the very best of them. But what happens when you try to combine these two best-of-breed technologies? Well, the end result is great, but not without some heartache.

In order to integrate them, XenDesktop needs to communicate with VMware vCenter's SDK services. Simple enough right? Not quite, as the caveat comes into play as you try to access the SDK over HTTPS. By default, vCenter creates a self-signed SSL certificate for hostname "vmware." In most vCenter installations, the name of the server is not "vmware" and, as such, a secure HTTPS connection fails when connecting from XenDesktop 5 Controller. This is in addition to the fact that the certificate was signed by an untrusted certificate authority to begin with, as is the case with most self-signed SSL certificates. 

To resolve this issue, you can do one of three things. Option one would be to purchase an SSL certificate for your vCenter from a third party. Option two, you can self-sign a certificate from your enterprise certificate authority. Option three is trusting the existing SSL certificate. To do that, you can follow these steps:

1. If you are logged in as a local administrator, open Internet Explorer and navigate to https://vCenterServer/
2. If you are not logged in as local administrator, or a user with sufficient permissions, it is very important that you SHIFT > Right-Click Internet Explorer, and run it as an Administrator, then navigate to https://vCenterServer/
3. You will get a warning screen that the SSL Certificate is not trusted, select Continue to this web site (not recommended)
4. Click the Certificate error in the Security Status bar and select View Certificate
5. Click Install Certificate
6. When the Certificate Import Wizard launches, select Place All Certificates in the following store and click Browse
7. When the Select Certificate Store window comes up, make sure you select the check box for Show physical stores
8. Find and expand Trusted People, select Local Computer and click OK
9. It is important to note that if you don't see the Local Computer option under trusted People, you are not logged in with a user that has sufficient rights, therefore, you must run Internet Explorer as an Administrator.
10. Click Finish to complete the certificate import process
11. Click OK when you receive the import successful window
12. Close your browser, re-open it again, and browse to your vCenter server. The browser should now trust your vCenter server and therefore you should not receive a certificate error. That is how you can verify if the process was successful
13. Configure the hosting infrastructure settings on the XenDesktop 5 controller to point to https://vCenterServer.domain.com/sdk
14. Voila, it works like a charm and there are no errors when creating catalogs

The previous version of XenDesktop, version 4, had another workaround that involved modifying the proxy.xml file on the vCenter and setting the SDK communications to HTTP instead of HTTPS. Unfortunately, as of this writing, this method is no longer supported with XenDesktop 5.  That being said, I know that some of you are spirited technologists and will try anyway, so we tried it as well.

While I was able to get XenDesktop 5 Controller to successfully communicate with vCenter, I experienced some issues. The issues started when I tried to create a pooled virtual machine catalog. The process begins and successfully communicates with vCenter, creating certain tasks, but then fails with an error that reads: "The catalog has the following errors, failed to create the virtual machine." This error occurs if you did not configure the virtual infrastructure in XenDesktop 5 to communicate over HTTPS. Once I got over this wrinkle, the integration of these best-of-breed solutions worked, and continues to work like a charm.

By now, some of you might be wondering why I keep referring to XenDesktop and VMware vSphere as best-of-breed -- why run XenDesktop on VMware vSphere? The answer will appear in this space soon. 

Posted by Elias Khnaser on 01/11/2011 at 12:49 PM