In the first post of this three-part blog series I went over installing XenServer and preparing the base virtual machine images for a XenDesktop deployment.  The first post may be read at /blogs/2012/01/13/10-to-xen-part-1-of-3/. Now with the following virtual machines available I’m ready to proceed with the XenDesktop install.

XD – Windows Server 2008 R2 XenDesktop Controller and components (4GB RAM + 4 vCPUs)

Win7Base – Windows 7 base image for use with Machine Creation Services (2GB RAM + 2 vCPUs)

Client – Windows 7 Endpoint Client for connecting to the environment (2GB RAM + 2 vCPUs)

All virtual machines are bridged to the local network segment which contains an infrastructure server providing AD, DNS, and DHCP services.  Alternatively, you may choose to create an internal host-only network and use a router to manage the traffic (I personally like Vyatta).

To start things rolling with XenDesktop 5.5 as quickly as possible, I’ll install all components on the XD system and run through the initial setup with Quick Deploy.  This is perfect for a PoC or smaller environment, but not designed for most production environments because there is no redundancy for the database or the Controller.  Should the single XD system fail, users will not be able to connect and administrators won’t be able to manage the environment (VDA High Availability Mode as described at is possible though it is only designed for temporary emergency situations).  Production deployments should always have a minimum of two Controllers on separate physical hosts and database HA through either mirroring or clustering on separate hosts or hypervisor HA with a pool.  Even though I will install all components on one system, it’s possible to separate them out later without starting over again. goes over the process of reconfiguring an existing site to use a mirrored database.

I installed the Virtual Desktop Agent (VDA) software directly onto the Win7Base virtual machine and rebooted.  I’ll be using Machine Creation Services, and like with Provisioning Services, this means that I only need to install the VDA software once on the golden image.  If you are not using MCS or PVS for one or more desktop groups, check out which explains how to push out the VDA via Active Directory.

So with the VDA installed and rebooted (which took under 10 minutes :)), it’s now time to install XenDesktop itself.  On the XD machine I proceeded through the XenDesktop 5.5 metainstaller and installed all the components (also less than 10 minutes).  I then proceeded to perform the initial configuration of the XenDesktop Site within Desktop Studio.  I chose my Win7Base VM, specified the creation of 3 machines and 2GB RAM each, assigned users, etc.  The wizard took a few minutes (I’ll admit it was more than 10) and when it completed successfully I switched to my Client machine and logged into the Web Interface at http://xd.  I clicked on the icon and my desktop started to load.

I realize that desktops don’t always launch the first time around, so if that’s the case for you check that the machines are not in maintenance mode within Desktop Studio, that the time is synchronized amongst the machines and domain controllers, and that there are no port/firewall issues for communication between the VDAs and Controllers.  Registration is the process by which VDAs inform the Controllers of their available status so that the Controllers can broker them to users. goes over the process of troubleshooting registration.

Before I sign off in this post, I’d also like to take the opportunity to mention the Desktop Transformation Accelerator Program (formerly known as Success Accelerator for XenDesktop 5) which is available at  This tool is an invaluable resource for doing XenDesktop deployments as it presents you with personalized step-by-step guidance, peer benchmarks, standard templates, and much more.  Regardless of where you are along the road to desktop transformation, I urge you to visit the site and create a project today!

Well that’s about it for now.  We have created a working XenDesktop environment and are on our way to a virtualized work style.  There is still some additional configuration and personalization aspects to complete though such as creating policies, adding additional machine catalogs and desktop groups, setting up external access, and so forth to meet the business requirements.  In the next (and last) post for this series I’ll go over adding virtual apps into the mix with XenApp.