The Citrix Receiver
While first introduced by Citrix at Synergy back in 2009, the Citrix Receiver was formerly known as the ‘ICA Client’. As Citrix added more products and capabilities to their portfolio (and thus more clients to install and manage) the name slowly evolved from ICA Client to Citrix Receiver (with a lot of steps in between), as we know it today.
The idea behind Receiver was and still is, that it functions as a container, or placeholder to hold all other Citrix client software providing administrators with a central point of management. The Receiver itself doesn’t really do anything.
This way all the various Citrix clients that might be needed on a client device, like the ICA Client software to access online applications and desktops, Password Manager, SSL VPN client software, the Secure Access Gateway client and so on, can all be managed and maintained from a single location.
The idea behind this project? Before commenting, read the introduction blog post here
You might also recall that around the same time Receiver was introduced, Citrix started to rename some of their existing clients. For example, the ICA Client was renamed as the Online Plugin, and the Access Gateway client to Secure Access Plugin; they also introduced an Offline Plugin, Web Plugin etc.
The thought behind this was that these clients would ‘plug in’ to Receiver, which would then take over with regard to management and maintenance. The only thing missing in this approach was a mechanism to deliver (and manage) the various plug-ins to the Receiver software installed on the client device. For this, they introduced something called a Merchandising Server together with Citrix Receiver 1.0. The Merchandising Server provides the administrative interface to configure, deliver, and upgrade plug-ins for your user’s computers.
From there Receiver has matured from version 1.0 back in 2009 to version 4.4 at the time of writing. The 4.4 client went GA in December 2015, and it was only as of version 3.0 that it was actually referred to as the Citrix Receiver (available as a complete package); before that, it was still ‘just’ a placeholder for all the other plugin clients accompanied by the Merchandising Server mentioned earlier.
As of Receiver version 3.2 and newer versions going forward, it slowly moved away from the Merchandising Server for updating and maintaining the plug-ins contained within Receiver, handing this functionality over to Citrix.com. Anyway, let me dig in a bit deeper.
The Citrix Receiver didn’t just appear out of nowhere: it was quite a journey. During the next section, I’ll try and take you through some of its history and highlight a couple of the most important changes along the way.
- It all started with the first release of the ICA Client software, version 4.0 back in September 1998. Note that I am not referring to the actual ICA protocol and earlier releases like Citrix Multiuser, WinView, and WinFrame after that; these were all released (much) earlier.
- It contained the Program Neighborhood, Program Neighborhood Agent (PNAgent) and Web install packages.
- As of version 11.0, it got renamed as the Citrix Plug-in for hosted applications, which was also known as the Web Plug-in. This was over ten years later in June 2008. Although it was renamed, it still contained the same software packages.
- While this didn’t directly lead to another name change, around version 11.2 they officially released Citrix Receiver (version 1.0) together with the Merchandising Server. This was in May 2009 during Citrix Synergy.
- As mentioned, initially Receiver was meant as a placeholder for all other Citrix clients, which as of Receiver 1.0 got renamed one by one (Plug-ins), or most anyway. It stayed this way all through 2010.
- Soon after, when version 12.0 came out (March 2010) it got renamed (again) to the Citrix Online Plug-in. Are you still with me?
- With the release of version 13.0 of the ICA Client software or Online Plug-in, it was now officially renamed as Citrix Receiver, version 3.0 at that time. This happened in August 2011.
- As highlighted earlier, as of version 1.0 Receiver was a self-service orchestrator and an updater also referred to as the Receiver Infrastructure (Merchandising Server).
- At that time Receiver, 3.0 got split into two parts, Receiver Updater, and Receiver Inside.
- Receiver Inside was integrated into the Online Plug-in to form a new package, which got namedCitrix Receiver Enterprise. *
- It stayed this way up to Receiver Enterprise version 3.4.
- With version 4.0, which got released in June 2013, they changed its name to Citrix Receiver for Windows, the name it holds today.
- The Receiver Updater, as a separate component together with Merchandising Server, stayed with us until August 2015 (EOL). After a user installed Receiver Updater on his or her user device, Receiver Updater installed, updated, and restarted the Citrix Receiver without any user interaction needed.
- In between, from Receiver Enterprise version 3.2 to version 3.4 it still included the original PNAgent software, which was then referred to as Legacy PNA.
- As of version 4.0, the PNAgent functionality was no longer part of Citrix Receiver. This also meant the end of the Desktop Lock feature as it relied on the PNAgent functionality.
- Interestingly enough, Citrix reintroduced the Desktop Lock feature with the launch of Citrix Receiver version 4.2. Only this time they named it Receiver Desktop Lock.
- Citrix Receiver version 4.4 was launched in December 2015, which is the most recent version at this time.
- As of late-2012 they slowly moved away from the Receiver Infrastructure and Merchandising Server, which was EOL in August 2015.
- Today we install and configure Citrix Receiver either manually, using Group Policy (adm GPO template), via a (start-up) script of some sort, as part of a base image, using our software distribution software of choice, or… through Receiver for Web sites. When a user accesses a Receiver for Web site from a computer running Windows or Mac OS X, the site will attempt to determine whether Citrix Receiver is installed on the user’s device. If Citrix Receiver cannot be detected, the user is prompted to download and install the appropriate Citrix Receiver for their platform.
- When Citrix started to rename their Citrix client software (remember the Plug-ins?) they also introduced a couple of new clients, like the Offline Plug-in, the Desktop Receiver, and the Citrix Self-Service Plug-in a.k.a. Dazzle. And I’m sure I left one or two out.
- The Self-Service Plug-in (Dazzle) was integrated with Citrix Receiver and your existing XenDesktop and XenApp infrastructure. It communicated with the Citrix Delivery Services (basically what we now call StoreFront) or Web Interface. Merchandising Server was used to control and manage it.
- The Offline Plug-in, version 5.1, was first introduced in May 2009 and disappeared in July of 2012. Earlier it was also referred to as the Citrix Streaming client, and used, as the name implies, with Citrix-streamed applications. For offline use, I might add. 2Unfortunately, Citrix Streaming never really took off.
- The Desktop Receiver was aimed at launching hosted shared desktops only (full screen), not published applications. Here they added the well-known pull-down menu, making it easier to switch between your hosted desktop session and your local desktop.
- 2018 update: The Workspace App (client) will replace Receiver. It will (again) function as a placeholder for other types of connectors, agents, and such – in addition, it will do a whole lot more than that.
*While the standard Receiver for Windows is for general use, Receiver for Windows Enterprise is intended only to support:
- Repurposed PCs and Thin Clients configured with desktop lock
- Applications that require Fast Connect-enabled products
- Applications that require 508 compliances
Don’t get confused by the different version numbers. There is a version numbering scheme for the ICA Client software versions (which has been renamed multiple times) and one for the Citrix Receiver versions.
While the previous section primarily focused on the Citrix Receiver for Windows, there is a Citrix Receiver for almost every platform out there; I’ll list them here:
- Receiver for Windows.
- Receiver for Mac.
- Receiver for iOS.
- Receiver for Linux.
- Receiver for Android.
- Receiver for Chrome.
- Receiver for HTML5.
- Receiver for Windows 8/RT.
- Receiver for Windows Phone.
- Receiver for BlackBerry 10.
Next to the various types of Receivers there are also multiple Receiver plug-ins like the HDX RealTime Media engine for Microsoft Skype and Lync (multiple versions), Receiver for Desktop lock (multiple versions) and the Offline plug-in.
It is also worth mentioning that Citrix has been working on an X1 release of the Citrix Receiver (X1 stands for eXperience 1st), which, combined with the latest StoreFront release (both are still in tech preview at the time of writing), offers some nice additional features like:
- Enhanced StoreFront management console
- The ability to group resources by organizing them into self-managed categories.
- Specific and flexible branding options (no more green bubble theme), including the use of customer logos and different color schemas.
- Eventually, all this will apply to the NetScaler interface (logon page) as well.
- The ability to use one Citrix Receiver for both XenDesktop / XenApp-hosted applications, as well as mobile applications hosted from XenMobile / App Controller (no more Worx Home, it will be part of the Receiver X1).
- A unified look and feel on all devices and different platforms, including connections through the HTML5-based Receiver.
Once the Receiver X1 will be released (GA) there will be no need for any of the other Receiver editions mentioned earlier: The Receiver for Enterprise, for example.
The X1 will be able to offer all the features and functionality you might need, including but not limited to,(legacy) PNA support, the ability to put all published applications in the Start menu or on the desktop, the Store concept where users can subscribe to their own applications, or they can be pre-subscribed using Keywords, the use of Single Sign-on and personal branding (you can get very creative), while the ‘old’ green bubble theme is still available/optional as well.
FMA fact: The Receiver X1 combined with StoreFront will greatly simplify overall management and improve the user experience on multiple levels.
2018 update: I guess we all know what happened to the X1 thought, right? On 07-08-2018 Citrix announced the GA of their Workspace App, here’s the announcement blog post.
Citrix Receiver communications
The Citrix Receiver is a client application enabling us to connect up to various Citrix services like XenApp and XenDesktop, but also the XenMobile App Controller, the NetScaler Access Gateway and StoreFront, to name a few more. While Citrix Receiver basically sits idle during the user authentication and application enumeration processes (you don’t really need a Citrix Receiver for that), it plays a leading role when it comes to actually launching a published desktop and/or application and establishing a secure connection up to XenApp / XenDesktop. It literally channels the ICA / HDX traffic back and forth between the client and server.
FMA fact: HDX is not a replacement for the ICA protocol. It offers a set of capabilities or technologies that offer a high-definition user experience, which are built on top of the ICA remoting protocol.
Once a resource is launched, once all background communications are done and load-balancing decisions have been made, one of the first things that will take place is something referred to as the ICA handshake.
During this phase, the client (Receiver) and the server (VDA) will exchange information on the virtual channels that the client supports: here the client basically tells the server which specific capabilities (virtual channels) it can or should use during the connection. This way the server knows what to expect and what virtual channels it can or should use.
Made possible with the support of my sponsor IGEL
I know, virtual channels? Yes. A big part of the communication between the client and the server takes place over and through what Citrix refers to as virtual channels (and not just Citrix by the way). Each virtual channel consists of a client-side virtual driver (part of Receiver) that communicates with a server-side application (part of the VDA).
Virtual channels (there can be 32 channels in total) are mainly used/applied for some of the bigger, well-known features like client drive mapping, smart cards, the clipboard, printing, audio, video and so on. However, the Citrix Receiver also supports a whole bunch of additional features and functionalities that do not involve or need a virtual channel.
And of course, from time to time, new virtual channels are released with a new version or Feature Pack of XenDesktop / XenApp and Receiver products to provide additional functionality. LikeFramehawk and ThinWirePlus, for example. Those were released as part of Feature Pack 3 for XenDesktop 7.6, including a new Receiver (4.3) if I am not mistaken) on the client side.
Each virtual channel represents a specific feature or functionality on its own. But don’t worry, I will elaborate a bit more on all this during one of the upcoming chapters where we will talk about the ICA protocol and the HDX additions in more detail.
FMA fact: While some think that ThinWire is still a relatively new technique, it is not. ThinWire has always been there. It is a core component of the ICA virtual display channel stack (for over twenty years now). That’s why they rebranded their latest addition as ThinWire Plus, although it has had several names along the way.
So, you see, most features and functionalities configured at server level (mainly through policies) will need to be supported by the client as well; there is a strong dependency between the two (think about the ICA handshake mentioned earlier). And while most features apply to XenDesktop / XenApp VDAs, some do apply to StoreFront, NetScaler and/or Web Interface as well, most are related to security and communication.
Receiver for web access, which is built into Receiver based on HTML5 technology, or secure remote access via the NetScaler Gateway, NetScaler full VPN capabilities, RSA soft token support, pass-through authentication, Smart Access policies and filters, IPv6 and more. While these types of features and functionalities mainly apply to components like StoreFront, NetScaler etc. your locally installed Citrix Receiver must be able to support these as well.
As mentioned, some of the bigger and better-known features that get built into XenDesktop come with their own virtual channel; however, the Citrix Receiver also has an extensive and impressive list of features that it is capable of without the need for a virtual channel. Check out the link below to find out more:
Although not mentioned on the Receiver Feature Matrix, the Desktop lock is another example. It is dependent on the type and version of Receiver installed and probably best described as an add-on on top of Receiver. The Desktop Lock feature is often used when thin clients are not optional, and you do not want to get rid of your older desktop machines just yet. When installed and configured properly (on a domain-joined machine) it will pass on the user’s AD/domain credentials, logging them directly into their VDI session, without the user being able to interact with the local physical desktop.
But there is more. Features like Session Sharing, Session Reliability, Auto Client Reconnect and ICA Keep-Alive etc. are all Receiver-dependent as well, although these have been around for some time now. Again, more details will be discussed in the ‘ICA / HDX protocol’ chapter.
During the StoreFront section earlier, I already mentioned a couple of ways how users can connect up to StoreFront using Citrix Receiver. However, this doesn’t just happen magically, somehow you will need to tell Receiver how and where to connect to: there are a couple of ways to achieve this.
First, and this is a popular approach, you can configure something called e-mail-based account discovery. This way, all your users will have to do is fill in their email address. After that, once they hit OK, Citrix Receiver will automatically determine the NetScaler Gateway or StoreFront Server associated with the email address. This method is based on Domain Name System (DNS) Service records. The user will then be prompted to log on using their domain credentials.
FMA fact: If you want to make use of e-mail-based discovery you will need to use StoreFront, it does not work with Webinterface.
Using StoreFront, you can also create your own provisioning files, which contain connection details needed for your users to connect. Once Receiver is installed all they have to do is double-click the provisioning file and Receiver will be automatically configured. When using Receiver for Web sites, and many do, you can also offer the provisioning file on there. Just like with the Citrix Receiver installation file itself.
As a third option, you can provide your users with the information needed to connect up to StoreFront for them to enter manually. Here you can use the XenApp services site if you are still on 6.5, or you can provide your users with the address of your StoreFront server for them to be able to access the Store(s)on there.
After the information has been entered Receiver will first try and verify the connection: once done and successful your users will be prompted to fill in their user credentials.
By adding StoreFront to Receiver, as we’ve just talked about, you can configure something called Self Service Mode (will be enabled by default). It enables the user to subscribe to resources directly from the locally installed Receiver (right-click on the system tray icon) and, just like with the Receiver for Web sites approach, Keywords can also be used to pre-subscribe certain resources to your users.
Another potential advantage when using this approach (opposed to the more limited Web Access Mode (although preferred by many) where Receiver is not configured, and users access a Receiver for Website) is the ability to (almost) fully manage and customize the application shortcut location (or you let your users decide for themselves).
This way, published applications can appear in your users’Start menu and/or desktop without them being able to uninstall. Your users will not have to manually subscribe to their resources before being able to launch them. Of course, these two modes, Web Access, and Self Service can be configured and used side-by-side.
FMA fact: All, or at least most, of these resource shortcut management options were already available with Citrix Receiver Enterprise up to version 3.4, when they killed it. It took up to Citrix Receiver version 4.2 to get this functionality back.
Just be careful and think about when to implement which solution. Not all of your users will be too happy with a preconfigured Start menu or desktop, for example, especially when dozens or more applications are involved. Unfortunately, there will always be some pros and cons no matter which route you choose.
Luckily, when needed you do have some options to play with. Applications can be configured on an individual basis to be placed in the Start menu or on the desktop, or you can let your users decide. Put them all on the desktop or in the Start menu by default or a combination of all options mentioned: it is up to you. This is accomplished by manually configuring the Citrix Receiver. If you want…
- Your users to be able to choose the resources they want in their Start menu, then you configure the Receiver in Self Service Mode.
- Your users to be able to choose the resources they want in their Start menu and you also want to force a few specific resources onto their desktops, then you will need to apply those specific settings on a per-application basis.
- By configuring the Receiver with PutShortcutsInStartMenu=False you prevent the Receiver from putting application shortcuts into the Start menu automatically.
- PutShortcutsOnDesktop=truewill put all application shortcuts on the user’s desktop.
These are just a few examples to give you an idea of the possibilities: it’s very flexible. There are a couple of more options available so make sure to check out the E-docs pages on Citrix Receiver.
FMA fact: By disabling the self-service mode (it is enabled by default) subscribed-to applications can only be accessed through the Start menu and desktop shortcuts. This is also referred to as short cut-only mode.
To conclude
Now, of course, there is still a lot more to tell and share when it comes to the Citrix Receiver, but hopefully, this section provided you with enough information on some of its inner workings and more specifically why it is such an important piece of the puzzle.
- No matter how you decide to deploy and configure Citrix Receiver, make sure to instruct your users.
- Don’t forget to inform your helpdesk employees when planning configuration changes to Receiver.
- I briefly introduced you to the Web Access and Self-Service modes. Remember, it does not have to be one or the other. They can be configured and used side-by-
- A couple of years ago the Self-Service mode was released as a separate plugin; it is now built into Receiver.
- In fact, some of the most important modules that make up Receiver today are the ICA Client software, the Self-Service plugin, and the Single Sign-on module for ICA.
- It all started with the ICA Client software back in 2009. Since then it has gone through a lot of name changes and of course, the underlying technology also matured over time.
- The upcoming Receiver X1 is probably a great example of its evolution during the last decade.
- When upgrading to a newer version of Receiver, make sure to follow the step-by-step procedure as outlined by Citrix; have a look at this CTX article: CTX135933.
- As it stands today, the Citrix Receiver version 4.4 should be able to upgrade from any of the older Receiver versions that might be installed without any issues.
- When upgrading to a version older than 4.4 and you run into any issues, have a look at CTX137494, the Receiver Clean-Up utility.
- Do not forget about the ICA handshake and the earlier mentioned virtual channels.
- The Citrix Receiver can be managed and configured using various methods, for example: using the command-line, registry settings, StoreFront account settings, or on a per-application basis using Studio and Group Policy Objects.
- When viewing the Citrix Receiver Feature Matrix, remember that not all features are on there.
- By default,the HTML5-based and built-in (StoreFront) Receiver is not enabled:this needs tobedone manually.
