Asking Citrix about the XenDesktop VDA is like a "Who's on first" Abbot & Costello routine

Practically everyone knows about the classic skit from Abbott and Costello titled "Who's on First?" The skit is a hilarious exchange between the two men where Costello is merely trying to understand who the correct player is in each field position.

Practically everyone knows about the classic skit from Abbott and Costello titled "Who's on First?" The skit is a hilarious exchange between the two men where Costello is merely trying to understand who the correct player is in each field position. It’s made funny because all of the players’ names are words like "Who", "What" and "I don't know," so during the course of the conversation each question is answered with a name that leaves the person asking the question feeling as though they didn't get the answer. Some recent situations with the Citrix Virtual Desktop Agent (VDA) from XenDesktop makes me feel a bit like Abbott.

What is the VDA?

Citrix XenDesktop is comprised of multiple architectural components. While many XenDesktop architectures will involve hypervisors, SANs, PVS servers, and various other infrastructure components, it's also possible to build XenDesktop without using virtualization technology at all. That flexibility in the architecture makes it both incredibly flexible and powerful but can be quite confusing at times. Here’s an example of the simplest XenDesktop architecture you can create (not considering VDI-in-a-Box of course):

Notice that the above diagram doesn’t specify any hypervisors since all of these machines could be physical servers if we wanted. Also, I haven't included Secure Access/Netscaler, PVS, MCS, Profile Management, PVD, Edgesight, Password Manager or any of the other pieces that *may* exist in a full blown XenDesktop Platinum implementation. So this is as simple as it gets. A client PC with Citrix Receiver installed connects to Web Interface Storefront where the user provides their credentials. The WI/Storefront server talks to the Desktop Delivery Controller (DDC) to authenticate the user (assuming WI/Storefront isn't authenticating them) and then the DDC server performs calls to the SQL Datastore to retrieve information on what Desktop Groups the user is entitled to use. The DDC then passes the information back to WI/Storefront where a set of icons is displayed to the user. Once the user clicks on a desktop to launch, WI/Storefront passes that back to the DDC which instructs the physical PC or VM to begin listening for the HDX/ICA on (TCP/1494) or, if you’re using Session Reliability, via CGP (TCP/2598). One of the key pieces of infrastructure that makes all of this work is the "Virtual Desktop Agent" or VDA. The VDA is a set of drivers and services that are loaded onto each host machine you want to connect to. The VDA registers itself with the DDC to make it available to users based upon which Desktop Groups/Catalogs have been defined in the SQL Datastore.  The VDA is what allows XenDesktop to connect to desktop operating systems, period. Without the VDA, none of this works. For a complete history of the VDA, see these articles on PortICA.

XPDMs on First, WDDMs on Second...

The issue with XenDesktop (or any other VDI technology for that matter) is that we're in a particularly bad transition time when it comes to Operating Systems. Many people are well on their way to move to Windows 7. Windows XP leverages a Windows Driver Model (WDM) called XPDM. When Microsoft released Windows Vista (and later Windows 7) they introduced a new display driver model called WDDM (Windows Display Driver Model). WDDM is required to drive the 3D Aero display model within Vista and Windows 7. (Look here for more details about how XPDM and WDDM differ.) The bottom line is if you want Windows Aero, you need WDDM drivers.

As you can begin to understand, if you had a product that straddled support for both Windows XP and Windows 7, it would need to be capable of supporting both XPDM display drivers as well as WDDM display drivers. In Citrix’s case, XenDesktop did not fully support WDDM drivers (and Windows 7) until XenDesktop 5.6 Feature Pack 1. XenDesktop 5.5 supported Aero redirection from VMs to physical PCs with GPUs, but that's not the same as supporting WDDM drivers when installing on a physical PC with an existing WDDM driver. So if you're building a XenDesktop 5.6 FP1 environment with its associated VDA, it can now be deployed with either XPDM drivers or WDDM drivers—The XPDM driver for the Windows XP VMs and the WDDM driver for the Windows 7 VMs where you want Aero.

The on ramp to VDI?

When Citrix released XenDesktop 5.6 Feature Pack 1, they introduced a feature called RemotePC. RemotePC essentially allows you to install the VDA onto physical endpoints for the purpose of brokering XenDesktop sessions to physical PCs. Keep in mind that the RemotePC features isn't really doing anything that couldn't be done before. The VDA has been able to be installed on physical PCs since XenDesktop 3.0—the first "real" XenDesktop release. Citrix never marketed XenDesktop towards physical PC use cases because (like many other vendors) they had the VDI horse blinders on. However once the industry recognized the analysts were wrong and VDI wasn't going to take over the world, Citrix and many other vendors started warming up to the fact that Physical PCs aren't disappearing tomorrow. So the RemotePC idea was born.

