This post, like all five Geek Week: VDI wrap-up posts, was co-written by Brian & Gabe.
We'd already done three other vendors by the time Frank Anderson of Citrix rolled in (ten minutes before we did, actually) on Thursday morning, but we were pretty excited (and anxious) to meet Frank and get started. It seems like all you hear from the Citrix haters is how complex XenDesktop is, and we hoped to either (a) get a glimpse of this with a Citrix person at the wheel, or (b) disprove the haters.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
You'll find out (as we did) that most of XenDesktop is fairly uncomplicated—it's Provisioning Server that adds the complexity to the setup process. To be fair, though, once it's installed, it works just like you'd expect...really well.
We (Gabe & Brian) had done a vanilla "next, next, next"-style install of XenServer the night before, and we had our infrastructure (AD, DNS, etc.) running on another server before Frank walked in the door. Frank brought three VMs with him that—like every vendor this week—had base installs of Windows Server that were fully patched with all the out-of-the-box Windows update components.
Then together we built three VMs: The XenDesktop 4 Desktop Delivery Controller, the Citrix Provisioning Server, and a Windows 7 x64 virtual desktop.
XenDesktop basic installation and configuration
First up for install is the Desktop Delivery Controller, or DDC, which went pretty quickly. It's a next-next-next install for the most part (even for all those little subordinate bits that previously had to be installed manually). The only real thing we had to do was swap the install source ISO once so that the DDC setup process could pull the Remote Desktop bits from the Windows 2003 ISO.
You might be curious as to why Remote Desktop (actually, Terminal Services, since this is still on Windows 2003) is required on the DDC for XenDesktop. The answer is that XenDesktop uses some components that were originally built for XenApp (and therefore Terminal Services), so instead of reinventing the wheel, Citrix just leverages the Terminal Services role to provide those bits.
While those bits were installing, Frank also created a separate OU in Active Directory to handle all the XenDesktop objects. This isn't just a requirement for XenDesktop—it's actually a best practice for any desktop virtualization solution: VDI or TS. Creating a separate OU allows you to manage, secure, and lock down your environment differently than you would the rest of your users and machines, and granular control is always a good thing.
After the DDC was configured (which automatically included the configuration of Web Interface), we were ready to start brokering desktops... we just needed a desktop to broker. For that, Frank fired up the Windows 7 base VM and did a quick next-next-next install of the Virtual Desktop Agent, or VDA. The VDA software that runs in every desktop VM that (a) communicates with the DDC, and (b) provides HDX connectivity from remote clients. We also installed our "base apps" into the VM, including Acrobat Reader, Flash, IE8, and Office 2007.
At this point we only need to create the desktop group (analogous to "publishing" the desktop) in the DDC before we can connect. It's during this desktop group setup process that you're able to choose what type of desktop you're using (pooled or assigned), idle pool settings (where you configure devices to be spun up and waiting for users to log on based on a schedule), log off behavior (restart the VM or just disconnect the user), and default connection settings.
So at this point we've sailed through the installation and configuration and are able to broker connections to the desktop VMs we've built via the Web Interface. But everything we've done so far only delivers the manually-created desktops to users. To get to the next level, where many users can share a base desktop image, we need to bring in Provisioning Server, and that's where we earn our living :)
Citrix Provisioning Services setup and configuration for XenDesktop
The fact that the edited-down Provisioning Services via is still twice as long as the base XenDesktop installation and configuration video is indicative of the effort required. Citrix Provisioning Server, as you know, is descended from the product Citrix got when they acquired Ardence. And unfortunately Ardence was designed long before the concept of VDI was invented.
Installing the Provisioning Services and its prerequisites was simple enough—really just more next-next-next style installs with a quick database setup. (And in our case it was just a next-next-next install of SQL Express as well.)
Once Provisioning Services was installed, had to set up the farm (the Provisioning Services "farm" is different from the XenDesktop "farm") and configure some basic options (licensing, admin access, etc.). Next is to configure a way for Provisioning Services to be able to deliver disk images to our VM clients. Since this is a pre-VM era product, this is done via DHCP. In this case we configure Provisioning Services to act as a TFTP server for bootstrap delivery, and we go over to our DHCP admin console to configure a couple of PXE boot option flags to point them to our Provisioning Server.
Next we run something called the "XenDesktop Setup Wizard" whose purpose it a bit confusing. "What?" we thought.. "Didn't we already setup XenDesktop?" It turns out this XenDesktop Setup Wizard is for Provisioning Services; specifically, it configures Provisioning Services to work with XenDesktop. (Its exact purpose will become more clear in a bit.)
After all that, we're now ready to select a shard master desktop VM disk image that we'll stream to all our users. This is done by first creating a "vDisk" which is a Provisioning Services term for the container that will hold our VHD and its related configuration information for streaming. We do this via the Provisioning Services Console.
The rest of the steps we do kind of hurt my head. The exact process is detailed line-by-line in the walktrough in Citrix eDocs, but it involved converting our disk image, swapping boot orders, typing in MAC addresses, creating collections, and all sorts of other little things.
Really the term "kludge" comes to mind with Provisioning Services. It's just so clear this thing was never designed for virtual desktop environments. (And ironically, Citrix recommends for sizing reasons that your Provisioning Server be installed on a physical box!) In Citrix's defense, I think once everything is initially set up, the day-to-day management won't be too hard. But ugg! Setting everything up is not for the faint of heart! (Watch the video for the full effect.)
Updating the master disk image
Once we got the base image installed and provisioned for a few users, we wanted to learn how the update process works. At this point Frank told us that there's a few different ways this could go, and he suggested that we to the update in a different way than when we made the initial image. (His suggestion was not because the "other" way was the suggested way, but just so that we could see something new this time around. Sweet!
Fortunately since we already had Provisioning Services installed, the update was pretty easy. The two methods of update are:
- Mount our Provisioning Services vDisk as "writeable," log in, make our changes, and "bam!".. we're done, or
- Open our original master VM's VHD, make our changes, and re-XenConvert to create a new Provisioning Services vDisk.
In the real world we'd choose Option 2 for a few reasons. First, editing a PVS vDisk can only be done when it's unlocked. And the only way it can be unlocked is for all the users using it to logoff. Second, when a vDisk is updated, that's it! It's instantly in use by everyone, which might not be what you want.
The preferred method is the first method, where we go back to the original VM template and modify the original VHD file. Then when we're done, we create a brand-new vDisk. This process can be done during production hours while users are using the first vDisk. Then it's a simple matter to flip some users to a new desktop group that uses the new vDisk. If that vDisk works fine, great! We can flip all the users over. But if that vDisk has some kind of problem, we can go back to the first one since it's still in PVS and hadn't been touched.
That said, we chose the other option in our video just so we could see what it was like. And since we had a small test lab, it was really easy to shut down all the desktop VMs and to update the master vDisk.
The user experience
We had high expectations for ICA/HDX heading into the day, and we weren't disappointed. Rather than try to describe the user experience, the best thing to do is just show you. The video below is a realtime recording of the experience we have in each of our three WAN scenarios as well as over the LAN. Something to note before watching is that we decided to turn off Flash Redirection for each vendor that offers it. There are a couple of reasons for this. First is that we know that redirecting Flash will make Flash look perfect. Second, and probably most important, is that Flash is only a portion of the video or animated content that a user would view. Turning off Flash Redirection allows us to simulate watching any video, Windows Media, Silverlight, Quicktime, etc...
Overall, HDX (which is what Citrix is calling ICA now) performed really well, even with Flash redirection turned off. The WAN experience was the best we saw all week, even though it left a little to be desired when watching video (again, with the acknowledgment that the YouTube video would've looked great with Flash Redirection turned on). Overall, though, HDX performed admirably.
The Bottom Line
The biggest takeaway from our day with Citrix is that while the initial setup is complex (and more than it needs to be), ongoing use is at least as painless as the other vendors that we saw. Detractors of XenDesktop for its complexity should look beyond simply that when making a decision, because in the long run there are bigger things that can make or break a VDI project, such as whether or not the remote protocol does what you need, disk usage for the VMs, printing capabilities, and so on. All in all, Citrix's product is just what we expected to see from a top-tier VDI vendor, from the installation and configuration down to the user experience. The only major knock that we have is the Provisioning Server complexity, and it's safe to say that Citrix is aware of it and is working to make it easier to get up and running.
I've been working with Citrix since 1998, so this was definitely the product I was the most familiar with. I'm writing this text on Sunday evening from 36,000 feet somewhere above the farmland between Ohio and San Francisco. I 'm flying home from visiting my dad who lives in the same house I grew up in. Part of going home felt calming, but part just wasn't right. My parents are divorced. Some teenage girl lives in my bedroom. The house smells like cigarettes and booze.. It's familiar, but definitely not comfortable.
And this is how I feel about XenDesktop. We have a product that is very capable. We have a protocol that's very mature. But I just can't help but feel like this thing is a mash-up of a bunch of different things—some of which were definitely not designed for this kind of use. Ironically this is a great analog for desktop virtualization in general: The components are there, but it just feels a bit mashed up.
They say no one ever got fired for buying IBM. In the case of desktop virtualization, no one will get fired for buying Citrix. They've got fine products that are getting better every quarter, but I'm also excited to see what what else we learn about over the next four days.
Tomorrow's vendor for Geek Week: VDI is VMware, so come back for our analysis, wrap-up, and lots of videos.