This has come up a few times now, most often on Brian’s blog (for instance here and here): XenDesktop uses ICA to deliver virtual desktops to endpoint devices, so why doesn’t it have the same capabilities as XenApp?

Before I go into details on the differences in capabilities of XenApp and XenDesktop, just a few words on the technical background: “ICA” is a rather wide-ranging concept. If you look at the details, it includes of a fairly low level “core” that deals with concepts such as capability negotation and security of the data stream. Most of the “interesting stuff”, such as graphics, drive mapping, etc is handled through virtual channels built on top of this core protocol. You can envisage a virtual channel as a direct connection between a piece of software on the client and on the server, and the data sent between these components is tunneled through the ICA connection. So ICA both provides a backbone, and on top of that many of the “ICA” features are in fact fairly independent pieces that use the core ICA protocol as a communication pipe.

What does this mean for XenDesktop? Well, of course the ICA stack in XenDesktop inherits heavily from XenApp (Jeff has blogged on this extensively, and Brian has a more detailed analysis too). But the underlying infrastructure is very different: XenApp builds on top of Terminal Services, while XenDesktop uses basic OS APIs. This means that some XenApp features that are intricately linked to the Terminal Services platform, like shadowing, are by no means a straight: “just recompile this for Windows Vista and it’ll work”. Instead, we had to re-code some features from scratch in a way that’s different from, but compatible with XenApp. All this takes time, and that’s the main reason we had to prioritize which features were shipped in the first version of XenDesktop. In addition, since we were re-working some aspects, it also meant that we had the opportunity to incorporate some innovations and enhancements, such as extended support for multiple monitors and – coming soon – support for USB devices.

Now looking through the limitations listed in the technical FAQ, here is a bit more background:

  • Kerberos SSPI: For this feature to be really useful you will typically have to mark the computer that your end users connect to as “trusted for delegation”. While that may be ok for a relatively small number of well managed XenApp server, it’s less clear that you’d want to do this for thousands of virtual desktops, where your users may have full admin rights. Moreover, Windows XP doesn’t support constrained delegation, which makes this a less attractive solution. Lastly, from a technical point of view this feature integrates deeply with the logon process, and this is one area where XenApp and XenDesktop differ considerably. As a result of all of these reasons, we did not prioritize this for the initial release.
  • SmartCards: this is a very important feature for a relatively small, but vocal target market. Again, from a technical point of view it is far from a straight port from XenApp. There are some unique considerations for virtual desktops, the applications that reside on them, and the apps that might be hosted on XenApp. Having said that, it is a very high priority item and we are working on delivering it as soon as possible.
  • SpeedScreen: SpeedScreen is a term that refers to a large array of technologies that optimize the end user experience. The first version of XenDesktop shipped with support for the majority of SS features, including SS Browser Acceleration, SS Image Acceleration, SS Progressive Display. Now for the features that didn’t make the cut: SS Multimedia Acceleration and the ability to change the quality of Flash based on bandwidth were unfortunately too late to make it into the first release, but we are well under way with it now. The situation is less clear with SS Zero Latency – XenDesktop already supports mouse click feedback, but keyboard type-ahead is a technology that is not terribly easy to set up, and can be tricky to get working with more recent applications that you would typically find on a virtual desktop; furthermore the bulk of the other SpeedScreen features already provide a highly optimized end user experience in high-latency environments. As a result, for now we are assessing how we can best make additional functionality available on XenDesktop.
  • PDA Sync and Twain: again, these are fairly tied to the Terminal Services infrastructure on XenApp and we made the decision to take a little more time to do handle these devices (and others beside them) in a more compatible and user-friendly manner through our upcoming USB remoting technology in XenDesktop – look for this soon. This is one of those areas where it just didn’t make sense to simply replicate what we had done in the past, and instead make an overall improvement.
  • Shadowing: as I mentioned before, on XenApp this is based off Terminal Services capabilities that just aren’t available to us in XenDesktop. Subscription advantage for XenDesktop Platinum comes with Citrix GotoAssist, which is a more complete replacement for shadowing, or you can also use the built-in Remote Assistance feature built into Windows for a premise-based solution. We also have plans to support shadowing functionality in future, but with the available alternatives, customers are still able to achieve the same capability.
  • SmartAuditor: SmartAuditor is used by a relatively small customer segment, and thus wasn’t among the highest priority items for a first XenDesktop release. There has been quite a lot of prep work for this already, and I am confident that we’ll include this in one of the future XenDesktop releases.
  • Audio on Vista: this is a rather complex area technically - Vista’s audio architecture differs fundamentally from that used in Windows XP, and we need to completely re-implement the audio framework in PortICA to support Vista. This effort is nearing completion now. The good news is that we will be able to take advantage of this rework to integrate much better audio codecs in future and improve user experience with audio significantly.
  • Perfmon Counters and User Experience Metrics: again lack of support for these metrics was due to resource constraints, and there are only minor technical difficulties to make them available on XenDesktop.

I hope this post has helped to give you an idea of the differences between XenDesktop and XenApp - and that we’re not standing still here, but working as fast as we can to deliver an ICA stack that has full parity – and in some cases additional improvements – when compared with XenApp. Keep in mind that it took many, many years to add all these capabilities on top of the core ICA protocol, and we’ve accomplished quite a bit already and are closing in on several more. Most importantly, hopefully this dispels the myth that there is anything  fundamental that would prohibit us from making it the equal of XenApp ICA.

(Note: I updated this post to clarify and extend on a few of these items and to highlight where XenDesktop’s ICA capabilities exceed that of XenApp, including support for higher multi-monitor resolutions. And as was pointed out: perhaps this article should instead be titled “Why ICA is ICA after all “.)