Together with my client I recently encountered a very interesting problem whereby one of their homebrew applications recently ported to Citrix Xenapp did not function correctly. Basically it was showing a (rather misleading) error message which indicated that there might be a connectivity problem between the frontend (installed on Citrix SBC hosts) and the backend (based on firebird database).
Initially we thought it might be related to the fact that it was wrapped into App-V 5 package but that was immediately excluded when it was found that in a separate environment the package was actually launching without any problems. I then went through the usual analysis starting from policies comparison and ending with a long night spend on comparing procmon logs to search for more in-depth clues. Although I found that the frontend was able to initialize the connection, a quick comparison with a normally working version made clear that a standard sequence was not completed.
Thanks to my client who had an access to the backend it was possible to detect that something is going wrong with a connection process to the firebird database. Basically, an application was written in a way to register the user from which a frontend connection was coming from (here: a host from which ICA session was initialized). It was doing it through inserting the hostname and adding an additional random string to uniquely identify the connection. What was really boggling our minds was that instead of a standard hostname a random string was presented. That random string was also particularly long. As a result, together with an added part, that string was longer than 31 characters which was more than firebird database was capable of accepting.
With that in mind I again compared a working environment’s configuration, this time centering my attention on policies part (Citrix policies, GPO policies) but found nothing interesting. A little research on the internet suggested that the client name variable was being manipulated by Citrix Web Interface instead of Citrix policies. Basically, it was possible to override client name with a random string to obfuscate the origin of the ICA connection or generate a new name with each new connection by editing Web Interface / Storefront configuration. The variable in question is called overrideIcaClientName and it should be set to OFF in order to fix the variable and show the real host name (which usually is much shorter than 32 characters!). After changing that string the frontend application started to work like a charm as a standard application as well as an App-V package.
Although it might be considered as a purely engineering task, I also found this story challenging from solution architecture perspective. Porting an application to the new Citrix environment was an important milestone in a project I am currently working on. It was impacting for all sides and a search for a solution required active participation of several parties with a different background. Searching for possible culprits and usual suspects (Microsoft App-V, Citrix, Windows OS, GPOs, human errors) took a considerable amount of time and human resources. My personal note to this is that a Citrix Administrator not only has to have a holistic overview of all associate services around a product he or she is responsible for but also has to be able to speak with AD administrators, application developers and (obviously), the client. Without a thorough application analysis from the backend (to which usually Citrix Admins do not have or do not want to have access) it would not be possible to find out a solution.
Another point is that Citrix shot itself in a foot by barring this unfortunate variable “client name” from the Citrix Studio management console in Xenapp 7.x. In comparison to previous versions of Xenapp it is barely visible in the GUI (you only see it when you actually click on a connection in details pane. But it’s so frustrating to search for this information because refreshing Citrix Studio is horribly slow!); Instead of it, a much faster way is to use a powershell cmdlet that links the troubled user name with his/her clientname variable:
For more details about how to edit overrideIcaClientName, please click here for Web Interface and here for Storefront. After editing the .conf file it may be necessary to reboot the server altogether because a simple iisreset did not work for me. If you want to understand use cases for changing this variable I suggest that you read this article.