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

2203 Virtual Apps Disconnection issues and questions


Question

Running Virtual Apps 2203 LTSR on Windows server 2022 infrastructure.

The issue initially was seen on Mac users, sometimes when their connection was interrupted (due to the Mac having a crazy 2 minute sleep/hibernation setting) they woudl not always reconnect to the original disconnected session.  Sometimes it would create a new session.  The issue with that is we are running FSLogic profile disks and they could not open Outlook as their OST file was already open in the other disconnected Session.  Yes I understand Outlook in Cached exchange mode is not recommended on Virtual Apps, but it is only 15 users and max, more like 5-8 a day so usage is minimal.

I found this article talking about "Auto Client Reconnect" https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/manage-deployment/sessions.html 

In the second last bullet point in the Auto Client Reconnect section it talks about this

"If the server is configured to reset sessions, auto client reconnect creates a new session. This process requires users to enter their credentials to log on to the server."

This appears to be exactly what is happening to us, but I have no idea what it means by "server is configured to reset sessions" 

The Auto reconnect Policy settings make no mention of this "reset sessions"  I have looked here https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/policies/reference/ica-policy-settings/auto-client-reconnect-policy-settings.html and have no real idea where to look or understand what the "server is configured to reset sessions" means or how to see where it is configured.

Link to comment

5 answers to this question

Recommended Posts

  • 0

I've done a great amount of troubleshooting into this already and so far believe the reconnection part of the problem to be related to or even caused by to the session reliability functionality. Please try disabling it temporarily via a Citrix policy and let me know here what that does for your situation:

 

image.thumb.png.9be8e1d8c8554fbd392110dac2bbf4b5.png

 

The disconnection (of an active session) part of the problem on the other hand seems to be introduced in VDA 2112 and up but largely solved for MAC users through CWA 2204 in combination with a rollback to VDA 1912 LTSR.

 

So a separate Delivery group for the MAC users where session reliability is disabled and the VDA server runs 1912LTSR and the MAC clients CWA 2204. That's your current most stable environment for MAC users. Windows users on the other hand are fine running VDA 2203 LTSR with CWA 2204.1

Link to comment
  • 0

Hi Andy.  Thanks for your reply.

Nice to know I am not the only person with a fault.  Is Citrix aware of a possible issue?  If so lets hope we get a fix soon.

I only have 1 Server running as a Machine Controller, it is only a 15 user site.

So I cannot have that server added to 2 Delivery controllers.

The short term fix for us is education to the affected users to Log off their sessions and to alter their battery Sleep timers to 15-60 minutes so that if they walk away for an extended period of time it is unlikely they will get disconnected.

I have not actually been able to reproduce it in action, but have had to reset sessions to get user Logged back in.

I found this about Session roaming https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/manage-deployment/sessions.html#session-roaming

Perhaps something changes on the Mac that makes it think the session roaming value is set to Disconnected Only, and when the Mac wakes up it is not seen as the disconnected client but as a new client and it therefore creates the new session.

 

Link to comment
  • 0

Hi Clarke, Hi Andy,

 

we have similar problems and I had also asked here in the forum, Andy had already given me some tips.

https://discussions.citrix.com/topic/416209-session-states-are-not-updated-after-resume/

 

May I ask you if you can recreate my problem on your end, Clarke? It's a ~5 minute job, I described the procedure in the post above. Thank you very much.

In the meantime we have reported the problem to Citrix, it has been looked at and logs have been collected. A reply is still pending.

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...