How to verify that NetScaler COOKIEINSERT persistent sessions are working?

Ever had issues with your Storefront load balancing setup not working after painstakingly setting up NetScaler load balancing?

Now, let’s discuss a few reasons why cookie based persistence are better (in some scenarios) compared to Source-IP based persistence.

In some circumstances, using persistence based on source IP address can overload your servers. All requests to a single Web site or application are routed through the single gateway to the NetScaler appliance, even though they are then redirected to multiple locations. In multiple proxy environments, client requests frequently have different source IP addresses even when they are sent from the same client, resulting in rapid multiplication of persistence sessions where a single session should be created. This issue is called the “Mega Proxy problem.” You can use HTTP cookie-based persistence instead of Source IP-based persistence to prevent this from happening.

If all incoming traffic comes from behind a Network Address Translation (NAT) device or proxy, the traffic appears to the NetScaler appliance to come from a single source IP address. This prevents Source IP persistence from functioning properly. Where this is the case, you must select a different persistence type.

HTTP Cookie Persistence

When HTTP cookie persistence is configured, the NetScaler appliance sets a cookie in the HTTP headers of the initial client request. The cookie contains the IP address and port of the service selected by the load balancing algorithm. As with any HTTP connection, the client then includes that cookie with any subsequent requests.

When the NetScaler appliance detects the cookie, it forwards the request to the service IP and port in the cookie, maintaining persistence for the connection. You can use this type of persistence with virtual servers of type HTTP or HTTPS. This persistence type does not consume any appliance resources and therefore can accommodate an unlimited number of persistent clients.

Note: If the client’s Web browser is configured to refuse cookies, HTTP cookie-based persistence will not work. It might be advisable to configure a cookie check on the Web site, and warn clients that do not appear to be storing cookies properly that they will need to enable cookies for the Web site if they want to use it.

By default, the NetScaler appliance sets HTTP version 0 cookies for maximum compatibility with client browsers. (Only certain HTTP proxies understand version 1 cookies; most commonly used browsers do not.) You can configure the appliance to set HTTP version 1 cookies, for compliance with RFC2109. For HTTP version 0 cookies, the appliance inserts the cookie expiration date and time as an absolute Coordinated Universal Time (GMT). It calculates this value as the sum of the current GMT time on the appliance and the time-out value. For HTTP version 1 cookies, the appliance inserts a relative expiration time by setting the “Max-Age” attribute of the HTTP cookie. In this case, the client’s browser calculates the actual expiration time.

So some of the benefits of using cookie based persistence are

  • Easy to configure
  • Load balancer does all the work without involving the back end services (mostly a web server)
  • No connection table to maintain
  • Activity based – Time out is based on idle connection and not the total connection time
  • caters to most of the load balancing scenarios
  • if proxies are involved in the setup where source IPs are masked, this makes it an easy choice

Cons of Cookie based persistence

  • can throw off the load balancing where timeouts are set to 0 or when time outs are long lived
  • when Type 0 cookie is used, time of the cookie value is absolute(GMT time). When type 1 is used, relative time is used (local time)
  • hard to troubleshoot

Testing COOKIEINSERT persistence

Use Putty or some other SSH clients to login to the NetScaler.

sh lb vserver vservername

If you take a closer look at the snippet above, the letters in yellow shows that COOKIEINSERT persistence is turned ON with a time out value of 0 mins. This means that the cookies doesn’t have an expiry time set by the NetScaler appliance. The backup persistence is set to SourceIP with a time out value of 60mins. You can also see the cookie values at the bottom of the results staring with NSC_xxxxxxx

You will now need to get into Shell with an account that has permissions. To get to shell, type shell and hit enter

Now type the following

nsconmsg -i vservername -s ConLb=1 -d oldconmsg

In the snippet above, the highlighted text in yellow shows that persistence is set to Cookieinsert and the number of hits for each service. You will also get values such as response times, CPU and memory utilization.

VIP value shows the total number of hits to the vServer hits
Each service has a line starting with S (IP Address) and its status.
Hits (x, x/sec) shows the initial (method) hits to the service for a new connection.
P (x, x/sec) shows hits to the service that are served using a persistence cookie

Also, check the current persistent session via the commands below

sh persistentsessions
sh persistentsessions -summary


The curious case of NetScaler access with error message ” The Connection to “Desktop” failed with status (Unknown client error 1110)”

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

Users unable to change passwords via Netscaler or Access Gateway when “User must change password at next logon” is checked

EnvironmentNetScaler 10.1, Citrix Storefront 2.5, XenDesktop 7.5, LDAP Authentication