Now while I don't necessarily agree with Citrix marketing RemotePC as an “on ramp” to VDI, it’s perfect for many key use cases like telecommuting, working from home, DR scenarios, etc. For companies who have fully invested in the Citrix stack, RemotePC is a no brainer. (By “Remote PC,” I'm not even necessarily referring to the automatic registration bit that the RemotePC feature actually enables, I'm just talking about slapping the VDA on physical machines and making them accessible via XenDesktop. And by the way, I'd still love to see some HDX Connect under the Christmas tree for 2013 ;)

The issue with bringing a whole bunch of physical PCs into the environment is those physical PCs have Windows 7 (if you're doing your migration right). And of course those physical PCs also have GPUs in them since even those low-end crappy integrated graphics chips can do Aero). Plus toady’s users have adapted to Aero and now expect to see it even though there isn’t any practical use to Aero whatsoever. So now we get to the crux of this article (thanks for sticking with me!).

Who's VDA is on first?

When rolling out a VDA, you take the MSI and push it out with your ESD/PCLM tools. The question then becomes, “Which VDA do I rollout?” Here's the kicker in the VDA decision process: According to CTX134196, the supported method of installing the VDA is to deploy the XenDesktop 5.5 or 5.6 VDA and then upgrade it to the XenDesktop 5.6 FP1 (version 5.6.100) or the latest 5.6.200 VDA. The article states that this is the proper method because the 5.6.100 and 5.6.200 packages are update packages intended to be applied on top of the existing VDAs—they are not stand alone VDA installers.

Here's where the complexity kicks in. If you're deploying Windows XP, this isn't a problem because you'll just roll the XD 5.5/5.6 VDA followed by the 5.6.100/200 VDA and you're good. Remember this is okay because XP uses XPDM and XenDesktop 5.5/5.6 supported XPDM. No problem. But if you're using physical Windows 7 PCs with Aero enabled, when you install a 5.5/5.6 VDA you'll notice that upon reboot the Windows 7 machine is now in Windows 7 basic mode. That's because the 5.5/5.6 VDAs didn't support WDDM drivers. So if the "correct" and "supported" mechanism is to use 5.5/5.6 and then patch 5.6.100/5.6.200, you now have a dilemma. Do you want Aero or not? If you have Windows 7 with physical PCs, the recommendation is to use the 5.6.100/5.6.200 VDA and use the RemotePC feature. First of all, you don't really need to use the RemotePC feature if you only have a small number of machines to support. Just build a physical PC desktop group, import the machines to the DDC, deploy the 5.6.100/5.6.200 VDA, and away you go. But whether you use the RemotePC feature or not is irrelevant.

What the really confusing part about this is, what happens for customers with mixed environments? What if a customer has some Windows XP or Windows 7 VMs and some Windows 7 physical PCs that they want to retain Aero on?  Should a customer really be forced to certify and deploy two separate VDA implementations?  One method for VDI and one method for physical PCs? That's crazy! By the way, CTX134196 was only updated to reflect the appropriate "supported" paths about two weeks ago and that was because I had a customer burn a support ticket to get Citrix to indicate the proper supported path of deploying in these two scenarios. Prior to this KB being updated, the only reference Citrix had anywhere was this which indicates, "Upgrade to XenDesktop 5.6 Feature Pack 1 Virtual Desktop Agent only from XenDesktop 5.5 or 5.6 Virtual Desktop Agent. Those are the only supported upgrade paths."

How Citrix could have made this better?

There are several things that Citrix could have done to avoid the whole situation that we're currently in.

1) Citrix could have taken the appropriate installer engine code from the 5.5/5.6 VDA and baked it into the 5.6.100 and 5.6.200 VDAs such that they would have the pieces from 5.0/5.5 so that you didn't need to apply them on top as a patch. That would have meant that customers could have used 5.6.100 or 5.6.200 as an upgrade (for existing XPDM systems) or are a complete installer regardless of whether something was XPDM-based or WDDM-based.

2) Citrix could have placed a warning in the 5.6.100/5.6.200 VDA installer indicating that it was intended to be an upgrade only and not a standalone installer. Of course for Physical PCs with Aero it's meant to be a standalone installer, so I'm still not clear on what exactly the differences are between the "supported" 5.5/5.6->5.6.1/2 upgrade versus installing 5.6.1/2 straight away.

3) Citrix could have released 5.6.100 and 5.6.200 as MSP patches if they were truly intended to be patches. Of course this would have completely screwed up the RemotePC stand-alone scenario.

