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.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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?