Jump to content
Welcome to our new Citrix community!
  • 2

Users unable to re-connect to their disconnected sessions


Dawid Bbn

Question

Hi all,


At the beginning of July our users started experiencing issues with reconnecting to their disconnected sessions. This started to happen without us making any changes to the Citrix site or VDAs configuration.

I am able to reproduce this: after disconnecting a session and leaving it for 15+ minutes in the disconnected state, I am not able to reconnect to it any more. The logon process starts but then stops after a couple of seconds and the Windows desktop windows disappears.

 

Citrix Director shows “None” as the Failure Reason.

 

There are no any useful logs to base on in the VDAs, all looks normal as if the session was disconnected intentionally (Error Code: 0).

We’ve tried to update VDA agents from 2012 to 2106.

 

Same issue happens for users connecting from older/new thin clients, as well as from Windows clients with the latest Workspace app. Other, XenApp 7.15 Citrix servers, located in the same internal company network are not affected by this issue.

 

Is there anything more I can do to troubleshoot this on my side?

 

Thanks for your help!

 

Citrix Virtual Apps (i.e. shared Windows desktops).

Windows Server 2019

Users connect through internal StoreFront 3.12 servers

2021-07-23 17_37_15x.png

Link to comment

12 answers to this question

Recommended Posts

  • 0

Thanks for the input Carl,

I've done some more tests and it looks like users are not able to reconnect to their sessions only if they previously manually disconnected from Start Menu.

If they leave their sessions idle for the configured 15min "Idle session limit" (Set time limit for active but idle Remote Desktop Services sessions), they can reconnect fine.

Additionally, when testing reconnecting via RDP (after adding the user to the Direct Access group), a new session is created on top of the disconnected session - weird!

Link to comment
  • 0
On 9/27/2021 at 2:14 AM, John Vickery said:

has anyone figured out a solution to this issue? I will be opening a case on Monday.

Carl's post helped reduce the amount of "Failure = None" we where seeing in Director but did not completely remove them.
We still see on average 20+ a day with 1000 concurrent users.

Would be good to see what Citrix support says about it.

Link to comment
  • 0

Hi all,

After further troubleshooting, I ruled out the root cause on the VDA, Group Policy & Citrix Policy side.

It turns out that reconnecting to sessions works if done via Citrix Cloud Gateway Service "xxx.cloud.com" but fails via internal, on-prem StoreFront servers.

I used another internal 1912CU3 StoreFront server for testing, played with all possible Store settings but could not nail it down.

Do you have any idea what else I could try on the StoreFront server side?

UPDATE:
I get the below Event when reconnecting to disconnected sessions fail:

"The Citrix ICA Transport Driver connection from 10.x.x.x:1099 to port 2598 received an invalid packet during its SSL handshake phase."

If I disable Session Reliability, it does not appear though I still cannot reconnect to the session.

Link to comment
  • 0

All, our env is running 1912 CU6 (Server 2016) ~5k connections and we were having this issue with clients running Receiver 4.7, 4.8, 4.11, etc. It seems legacy serial & parallel port redirection was causing the client to crash/disconnect client side. Any attempt to communicate with our app using an older parallel device would instantly crash the session client side. Rendered useless until either 15 minutes of no attempts to login or manual intervention by logging off the "stuck" session. In our case, the application was still running server side. Manual log off would allow for login again. So far, reports of "stuck" sessions have not been reported from users running the latest 2203 build of workspaces connecting to our 1912 CU6 VDAs.

 

FWIW; I was able to see this improvement client-side firsthand today by reproducing the issue on Receiver 4.7, upgrading said user to 2203 (23.2.0.38), and ultimately unable to reproduce after the update. Not sure if this helps, but this is one avenue where these stuck sessions have been coming in.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...