Very often in our own and our clients’ XenApp and XenDesktop environments we face an issue where some sessions mysteriously stay connected with no owner when users disconnect. These phantom or ghost sessions cause lots of headache to IT support teams. To briefly describe the issue:
– User session disconnects
– The Session State changes to Connected
– The Current User is displayed as “–“
Here is how the issue looks like in Studio:
Usually, users are no longer able to reconnect to their sessions, their XenDesktop desktop freezes and in some cases users are no longer able to create new sessions with ‘Cannot start desktop’ or ‘Cannot start app’ error messages. Sometimes the session may hang on ‘Loading user profile’ and then user’s Receiver disconnects. The user impact is especially critical when you have Citrix desktop statically assigned to users or users are limited to a single session. Manually rebooting XenDesktop desktop or XenApp server resolves the issue but this is not a very good option for most of us.
Somewhat similar issue is described in Citrix Support Article CTX128715 but we found that in most cases this is not the real cause of the issue and the proposed resolution doesn’t work. We have observed this behavior in all versions of XenApp/XenDesktop 7.x including the latest 7.11 and 7.6 LTSR CU2, and even in older XenDesktop 5.x.
The issue is being actively discussed is this Citrix Discussion and it is caused by Citrix Universal Profile Management (UPM). While Citrix is working on resolving the issue, here is a Handy Script by Andy Simmons. The script searches the Site for Citrix Searches for sessions that have been in a “Connected” state for an unreasonably long time and forcefully reboots the corresponding machines, provided the machine only supports a single session. Working VDA sessions would normally be in “Active” or “Disconnected” state. Once a session is in “Connected” state for more than 5 minutes, it is most likely broken.
While the script works fine for the most of VDI (XenDesktop) and Remote PC use-cases, it does not address when the issue is on XenApp multiuser session hosts. The solution for XenApp would be restarting the Citrix Desktop Service on affected servers which should not affect existing active user sessions. iRangers team is currently investigating and testing the solution. We will rewrite Andy’s script to support multi-sessions and restart the Citrix Desktop Service as opposed to rebooting VDAs if our testing is successful. Stay tuned.
Right in your email inbox
Useful data from iRangers Experts
Subscribe to our mailing list and get interesting updates and tips.
Thank you for subscribing.
Something went wrong.