Citrix Client Types: Features and Limitations
Today Citrix offers a Full Program Neighborhood client, a Program Neighborhood Agent client, a web client in some varieties, and a java client. As from version 8, an all-in-one client has been introduced. In order to create some clarity in the client chaos, this article should help you see the light again.
Client types and technology over time
Way back in Citrix time, they only has a Program neighborhood client. Life was simple. Application resolving over port UDP 1604 and ICA sessions over 1494. A few years during the Metaframe 1.8 FR1/sp2 a new deployment way was introduced called NFuse. Together with that, Citrix introduced the first web client, in a few formats. The 256kb large active-x plug-in, and its bigger brother the ica32t.exe which had more functionality. Together with that, application resolving over UDP 1604 was dropped, and XML TCP/IP 80 application resolving kicked in, and is still used today.
NFuse technology evolved from 1.0 to 1.7 and at some point the Program Neighborhood Agent (PNA) was introduced. A bit of time later, the java client was added to the list.
The size of the clients grew more over time, as functionality was added for Citrix MPS 3.0 and the latest CPS 4.0. MPS 3.0 introduced Session reliability, introducing a new port to connect, using port 2598. (Even today people get confused, that the client needs a new port open on the firewall, where 1494 had been used for so many years. Disabling session reliability on the client 8.0 and higher often gets you quickly back on the road, if the server is lower then MPS 3.0).
NFuse is now called Web interface, and is at version 4.0.
The current all-in-one client, including the PN, PNA and web client, is the biggest, being a 3.4 mb download.
Keep an eye out on the Citrix client download page, as currently the “Citrix Access Client package” is listed on top, and includes the Access Gateway client. Using this client with a default install, towards a default Citrix environment without an Access Gateway will cause errors during use. Most people will need the “Citrix Presentation Server” section when downloading a client.
Push or Pull
There is a big difference between the Program Neighborhood client (PN), and the other clients. The PN client was designed to be locally installed, and configured. (They could be preconfigured before deploying if needed. Read CTX466058 on the details). All connection information was stored in local .ini files and if connection information needed a change, the user had to do it himself, or required the admin to script the change to the .ini files if he was skilled enough to do it that way. The PN client pushes these settings to the server, to get an ICA session started.
The other client types, are a local installation (except the java client which is loaded into the client’s system memory at first start), but with zero configuration done on the client.
These clients rely on pull technology to get the information needed. They logon to a web portal (either NFuse or Web interface) and acquire a preconfigured ICA file, with all information needed to start a session. This puts all maintenance back on the server side, and is a blessing for administrators as changes require much less work.
Install and usage rights
A burden even today, is that all client installations require local administrator rights during the installation. Due to a small glitch in the client, it is sometimes even needed to manually set write access to this key for a user “HKEY_LOCAL_MACHINE\Software\Microsoft\MSLicensing\Store” in order to get a session started.
Citrix has discovered that needing local admin rights during an installation is not always favorable, and that domain administrators prefer automatically installing the client via the Active Directory. This has lead to the Citrix creation of the .msi version of the client, which administrators could easily push out to clients, without needing the user to have local administrator rights. (MS article 259459)
Everything has its price, and the .msi client cannot be used via the citrix client update mechanism, so that functionality is lost.
If you’re switching from .exe to .msi in your environment, also keep in mind that an .msi cannot upgrade the .exe client, and requires the old client to be uninstalled first.
Once the client system is on .msi, upgrades are a walk in the park. Citrix article CTX987123 describes how to create a silent PN or PNA .msi installation.
If you’re not using the client update mechanism at all, disabling the usage which is “on” by default, will speed up the client logon process.
Changing from PN to NFuse/PNA or web client
For those people who want to take back control of their client settings, but already rolled out the full PN client in the past, don’t worry. You can setup a Web interface website, next to your existing and running environment. Basically the Web interface is a web based version of the PN client, and does not change or touch existing farm settings.
When people connect using the full PN client, their local settings are overruled by the preconfigured settings, they get from the web interface server. That gives you an easy conversion of technology, without any changes on the client side.
If at a later stage, you decide to force people to use your new Web interface technology, instead of the old PN application resolving mechanism, just simply change the default XML port from 80 to another one on the farm, and none of the PN clients will work in their classic ways. Connecting them to the web interface will fully function though.
When to use what client type
As I said earlier, the PN client has been there historically, and is still fully used today. It has however lost its charm to the web and PNA client I think, with the pull instead of push technology. If you feel comfortable with it, by all means keep using it.
So, how do you choose between the PNA and the web client when switching to pull technology?
The PNA client is a client that fully integrates with the users existing windows desktop. It can add published apps icons to the desktop, looking like local apps. Therefore, a very transparent way to deploy Citrix sessions to your users. One of the most important points of the PNA over the web client is the “Desktop Credentials Pass-through” support.
Using the PNA client, is also very popular as a deployment method for thin clients. Administrators publish the desktop, and use the PNA client on that published desktop session, to jump to published apps on another Citrix server.
When using a web interface server in the DMZ, keep in mind that “Desktop Credentials Pass-through” does not work, as the web interface server needs to be a domain member server, and that the server is often in a workgroup inside the DMZ. That makes the functionality lost for PNA clients connecting to such a server.
The web client is most popular in internet deployments. A web interface in combination with a Secure Gateway. (Often on the same server, sharing 1 public IP, and using 1 SSL cert). Considering the characteristics of that architecture, it could benefit some LAN/WAN deployments also.
Since the use of the web client is not always possible, administrators often configure their web interface server, to use the java client as a fallback option, should the web client use be not possible. You can read about how to set this up here: http://www.citrix4ge.de/wim/wimcs3.htm
That same webpage has a huge resource of web interface customizations, in case you get hooked on using the web technology.
For those of you who are thinking of using the java client permanently, keep in mind that the java client does not interact with the underlying OS, so when using a Windows 2000 Citrix server, and a Windows 2000 or XP pro client, you cannot use the free TS call mechanism, and the java client will consume a TS call in that specific setup.
For those of you who expected a summary of features in a client version in this article, I would advise to have a look at the following document, where Citrix sums that up already: http://ctxex10.citrix.com/kb/entry.jspa?externalID=CTX103289
In the past, choosing the wrong client type could end you up with a lot of work when changing architecture. Today Citrix offers an all-in-one client that can easily let you switch your client towards different Citrix backend infrastructures. I can only encourage you to start using this new client type.
In this article I tried not to make a simple feature summary, but to show you the possibilities, and some limitation of features, belonging to client types or architecture choices. When you want to go deeper into the possibilities of a specific client, it is always good to start with the ICA client admin guide. It might be tough to go over a hundred pages, but it might give you that little extra hint on what could work or not work in future changes.