We were recently asked, by someone who was planning a XenDesktop 4 Proof of Concept, what minimum components were required to conduct the POC. Rather than prepare a document just for them, it seemed like a good idea to put the information here so others can read and contribute.
In its most basic configuration, XenDesktop is, functionally, going to look like this (click on picture to view full-size):
I lifted this drawing from a three-year-old Citrix PowerPoint presentation, and while XenDesktop has evolved considerably since then, the functional building blocks are still much the same:
- You’re going to have a Desktop Delivery Controller (“DDC”). This is the Windows server that brokers the connection between the client device and the virtual OS. As you move into production and scale up the environment, you will probably have multiple DDCs.
- You’re going to have a Citrix License Server. In a small deployment, like a POC, this service can also reside on the DDC.
- You’re going to need a place for Citrix to store configuration data. In a production deployment, you’ll probably want the Data Store on a SQL Server. For the POC, it can also reside on the DDC.
- You’re going to need a “Web Interface” server. One way or another, the client devices are going to communicate with the WI server, which will consume the user’s authentication credentials and (in most cases) present the user with the desktop choices that are available to him/her. I say “in most cases,” because it is possible to configure a client such that it will immediately connect to a designated virtual desktop without requiring the user to click on an icon.
Once again, in a small deployment like a POC, the Web Interface services can run on the same Windows Server as the DDC, the Licensing Services, and the Data Store. So far, we haven’t moved beyond just a single Windows server – although, of course, as the environment expands and moves into production, these Web services should also be migrated to their own server.
- All of this needs to live in a Windows Active Directory Domain, so if you’re building a POC that is isolated from your production environment, you’re going to need to provide a Domain Controller. That poor little DDC system already has enough running on it, so let’s make the Domain Controller a separate server.
- You’re going to need some kind of virtualization infrastructure. XenDesktop is platform-agnostic at this level – it will run on XenServer, Hyper-V, or VMware. All of the other servers/services we’ve been talking about so far can be virtual servers running on this infrastructure. In a small POC, that’s the obvious way to go anyway.
Now things start to get a little tricky. That gray box that surrounds the repositories labeled “Profiles,” “Apps,” and “OS” can be broken down in a couple of ways.
Let’s assume that we are going to stream an OS, from a single, shared, read-only image, to virtual PCs that will be instantiated (I love that word – it just rolls off the tongue, and it sounds so technical) on-demand on whatever virtualization platform we’ve chosen. That means we need a Provisioning Server, and a place to store those read-only images. For a POC, the images can be stored on the Provisioning Server itself. When we move into production, since we don’t want the Provisioning Server to be a single point of failure in our VDI infrastructure, we’re going to want more than one Provisioning Server, which means that the OS images are going to need to reside on shared storage of some kind that can be accessed by all of our Provisioning Servers.
Elisabeth Teixeira of Citrix has a great 4-part series on High Availability for Provisioning Services over on the Citrix Community Blog site. Rather than go into detail here, I’d strongly recommend reading through her posts.
For our POC, the Provisioning Server can be virtualized. When we move into production, it’s probably best, for a variety of reasons that we won’t go into here, that they be physical servers.
Our virtual PCs are going to need apps as well. (After all, the entire purpose of a PC is to run apps, right?) If you wish, you can “bake” the applications into the read-only “golden” image that we’re going to use for provisioning, by first installing them on the PC that we’re going to use to create the image. Of course, that means that whenever you make a change to an app, you have to change the whole image, and we know what a pain that is, because many of us have been managing images for physical PCs that way for years. So we’re going to be better off if we stream the applications on-demand onto the virtual PCs after they’re booted up and users have attached to them. We will therefore need at least one XenApp server to manage the application streaming.
Finally, we’re going to need a file server to serve as a repository for user profiles and user data. The streamed OS images are, after all, read-only, so we’re going to need to use AD Group Policies to specify where that data is stored, since it can’t be stored in a profile that’s part of the streamed image.
One more thing comes into play, depending on what Windows OS you’re going to use for your virtual PCs. As we’ve noted in other posts, the process of converting a Vista or Windows 7 PC into a shared golden image will break the license key. You must therefore have a KMS Server available to auto-activate the PCs as they boot up. For best results, the KMS service should be running on a Windows 2008 R2 server. For more information on KMS and how it works, please see our earlier blog post on KMS.
That’s really all you need to do a POC, provided that all your clients will be connecting from within the protected network. If you want to grant access to clients connecting in from the public Internet, you’re going to need a secure way to do that. The simplest way is to use the software Citrix Secure Gateway that comes with XenApp. The CSG is basically an application-specific software SSL/VPN – running on a Windows Web server – that provides a secure proxy between the public Internet and the Web Interface server. For more demanding environments, you should consider the line of Citrix Access Gateway appliances, which can function as general-purpose SSL/VPN appliances as well as providing access to the XenDesktop infrastructure, and can provide advanced features like redundancy, automatic failover and, with the NetScaler software load, even provide Global Network Load Balancing for automatic failover between a primary site and a DR site.
If you have clients in branch offices connecting to your XenDesktop infrastructure across a Wide Area Network, you may see some benefits from deploying the Citrix Branch Repeater line of WAN optimization appliances. It’s likely that as we move through the year and see the release of new technology like XenClient, we will see an expanded role for the Branch Repeater with Windows Server and its ability to cache data locally at the branch office level – but that’s another post for another day.
So there you have it. To summarize, our minimum POC environment will consist of the following servers/services running on our virtualization infrastructure:
- Domain Controller
- A Windows Server hosting the following services (which can be broken out onto separate servers as the environment scales):
- Desktop Delivery Controller
- License Server
- Data Store
- Web Interface
- Provisioning Server
- XenApp Server (for application streaming)
- File Server (optional – in a pinch you could make file shares available on one of the other servers)
- KMS Server (if you want to provision Vista or Win7 PCs)
- Secure Gateway Server or Access Gateway Appliance (if you want to provide secure access from the public Internet…note that this server or appliance should be in a DMZ for best security)