Issue – AD user accounts with the attribute “User must change password at next logon” are unable to change their passwords at the NetScaler /Access gateway page. However, users do have the ability to change the passwords by selecting “change password” from the drop down menu on the Netscaler page

Resolution – The issue was the Active Directory /LDAP Authentication profile that I created which had the Security Type set to PlainText. Changing it to TLS resolved the issue for me.


How to Configure ICA Proxy for XenApp & XenDesktop for Citrix Receiver for iPhone, iPod, iPad – Deployment Guide

I came across this super informative document from Citrix detailing the setup of Citrix access on iPads and other iOS devices. The document has been written for the older version of Netscaler and XenDesktop versions but i would think there isnt much changes in terms of configuration so is worth a look.

Solution Requirements

  • Windows Desktops delivered to iPhone, iPod or iPad
  • Windows Applications delivered to iPhone, iPod, iPad
  • ICA Proxy for Citrix Receiver iPhone, iPod & iPad
  • ICA Proxy for XenApp & XenDesktop
  • ICA Proxy for NetScaler Access Gateway Enterprise Edition – AGEE


  • Citrix NetScaler L4/7 Application Switch, version 9.1 build 101.5+ running Access Gateway (Quantity x 2 for High Availability)
  • Citrix XenApp Server 5.0+ or XenDesktop 4.0+
  • Microsoft Server with Active Directory
  • iPhone Configuration Utility
  • iPhone OS 3.0+, iPad OS
  • Citrix Receiver for iPhone v2.1+

The document can be downloaded  here citrix_agee_icaproxyxaxdreceiver.pdf

Tweaking Netscaler for XenApp/XenDesktop via TCP Profiles

I have recently come across this super blog from Citrix folks on the NetScaler Traffic Management classes. I thought i would rather add this in my blog for easy reference.

NetScaler has a highly scalable TCP stack which is built to take care of varying network conditions and various types of clients/servers. In any communication channel over TCP what makes difference is the client side stack, server side stack, intermediaries and network conditions. Beyond these core aspects the application layer as well impacts with the nature of application, size of request/response and how it makes difference to TCP connection characteristics.

For most cases what we have in default TCP stack holds well but if you know more about your application, client/servers and network conditions then you can use one of the built-in TCP profiles. These TCP profiles have fine-tuned TCP parameters which make significant difference in terms of lower latency, faster response time and better bandwidth utilization in given Application and network environment. NetScaler also allows you to create your own TCP profiles with these core TCP parameters which can optimize the TCP stack for your deployment. The TCP profile can be used globally which has system wide impact and it can also be used per vserver and service to localize the impact. Which means you can have different virtual TCP stacks for multiple vservers and services within same NetScaler, isn’t it really interesting?

The built-in profiles are aimed at common deployment scenarios based on different network and application characteristics. Let us understand the system supplied built-in TCP profiles:


  • Nstcp_default_profile
    • Default TCP profile impacting system globally
    • Any changes impacts the global TCP settings
    • Does not need to be bound to explicit vserver/services
    • Gets overridden by the vserver/service level profiles
  • Nstcp_default_tcp_lfp
    • This profile is recommended to be used in networks with
      • High bandwidth
      • Low packet loss
      • High Round-Trip Time (RTT)
    • Suitable for WAN kind of environments
    • Useful when there is dedicated bandwidth
    • Enterprise use cases across WAN
  • Nstcp_default_tcp_lnp
    • This profile is recommended to be used in networks with
      • Low bandwidth
      • High packet loss
      • High Round-Trip Time (RTT)
    • Suitable for WAN kind of environments
    • Useful when there is restricted bandwidth
    • Online use cases across WAN in shared bandwidth
  • Nstcp_default_tcp_lan
    • This profile is suitable for the LAN
    • Mostly to be used with servers in same datacenter
    • Useful when access is limited to same local network
  • Nstcp_default_tcp_lfp_thin_stream
    • Similar to Nstcp_default_tcp_lfp
    • Tuned for Small packets flow
  • Nstcp_default_tcp_lnp_thin_stream
    • Similar to Nstcp_default_tcp_lnp
    • Tuned for Small packets flow
  • Nstcp_default_tcp_lan_thin_stream
    • Similar to Nstcp_default_tcp_lap
    • Tuned for Small packets flow
  • Nstcp_default_tcp_interactive_stream
    • This profile is recommended to be used with
      • Chatty applications like telnet
      • Application virtualization environment
      • Small packet and quick feedback based Apps
    • Should work with different kind of networks
  • Nstcp_internal_apps
    • This profile is recommended only for Internal services
    • Should not be used for any other network service

Full credit to Citrite “Abhilash Verma” for taking time to write this stuff and the original writing could be found here