The IT Melting Pot!

Ok, we’ve had some issues with Citrix Receiver version 13 for Linux.. and it’s not just ONE issue. I found one that I thought I just have to share… so it’s lab Saturday for me at the office in a true geek manner with two XenClients and my favourite MacBook!

I guess that some of you have tried the Linux Receiver and knows how hard it is to get working, especially on a 64-bit distribution of Linux like Ubuntu 12.04 LTS och 13.10 LTS.

If you follow these instructions you can get it onto the device and then login through a browser (local Receiver UI may still not be full functioning!)..

https://help.ubuntu.com/community/CitrixICAClientHowTo

What I’m about to show you is that it’s not just only getting Receiver on the device and ensuring that the SSL certificates are trusted. You then have to be able to use it as well externally through a NetScaler Gateway (NSG) into StoreFront and your XenApp/XenDesktop VDA’s.

Just assume that you have a production environment that consists of a NetScaler Gateway and a StoreFront server, if you then in StoreFront have configured your NetScaler Gateway correctly and the appropriate STA configuration (with MULTIPLE STA’s) then you will notice that you can’t launch a session.

BTW, the recommendation from Citrix is to use multiple STA’s, right! See this from edocs:

For all deployments, if you are making resources provided by XenDesktop, XenApp, or VDI-in-a-Box available in the store, list on the Secure Ticket Authority (STA) page URLs for servers running the STA. Add URLs for multiple STAs to enable fault tolerance, listing the servers in order of priority to set the failover sequence. If you configured a grid-wide virtual IP address for your VDI-in-a-Box deployment, you need only specify this address to enable fault tolerance.

Important: VDI-in-a-Box STA URLs must be entered in the form https://serveraddress/dt/sta in the Add Secure Ticket Authority URL dialog box, where serveraddress is the FQDN or IP address of the VDI-in-a-Box server, or the grid-wide virtual IP address.

The STA is hosted on XenDesktop, XenApp, and VDI-in-a-Box servers and issues session tickets in response to connection requests. These session tickets form the basis of authentication and authorization for access to XenDesktop, XenApp, and VDI-in-a-Box resources.

If you want XenDesktop, XenApp, and VDI-in-a-Box to keep disconnected sessions open while Citrix Receiver attempts to reconnect automatically, select theEnable session reliability check box. If you configured multiple STAs and want to ensure that session reliability is always available, select the Request tickets from two STAs, where available check box.

When the Request tickets from two STAs, where available check box is selected, StoreFront obtains session tickets from two different STAs so that user sessions are not interrupted if one STA becomes unavailable during the course of the session. If, for any reason, StoreFront is unable to contact two STAs, it falls back to using a single STA.

So what do you do as an admin setting up your environment, I guess we add two STA’s!!!

For the sake of showing the issue let’s start of with our little EnvokeIT environment that has two STA’s configured both in StoreFront and on the NetScaler Gateway vServer as you can see below:

This is good! What I do now is to log on to my Ubuntu device running on XenClient to try it out. When I try to launch my EnvokeIT Desktop from the RfW I get this error message (“Cannot contact server for application: “EnvokeIT Desktop”, Server browser command contains an invalid parameter, The server name cannot be resolved.”):

It works like a charm on Mac and Windows… so what is the issue!?!

It took me a day to find out what we already by know if you’ve read the whole post that the problem is the multiple STA’s we’ve configured. When you configure Firefox in this case to open the ICA file with gedit instead of the local Receiver you see that you get these two STA tickets:

[EnvokeIT Desktop]
Address=;42;STA522135098;4CC3FD3050EE76F65D417D7C5B6286;STA809E1FE74E29;7B5842A6DCEEBE0E1E7267528B69736A 

This is the problem, I saved this ICA file down locally to try and figure out what setting or config it could be that caused this issue, removed LB and Content Switching of StoreFront, disabled ICA encryption, disabled session reliability, SmartAccess etc etc… I compared the ICA file from the one I got on my Mac and Windows clients that worked but couldn’t really figure it out.. then I read the error message again. It actually says that it cannot resolve the server name.. wait a minute! What if it is that the NetScaler Gateway cannot for some reason get the internal IP of the XenApp server from the STA, is it the STA? So I removed the last STA ID and ticket from the ICA file, saved it again and now I got an SSL error instead! GREAT! I thought that this was good though the ICA file had been “issued” quite a while ago so the STA ticket for sure had expired and wasn’t valid any more. So I went in and changed the NetScaler Gateway vServer to use only one (1) STA and the same on the StoreFront side:

Now let’s try it again! And YES, it works as you can see below:

This was great! I found the issue, but wait…. is it great!? NO, it means that Citrix has a bugg and have to release a new version with a fix for this. But wait again, is that the bad thing or is the real bad thing here that they don’t test their own products in a real production scenario?

This has now become another example where Citrix has some work on their side to ensure that they do proper test cases and quality assurance before releasing stuff!

I wonder if this could be one of the issues for that Thin Client vendors hasn’t incorporated version 13 into their Linux distributions…

Well, well.. now Citrix should be aware of it and so are you. Don’t try to run Citrix Receiver for Linux remotely (internally is totally fine though then the STA is not involved at all), but you still have to ensure that you get the Receiver installed properly using this crazy workaround to get it to work. Hopefully you have Puppet or some other configuration management tool in place to assist you with this nightmare so that each user doesn’t have to install it by himself. And then you have the certificate handling as well that isn’t that great.. managing the root certificates independently for the Receiver, come on Citrix!

Now my little lab and test Saturday can come to an end, have a great weekend all!

//Richard