If you have a farm running XenApp 6.5 and you have Citrix Secure Gateway installed keep an eye on this issue:
If Session Reliability is enabled via Citrix Secure Gateway (see CTX112764) , you should also enable it on the XenApp server.
Session Reliability can be enabled on the XenApp via AD group policy and via Apps Center (IMA policy)
NOTE 1:
If you install CSG version 3.2.1 and Session reliability doesn’t work, three things might be happening:
1. CSG broke session reliability. This is a bug. Here is the fix: CTX118021 – this also applies on XenApp6.5. This bugs causes this:
2. Your XenApp server probably doesn’t have port 2598 listening on the XenApp server. This is caused by:
3. The Citrix XTE service in the XenApp 6.5 box cannot start.
Update to Note 1: Citrix upgraded the Secure Gateway to version 3.3.1 that includes this fix. So if you are running any version of CSG prior to 3.3.1, you must upgrade to this version to avoid sudden disconnections
NOTE 2: Session Reliability(SR) should be enabled if the XTE service has started on the XenApp server AND you enabled SR under Citrix Apps Center. The CLI netstat command (netstat -bano) should show you if any active sessions are running under session reliability.
If you are running CSG version 3.3 then you need hotfix 24 for XenApp 6.5 to prevent SSL error 45 errors
P.S: One of the things CTX118021 does is to fix the path to the XTE service that was wrong in the registry and in the httpd.conf file.
As a refresh check, it out this definition of Session Reliabity: Session Reliability (SR) “Session reliability keeps ICA sessions active and on the user’s screen when network connectivity is interrupted. Users continue to see the application they are working in until network connectivity resumes.” source: E-docs
A good analogy is this: a user is traveling by train and has a laptop that is connected to a Citrix environment via a WAN/WI-FI connection He has a notepad session opened and he/she is typing something. Suddenly, the train enters inside of a long tunnel, and travels for about 45 seconds. The satellite signal is lost during that time. The user continues to type on his/her notepad session. All the keyboard entries made during that time are stored in a memory buffer. As soon as the train leaves the tunnel, the connection is reestablished and the data recorded into the memory buffer is sent back to the server. When the user saves the document everything is saved. SR did its job of keeping the session “active” while the connection was broken. The user never had to reconnect to the session by logging back into the session, everything was transparent/seamless to the user as if he/she was typing on a local notepad session. That is the beauty of SR!
(updated February 21, 2013)
Discussion