4) Citrix could have disclosed exactly why it's necessary to treat 5.6.100 and 5.6.200 as patches. In other words, why can't a person use 5.6.100/5.6.200 as a stand-alone installer? The only difference I've seen at all between the two deployment paths is that things are all jacked up in Add/Remove Programs and you can't leverage the Repair feature of Windows Installer to reconfigure the VDA. Personally I couldn't give a crap about that because I stopped using the MSI config tool as well as AD OU-based discovery since Citrix patched XenDesktop 3.0 at my request to include the ListofDDCs values.

So is this issue resolved? Not in my opinion. What Citrix needs to do is put out a comprehensive VDA that supports both deployment scenarios or at a minimum fully explain to people why they should perform dual certification deployment scenarios. For me personally, I'm recommending all customers use ONLY 5.6.200 VDA code regardless of whether they are using XP or Windows 7 and whether it's VMs or Physical. So far no problems as a result of that, but the deployments of 5.6.200 are just beginning so we'll see if I end up regretting that decision. Anyone else been bitten by this nonsense?

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Hi Shaun,

I've examined the install files from both versions and as best I can tell, there are two parts to the install. There is XenDesktopVdaSetup.exe which creates the "Citrix Virtual Desktop Agent" entry in add/remove programs referred to by and there is XdsAgent_x64.msi which creates the "Citrix Virtual Desktop Agent Core Services" entry and is the actual meat of the VDA. The 5.6.100/5.6.200 updates are full copies of the VDA Core Services component and as such are right to be distributed as MSIs, but they don't include the "Citrix Virtual Desktop Agent" component because this hasn't been updated.

So what does the "Citrix Virtual Desktop Agent" component actually do? As far as I can tell it just provides a GUI to configure the actual VDA and prepare a VM with optimizations such as disabling last access timestamp and so on. Deploying the VDA without this component is supported since that is exactly what Citrix recommend if you want to distribute it with group policy:

In they don't actually say you can't install it standalone, just that it is not "meant" to be installed that way, but it must be OK to do so because that's exactly what you would do for a GPO deployment which is supported. The only caveats being that you need to find other ways of applying any optimisations (the group policy article has methods for many of them) and you don't get the configuration wizard mentioned in, but you wouldn’t want that for an automated install anyway. If you are happy with them then I can't see a problem, although it would be nice if Citrix would make that clear in their documentation.

If you do want the wizard and the updated VDA without going through two installs then you should try using the original XenDesktopVdaSetup.exe with the original XenDesktop installation source, but replace the XdsAgent_x64.msi (or 32-bit equivalent) with the updated version from the download. You'd need to test that yourself and certainly wouldn't be a supported scenario by Citrix, but it nevertheless has a high chance of working successfully. You'd need to judge for yourself whether that made sense to do. Bear in mind that this is exactly what Citrix did themselves in updating from 5.5 to 5.6 since the XenDesktopVdaSetup.exe part stayed at version 5.5 for that release.

While Citrix certainly could and should have documented this better, I feel bad picking on them for this given that the state of the Linux Receiver makes this look wonderful by comparison. To just get the linux receiver installed on a 64-bit system I have to first modify the installer to remove the check that stops it from installing on a 64-bit system! I'm totally stumped how Citrix can manage to release a download for the 64-bit Linux agent that actually has a check in the installer that means it cannot ever install on any 64-bit system without modification. How could that possibly get through QA? Did they never test it at all? There's other issues as well that I won't go into now, but that one just seems incredible.



Thanks for providing some excellent additional info.  I guess the frustration in all of this for me (and my customer) is that there was clearly an indication from Citrix that there was only one supported installation method which clearly conflicted with usage of Windows Aero / RemotePC.  I think they could have done a much better job putting out a good VDA that had all of the necessary bits in it and I think they definitely could have amended documentation to indicate that standalone VDA was perfectly fine to use and exactly what things you would sacrifice by using it instead of the other upgrade path.  I just think there were far too many things wrong with the approach taken and I think it's a result of far too much emphasis on putting new code out and not enough emphasis on quality control.  But that's my opinion.

Again, thanks for sharing.  Some great stuff in there.



Great article, I wish I had seen it about two weeks ago. :)

If you happen to use MCS on VMware hosts for/with have to install from the original agent off the XenDesktop CD (getting the "Citrix Virtual Desktop Agent" part) in order to get the under-the-hood MCS components that allow for customizing images after they are cloned and spun up by XenDesktop.

Found that out the hard way when I totally uninstalled the old VDA and then installed the 5.6.200 version in my new base image, thinking that was the right way to go based on some older documentation.  Then I spent a long afternoon trying to figure out why my MCS-provisioned desktops from that new base wouldn't change names and register themselves with the DDC.

Lessons learned (one of many Citrix Lessons I have been learning of late).