Before we run through a basic proof-of-concept install, let’s talk about some of the key differences between XD4 and XD5. There are some significant terminology changes from previous releases of XD (this is Citrix, so no surprise, right?!):
- What was known as Farms are now called Sites. Citrix would like you to think of a site as a deployment of XenDesktop in a single geographical location.
- A catalog is a collection of user desktops managed as a single entity. Catalogs specify virtual machines (VMs) or physical computers that host user desktops, the Active Directory computer accounts assigned to those VMs or computers, and, in some cases, the master VM that is copied to create the user desktops.
- Desktop groups and the virtual desktops they contain can be configured more flexibly. A single desktop group can contain desktops from a number of catalogs rather than being limited, as in earlier versions, to a single hypervisor pool. Also, a single desktop group can be published to users so that a single user may access multiple desktops in the group, and a single desktop may be assigned for use by multiple users. Desktops can also be assigned to client machines, rather than users, if required.
- A host is the infrastructure on which desktops are hosted, which comprises of hypervisors (resource pools or clusters), storage etc.
There are also some very substantial architectural differences in XD5. These include:
- No IMA data store. XenDesktop 5 no longer uses the IMA data store as the central database in which to store configuration information. Instead, a Microsoft SQL Server database is used as the data store for both configuration and session information. This means:
- Database requirements are different: Microsoft Access and Oracle are no longer supported databases.
- Terminal Services is no longer required on servers running the controller.
- There is no longer a dedicated zone master. In previous XenDesktop versions, there was a zone master/data collector responsible for user connection requests and communication with hypervisors. In XenDesktop 5, this function is distributed evenly across all controllers in the site.
- Due to reliance on Microsoft SQL Server, to ensure failover should the database become unavailable, you must use either SQL clustering or mirroring, or deploy the database as a virtual machine and use your hypervisor’s high availability features instead.
- Registry-based discovery. Desktops will now locate XD controllers through a registry-based mechanism. An Active Directory Organizational Unit is no longer required, although you can still use Active Directory-based registration. Active Directory is still needed in a XenDesktop deployment for authentication and authorization, therefore machines need to be domain-joined regardless of whether you use registry-based discovery or not.
- SDKs. XenDesktop 5 provides a new PowerShell SDK which allows you to perform the same tasks as you would with the Desktop Studio console. You can also perform tasks with the SDK that you cannot do with the console, such as assigning an IP address to a desktop, rather than a user name. Desktop Studio is built upon the PowerShell SDK; you can display the PowerShell in use in the console. Note that the new PowerShell SDK is not compatible with the SDK associated with previous XenDesktop releases.
No IMA? No AD OU required for registration of the DDC? No terminal services? Pretty crazy, right? Yes, it is but Citrix is definitely going in the right direction on simplifying the installation and configuration of XD. Certainly lots of things have changed. As humans we are creatures of habit, but these changes by Citrix are intended to make the lives of us consultants, architects, and Citrix administrators easier. With that said, it’s important to know that now the logged-on user’s rights are what you are using to authenticate to the XD5 database, to your back-end virtualization, and to AD. Because of this, make sure the user that you install XD5 as and the user that connects to your back-end virtualization has the appropriate privileges to access everything XD5 needs to touch.
Also, for the DDC, Windows Server 2008, Standard or Enterprise Edition, with Service Pack 2 installed (32- and 64-bit) Windows Server 2008 R2, Standard or Enterprise Edition (64-bit only) are the only supported OSs. Windows Server 2003 in any edition is no longer supported.
OK, with the semantics out of the way, let’s get started on a basic install of XD5.
First, let’s go to Citrix’s website (http://www.citrix.com), then to Downloads and get the appropriate software for XD5. In this version, we are using the Express edition.
Once you’ve downloaded the XD5 ISO, put it in a place where it will be accessible to your back-end virtualization. For our purposes, we are using vSphere as our virtualization solution.
For the master desktop, I used Windows 7 Professional 32-bit, although XP 32 and 64-bit are supported, as well as Vista 32 and 64-bit. Aero is not supported for Vista or 7. Install all updates and make any customizations to the desktop that you require. .NET 3.5 and Visual C++ will be automatically installed if not already when installing the Virtual Desktop Agent (VDA).
Spin up a Windows Server 2008 or 2008 R2 VM as our DDC (from what I’ve read, DDC seems to have been dropped by Citrix, with “controller” being the favored term now). Install all necessary Windows updates, assign it a static IP address, and join it to a domain. Although, most prerequisites can be installed with the XenDesktop install itself, it is advised that you manually add the .NET 3.5 feature before the XD5 install (if installing Web Interface on the same box). You could potentially have some funky things happen if you don’t. IIS, which is required by Web Interface, is installed with .NET 3.5.
We’ll handle the install of the VDA on our master desktop first. Open a console to your VM and connect to the XD5 ISO and let’s get started.
If the autorun doesn’t go, just go to Computer and start it manually.
Click Install Virtual Desktop Agent (VDA).
Click Quick Deploy. You would choose Advanced Install for a production environment.
You may get a notice similar to the one above. Click Yes to continue. XD5 will disable the WDDM driver for you.
Next, is the Summary Screen. Pretty self-explanatory. Click Install to begin.
Be patient as the VDA and its prereqs install.
Notice Restart machine (required to complete install) is checked. Make sure that it is, and then click close. Your VM will restart. After it comes back up, you can shut it down. It’s ready to go.
With our master desktop out of the way, let’s get going on our XD5 controller (DDC). Console to your 2008 or 2008R2 VM and connect it to the XD5 ISO. As before, if autorun doesn’t work, start the installation manually.
Click Install XenDesktop.
That brings us to Citrix’s Licensing Agreement. Please read over it and put a check in the box if you agree with the terms. Click Next.
This is where we select what components to install. You must select and install all components on the same server for quick deploy to function. Most of these components would be separated out on their own servers for a production install.
You may get the above message if you either have Windows Firewall turned off or if you have a third-party firewall installed. In this case, Windows Firewall has been turned off and there is no third-party firewall so we need not worry about this message. Click Next.
We get the Summary screen to see what exactly is being installed. Click Install to begin.
The install will begin. It will take a while for all the components to install, so please be patient.
After all components have been installed successfully, we can begin to configure our XD environment. Check the box to Configure XenDesktop after closing. (Note: If you have neglected to join your XD controller to a domain before the install, this box will not be able to be checked).
The Citrix Desktop Studio will open for you automatically. This is where we will begin to configure the environment. Click Quick deploy to begin.
Enter the name for your Site. Remember, Citrix would like for you to think of a Site as a geographical location but you can choose any name you’d like.
Select your hosting virtualization platform. Since we’re using vSphere, we’ll need provide the http or https address of our vCenter Server. Don’t forget to add the /sdk behind the address. Provide the necessary credentials to your vCenter Server. When done with all of that, click Next.
(Note: in our PoC environment, we are not using https access to our vCenter Server. To allow http access, you will have to modify the proxy.xml file on the vCenter Server. To do this, logon to your vCenter Server as an administrator. Go to this path: C:UsersAll UsersVMwareVMware VirtualCenter/ to find the proxy.xml file. Make a copy of the file in case you make a mistake. Edit it with Notepad or something similar. It can be difficult to read, so to get a clearer picture of the contents, you can open it in a web browser then make edits as you find the correct places with your text editor. You want to change two places: the / namespace and the /sdk namespace. We need to change them from >httpsWithRedirect< to >httpAndHttps<. I’ll highlight them in the screenshot below:
What we are changing is the access mode. To make it even easier to find, look at the red circles. The / namespace is listed after <e id= “0”>. The /sdk namespace is listed after <e id= “5”>. Also note, I’ve already changed these to read httpAndHttps.
This is similar to what you had to do in XD4 to allow http access but with XD5 you actually have to change this in both of these places. If you don’t, your VMs will delete themselves after provisioning.)
It may take more than a few seconds to contact your hosting, FYI.
When you get connected, we get to select the cluster and storage for the deployment. Click Browse to select your cluster.
Select your cluster and then click OK.
Now, select the storage you want your VMs to be able to be stored on. Lastly, select the network for your VMs. Click Next.
We now get to use the master desktop we create earlier. Select the master image and click Next.
Select the number of VMs you wish to create. Customize the number of vCPUs and RAM if needed. Browse to an Active Directory Organizational Unit in which to create the computer accounts (Hint: Go to your AD Users & Groups and do this ahead of time). Click OK and then Next.
Click Add and select the users and/or groups that will be able to access the VMs. Click Next.
Here we have the summary of everything we have just configured. Review your selections and click Back to make changes. If everything looks good, click Finish.
Sit back and relax because this will take a while depending upon the number of datastores you selected earlier (I’ll explain in just a bit). In the meantime, we’ll take a look at what vCenter is doing while we wait.
In just five minutes time, we have a lot going on for just 3 VMs we are creating. Let’s take a look at what’s going on with one of our datastores.
Here, we’re looking at the VM files for one of our virtual desktops XD5WIN7-01 (highlighted in yellow). Highlighted in blue, is our identity disk. Highlighted in green is our vswap. Highlighted in purple is our delta file. You’ll notice that our identity disk is just about 16MB. Our vswap is just about 1GB. Our delta file is about 144MB. This particular VM has been up and running for about 8 days. Take note that there are no apps added into the image, just Windows updates.
When complete, you’ll see the above. All in all, to create 3 virtual desktops, it took about 30 minutes. What actually is happening during this time is the copying of the replica (of your master VM) to the datastores that your site has access to. That is the explanation on why it takes so long. Once the initial cloning is complete, VMs spin up rapidly. I tested spinning up 100 desktops and they were ready to go in 5 minutes.
So, what next? Let’s configure admin access to our catalog.
Click on Administrators in the left hand pane.
Select the user or group to grant admin rights. Browse if necessary to select it. Next, select the appropriate level of privileges for the user or group. Don’t forget to enable the group before clicking Next.
Next, you get a summary page displaying what we just configured. If all looks good, click Finish. Now, let’s create a desktop group.
In the left hand pane of Citrix Desktop Studio, click Assignments. In the right-hand pane, click Create Desktop Group. Add the amount of machines you want to assign to the group based on how many you originally added to the catalog. You can always add more machines to the catalog and assign them to this group or subsequent groups you create. Click Next.
Select the users or groups that will have access to the VMs in the new desktop group. Assign the number of desktops per user. Click Next.
On the screen, the administrators you assigned to the catalog will be pre-filled for you here as administrators that can manage this desktop group. Click Next.
Here is your Summary page. Pick a display name for your users to see when they connect to a desktop. Choose a name for the desktop group. Click Finish. Now that we’ve gotten all the configuration out of the way, let’s connect to a desktop!
If you don’t know the name of your Web Interface site, check it by going to the left-hand pane of CDS, expand Access, and click XenApp Web Sites. You may also be wondering what is the difference between XenApp Web Sites and XenApp Web Services? Well, allow me to digress. Here’s the skinny: XenApp Web Sites will provide users a URL to a website where, once authenticated, users will have access to their online resources using a Citrix client. With XenApp Web Services, you can use the Citrix online plug-in in conjunction with the Web Interface to integrate resources with users’ desktops. Users access applications, virtual desktops, and online content by clicking icons on their desktop or the Start menu, or by clicking in the notification area of their computer desktop. OK, let’s get back on track. In the top middle pane, you’ll see the name for your internal site. So, fire up a browser and let’s connect.
You may be prompted to install the Citrix Web Client. Follow the on-screen instructions to do so. You may also have to install an ActiveX add-on if you’re using Internet Explorer.
Eventually, you’ll be able to authenticate. Log on with the appropriate credentials the click Log On.
Click on the appropriate desktop (the reason two are shown here is because another group was created before I created the screenshots for this blog).
Nice! We’re connecting to one of our virtual desktops.
You will get a dialogue box asking about HDX file access. Select the appropriate level of access you wish to grant. HDX allows certain multimedia tasks to be processed by the users’ Windows device to reduce server and network load.
That’s it! You have the XenDesktop welcome screen here, which you can select not to show again. You can also choose to stop it from ever showing up via a custom GPO, by registry key, or by simply removing the shortcut for it in the Startup folder for All Users.
OK, let’s recap. In this process, we have accomplished the following:
- Downloaded XD5 software from Citrix
- Spun up a Windows 7 VM, patched it, and customized it for use as our master image
o Patched it via Window Update
o Customized it via our specifications
o Installed the Citrix Virtual Desktop Agent (VDA) to enable its use as our master image
- Spun up a Windows 2008 R2 VM, patched it, installed .NET 3.5 (which installs IIS as part of it) for our XD controller (DDC)
o Patched it via Windows Update
o Installed .NET 3.5 feature, which installs IIS (required for Web Interface)
o Installed XenDesktop 5 and all roles needed for a PoC
o Configured our site, connected to vCenter, and began creating desktops
o Configured administrative access to our catalog
o Created a desktop group
o Connected via internal Web Interface to our virtual desktop
Next Steps…
Well, in lieu of creating a more production-ready type of XD environment, you could start with creating vSphere permissions for XenDesktop 5. There is an excellent blog out about this already from Jarian Gibson (http://jariangibson.com/2010/12/21/using-xendesktop-5-with-vmware/) where he talks about drilling down XD5 permissions with vCenter roles.
As you can see, there are still a lot of steps in the process but Citrix has clearly designed XD5 to be easier and quicker to get up and running than its predecessors.
One thought on “Installing a XenDesktop 5 PoC”