Minimum Requirements for XenDesktop
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)
I’ve heard lots of comments about how complex a XenDesktop deployment is – mostly from Citrix’s competitors. And, yes, it can get complex if you want to deliver the full suite of functionality, including provisioning from a common image, application streaming, applications executed on XenApp servers instead of (or in addition to) on the desktop OS, SmartAccess, etc. However, the complexity of a XenDesktop solution is in direct proportion to its functionality. You can deliver basic VDI with just the components outlined in my first bullet list above – and that isn’t a particularly complex deployment.
So my suggestion to anyone who is looking at cost and complexity is to make sure that they’re really doing an “apples-to-apples” comparison in terms of functionality.
your article is very interesting.
The complexity of the Citrix architecture is one of the most important reasons for my different choise: the Virtual Bridges proposition (vbridges.com).
It is: simple, rapid to implement(deploy), not expensive, and, overall, you haven’t any technologic lock-in by a specific provider, because it uses the KVM project.
Thanks for that. You’ve hit the nail on the head with your summary of what we want to achieve. We’ll start investigating the Smart Access option a little more.
Thanks for you help
Thanks for your comment. Perhaps I should have been more clear, but in XenDesktop, desktop assignments are based on the user ID, not the client ID. Somewhere along the way, we’re going to need to capture the user’s login credentials. At that point, if you have given that user the ability to choose between multiple desktops, we’re going to take the user to an interface where s/he can choose the desired desktop. If, on the other hand, you have restricted the user to only one desktop, the user should be immediately connected to that desktop as soon as the user’s credentials are validated.
What I think you’re asking for is the ability to grant a given user the rights to several different desktops, but then to dynamically restrict those rights (perhaps to a single desktop) depending on the client device.
If that’s correct, then I believe you could accomplish that with the Citrix “SmartAccess” (a.k.a. “Advanced Access Control”) functionality, which is implemented using one of the Access Gateway Enterprise Appliances together with the appropriate client licenses (which are included with XenDesktop Platinum Edition, or which can be purchased separately). The whole point of SmartAccess is to build policies that will dynamically change what a user can and cannot do based on the access scenario, and the policy can incorporate such factors as the client device name and/or IP address range.
SmartAccess can also grant or restrict access to specific applications, shared files & folders, internal URLs, etc.
EDIT, 3-15-10: Note that the new Access Gateway VPX (Virtual Appliance) fully supports SmartAccess, which can considerably lower the cost of this solution. For more on this, see “Citrix Continues to Virtualize Appliances.”
Great article but a little late for us as we are in the late stages of go live. You mention that 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. Do you have details on how to achieve this? We have looked into this and it looks easy to do on VMWare but we can’t see a way to do it on XenDesktop.
What we are after is to present users with a number of desktops but ensure that a client device always connects to a specific virtual desktop.
I spoke to someone at Citrix and the only way they thought it could be achieved was by using Access gateway.
Any ideas would be a great help.