I was pulled into to look at a problem for one of our customers with their Netscalers which stopped the user connections intermittently throwing a very “helpful” error message ” the connection to the desktop failed with status (unknown client error 1110).
The customer description was “it only started to happen a few weeks ago and these days it’s quite impossible to land a successful connection from the outside of our corporate network.”
I managed to get a couple of screenshots of error messages from the users and they appeared like below. When queried, the internal access via Storefront is working fine.
Looking at the error message, there are a multitude of reasons why you would get that, and I am outlining the common areas to check in such cases.
- Check if the Root certificates and intermediate certificates are available on the client devices. If frequently patched, the client will most probably have the latest and update Root CA’s from various public CAs. Check the IE’s / Other browsers’ certificate store to verify the Root and Intermediate CA SSL certs
- If using non-IE browsers for connectivity, switch over to IE to see if it connects. IE is the safest bet when it comes to connectivity to Citrix environments.
- Check for SSL ciphers attached to the NetScaler Gateway vServer. If high security ciphers are used, this issue may occur. Relax the cipher suites to see if that makes a difference. Again, if cipher suites are an issue, the problem will occur every single time when you connect and not sporadically.
- Check the STAs on the NetScaler and ensure that it matches with the STAs configured on the WI/Storefront. This is one of the most critical setting to check and probably the first one to check if the issue occurs only sporadically. There is a high possibility of an STA mismatch as it turned out to be in my case.
- Check the FW from the NetScaler to the VDA – As the title says ensure that the Citrix ports to the VDA are open from the Netscaler
Time for another article, this time on the Native Receiver issue which gave me a lot of pain, was resolved by tweaking a simple setting.
We had users reporting issues connecting to the Storefront store using native Receiver. The Receiver version was 4.1 running on Windows 8.1. The issue was random and a lot of times, the issue resolved itself after a few tries.
The exact error message was below
One of the workaround for us was to get the users to connect to the Storefront via a web browser and that worked flawlessly.
The issue was later identified with the Internet Explorer proxy settings – the users reported issues had a different proxy server set due to some other special access requirements and hence gave the errors every now and then. In my case, the issue was the proxy server entry highlighted in red box.
There could be other reasons why this error message occurs – Storefront connectivity, Storefront services issues etc but remember to check this as well and it might save you a lot of time.
I always loved the good old Citrix Web Interface; but being one of the products from Citrix, pretty much every single product will eventually be put to rest to open the door for newer technologies and advancements in Citrix delivery framework.
Lately I have been working on a big deal on the Storefront side of things and one thing i have noticed is the slow loading times for the Citrix login page and the Storefront console. The below are 3 neat little things that you can do to make the storefront run faster.
- Disable NetBIOS over TCP/IP in the network adapter properties
- Add the .NET code to the ASPNET.CONFIG file. I have to make changes to the files in the following 2 folders Microsoft.NET\Framework and Microsoft.NET\Framework64 directories. This changes are even endorsed by Citrix by their KB here. The below is the code that you need to add towards the end of the line.The file could be located in C:\Windows\Microsoft.NET\Framework64\v2.0.50727 and C:\Windows\Microsoft.NET\Framework\v2.0.50727
<?xml version=”1.0″ encoding=”utf-8″ ?>
<generatePublisherEvidence enabled=”false” />
3. Also uncheck the below 2 settings in the advanced tab under Security
Your SF page will load much faster after this!
I have been looking into an issue for quite sometime where users were unable to populate the saved passwords in Internet Explorer 8 running on XenApp 6.5. The below steps outlines the procedure that I followed to fix the issue.
XenApp 6.5 with Citrix UPM 4.1.1 and Internet Explorer 8
- The first thing that I checked was the exclusion list where IE stores its cookies and saved passwords. That wasn’t the issue in our case.
- Ensure that the Citrix UPM setting “Process internet cookies on logoff” is Enabled as below
- Also ensure that the below settings are in place
The above settings fixed the issue in my case. I hope it helps someone … Cheers
Here is one of the easiest way to populate Favorites in Internet Explorer using Microsoft group policies.
Using Group Policy to populate the favorites in Internet Explorer allows you to make sure your users have quick access to mission critical websites. To do this, create or use an existing GPO that is properly scoped to the users you want to publish the links to.
In Group Policy Manager right click the GPO and click Edit.
Expand User Configuration / Policies \ Windows Settings / Internet Explorer Maintenance / URLs
Double click Favorites and Links
Click Add URL
Provide a name and a URL. You can even provide the location for a custom icon for the site.
Once you are finished, click OK in the Favorites and Links window.
Close the Group Policy Management Editor to save the policy.
Refresh the Group Polices on a client and test.
Should the user delete this link, it will re-appear at the next Group Policy refresh.