Since it’s inception in 1996 with the first release of WinFrame the “ICA Client” has been on a continuous improvement cycle. As WinFrame grew and evolved into XenApp the client grew and evolved right along with it. As you can imagine the client portion of XenApp that runs on every users device has been a fertile ground for integration and feature enhancement. Over the past 13 years we have added support for all sorts of client facilities like the clipboard, local drives, serial and parallel ports, printers, multiple monitors, etc … And we have rarely and reluctantly ever dropped or “deprecated” any features or support. E.g. We have only recently dropped support for “Windows NT 4.0 Workstation” years after Microsoft had ended their support. For the most part this strategy has been pivotal to the success of XenApp. Many of our customers have used XenApp to maximize their investment in desktop hardware by delaying the endless death march of the continuous and costly desktop refresh cycle. However, it’s time for change. The latest release of the client has swelled to over 3 million lines of code (which is a lot, trust me) and the test matrix has grown to the point where we spend a great deal of effort every release just on maintenance and testing alone. This, of course, makes it very difficult to be as responsive as we would like to the needs of our customers and our business.
So what are we are doing about it?
1: We are introducing a new client strategy that revolves around what we are calling the “Citrix Receiver”. The Receiver is all about simplifying and enhancing the user experience. The Receiver achieves this in many ways but most germane to this discussion is it’s ability to hide complexity from the users and make the Administrators job of managing and updating the client easier.
2: We are modularizing the client. Breaking the client into smaller more manageable pieces allows us the ability to be more granular with our changes and enhancements and more flexible in our release schedules.
For example the “XenApp Plugin for Hosted Apps” will break down into three smaller Plugins:
• The Hosting Engine - Responsible for all of the heavy lifting associated with the delivery of Hosted Apps and Desktops.
• SingleSignOn - Responsible for passthrough authentication from a domain joined client.
• XenApp User Experience - Responsible for managing the integration of XenApp into the users environment.
* These Plugins will be on independent release schedules and are delivered by the Citrix Receiver as necessary.
What’s the upside?
• The Receiver is the last Citrix client you will ever need to install - The Receiver has a premise based Server component that will act as staging area and control facility for propagating Plugin updates out to the end users. The receiver will periodically check the Server for updates and, provided you allow it, will update with the newer Plugins as they become available.
• More frequent release of enhancements - Plugins will be released independently and on their own schedules meaning we’ll be able to bring enhancements to market when they are ready without having to wait for a periodic client release.
• More granular control over what gets installed on the clients - Administrators will be able to control which users get which Plugins and when.
* Note: A standalone Plugins Pack will be made available for those who would like to continue to manage their client updates with existing methods.
What’s the downside?
In order to make room for these changes we need to remove\deprecate some of our legacy features:
1: Thinwire 1 - Thinwire 1 is a low-level graphics virtual channel that was replaced by Thinwire 2 back in MetaFrame 1.8 FR1 (August 2000). Removing TW1 from the Windows client means that you won’t be able to connect to a MetaFrame 1.8 Server with the newer client. See, I told you we were reluctant to remove anything.
2: Program Neighborhood --Program Neighborhood has been around since the early days of WinFrame. PN is a launch pad for XenApp Applications. When launched it connects with the XenApp Server and lists the Apps that are available for the user. PN was effectively replaced by PNAgent (Now the XenApp User Experience Plugin), which provides the same functionality with a far superior interface by integrating the XenApp delivered Apps transparently into the users Desktop. We removed PN from an active enhancement path several generations ago but we’ve been keeping it alive in maintenance mode to give our customers time to move on to the newer and better XenApp Plugin. There is more to the story but I think I’ll post that as a separate Blog entry.
Some advanced answers to anticipated questions.
1: When is this all happening?
* Citrix receiver will first become available in late Q109 with the componentization of the client available late in the year, probably somewhere in the middle of the second half.
2: Will there be separate Receivers for XenApp and XenDesktop?
* No. There will be one “Citrix Receiver” that will deliver Apps and\or Desktops depending on which Plugins are installed and active.
3: Will I be able to control, which Plugins are installed?
* Yes. The Citrix Receiver will provide Administrator control over which Plugins are installed on which machines.
4: How many Plugin Packs will there be?
* Two. We are trying to keep this simple. There will be one pack with all of the Plugins and another one designed to be more lightweight for more streamlined deployments.
5: What if I want more granular control over the Plugins?
* We strongly encourage customers requiring granular control to use the Receiver but the Packs will allow for context switches that will toggle the install of specific Plugins. I.e. “CitrixReceiverPluginPack.exe /No USB”