I have had several customers, and even other Systems Engineers here at Citrix, ask me about the differences between the newly released XenApp plugin, formerly known as the ICA client, and the Desktop Receiver which ships with XenDesktop. So, I figured I might as well write my inaugural blog on this topic.
Because the XenDesktop and XenApp technologies are so closely tied, many customers, and even some SEs, get confused around which client to use for the XenDesktop environment. Others view the Desktop Receiver and the XenApp plugin as interchangeable and believe they can be used to access either type of resource. Recently, confusion has increased around which client to use when you need both XenDesktop and XenApp connectivity because of two statements found in the documentation for XenDesktop 2.1.
An updated Desktop Receiver for use on XenDesktop AND XenApp resulting in a single point of access and management for customers living the virtualization dream and benefiting from the entire Citrix solution.
Installation of either the Desktop Receiver or the Desktop Receiver Embedded Edition on the same computer as XenApp plugins (client-side software for Citrix XenApp) is not supported. If you want your users to be able to access both virtual desktops and virtual applications from the same computer, Citrix recommends installing XenApp plugins on the virtual desktops that you create with XenDesktop. This allows your virtual desktops to receive virtual applications.
At first, I was confused by what appeared to be a contradiction of statements. However, as I began to research the behavior, I decided to go ahead and try the two clients. After spending part of a day testing both, I think I can explain how both of the statements above are correct, though they could have probably been worded a bit clearer.
The XenApp plugin (version 11.0) and Desktop Receiver (version 10.251) are different ICA clients. They both use a similar code base, so the functionality is similar. Both clients allow you to access published XenDesktops and/or published XenApp resources (applications or desktops), depending on what resources are available. However, at the moment, these two clients are not yet merged into a single code base, so you get slightly different behaviors between the two clients.
Using the Desktop Receiver
Since the Desktop Receiver and the XenApp plugin client share similar ICA code they cannot co-exist together, hence the need for Statement 2 from the XenDesktop 2.1 Release Notes. If you install the XenApp plugin client first and then attempt to install the Desktop Receiver, the install will fail and require that you first remove the XenApp plugin because it holds a version number higher than the Desktop Receiver.
The Desktop Receiver has only support for PNAgent and the web client. The Program Neighborhood Classic (with custom ICA connections) client is not installed with the Desktop Receiver. The Desktop Receiver does support the Desktop Toolbar, so you can run in modes other than full screen. The only limitation that I am aware of in the Desktop Receiver is that if you are using the Desktop Toolbar, the pass-through authentication method is not supported on Web Interface. You need to set the site to Explicit authentication. Once you authenticate to the site, the credentials are passed automatically into the XenDesktop. The loss of pass through authentication when using the Desktop Toolbar is a result of a tightened security infrastructure. Citrix is looking to address this in a future release.
When the Desktop Receiver is pointed to a XenApp farm, it works as a standard PNA client, and displays those resources only, thus validating Statement 1 from the XenDesktop 2.1 product update. The screenshot below shows the Desktop Receiver working like a normal PNAgent when pointed to a PNAgent configuration site that only has a XenApp farm configured.
One thing to remember is that with the Web Interface 5.0 that ships with XenDesktop, you can create a Web Interface or PNAgent site that aggregates resources from both the XenDesktop and XenApp farms, by simply adding the additional farm through the Manage Server Farms link on the site configuration. Then when users access the site, they will have all their available resources displayed. The screenshot below shows the Desktop Receiver when pointed to PNAgent site that has aggregated a XenApp farm with a XenDesktop farm.
Using the XenApp Plugin
With the XenApp plugin, access to normal XenApp published resources works as expected and you have the PNAgent, Web, and Program Neighborhood Classic (with custom ICA connections) options available. When accessing a published XenDesktop, you only get Full Screen mode (no support for the Desktop Toolbar or long-running operations feedback). I was able to successfully install and use the XenApp plugin to access both a published XenDesktop and a published XenApp application.
If you have an older ICA client, and you want to use XenDesktop, the recommendation is to use the Desktop Receiver for the user’s workstation and then inside the XenDesktop, install the older ICA client for connectivity into the existing farm. If you are going to use an ICA client or XenApp plugin in the XenDesktop image, be sure to point it to a site that does not have the XenDesktop published, or you risk letting the user create a XenDesktop auto-reconnect loop that will require manual intervention to stop.
In the end, it depends on what functionality you want or need to provide to the end-users. If you need Desktop Toolbar support, you need to deploy the Desktop Receiver. If you need the Program Neighborhood Classic or custom ICA connections, then your choice is to use the XenApp plugin. If you don’t have any pressing needs for either of the client-specific features, then you can choose either one.