Impacted Citrix Versions: 7.X XenApp/XenDesktop

The organization I work for uses Citrix XenApp to publish resources for our end users. One of our most recent clients was our first real client to use Citrix XenApp 7.X (they are currently on XenApp 7.11) and after the first few problems were ironed out with their environment, we started to see an issue with their environment as more and more users started to use the XenApp environment. The issue presented to us was that the user was unable to login, and they would receive a message that the desktop was unavailable or that they already had a session in progress. When a user would receive this message, they would not be able to login to the citrix environment until the next day. If we looked in Citrix Director we would see one of two scenarios as outlined below.

  1. The username of the user calling in would not be in the list of user sessions reported by director. Instead what we would see is “-“ in the username list (and on bad days we would see multiple “-“). If we checked the server listed with “-“ as the username, the username of the client was not found. If a quick query was run on all of the servers, the username of the caller would not be found as logged in to any of the servers and no processes would be running under the user’s username.
  2. The username of the user calling in would be in the list of user sessions. Even though the user would be listed, the session could not be logged off through director, and if you looked at the list of logged on users on the impacted server the user was not listed as logged in or running any processes.

For Additional Information On This Issue See Here

Now it is important to note that we did have a policy in place that a user could only have one session at a time in the citrix environment, and that after server reboots at night the user could log in again.

After much research into the issue, I discovered that the root cause of this issue appeared to be that the Citrix Broker Session would (for one reason or another) hold onto a citrix session in it’s memory on the server. A user would login to a server and for whatever reason (executable errored out on login/logoff, legal banner timeout, session error, etc) the citrix broker session would not remove the session from its internal memory and not report back to citrix director that the user was no longer logged into the server. So even though the session was gone from the server, Citrix thought the session was still around due to the broker session not removing it. To resolve this issue, you can restart the server, or more simply, restart the Citrix Broker service on the impacted server. The big issue was being able to detect these broken sessions automatically without a user having to call in first. Digging through the citrix database, the error id was finally able to be identified to allow for the creation of a script to proactively monitor for these phantom sessions. Since putting this code in place as a scheduled task in my work’s environment, there have been 0 calls into our service desk regarding phantom sessions. To help out others, I have provided a link below to the Github repo for the code we are running in our environment (along with examples) to automatically clear up phantom sessions.

Hopefully it can be of help to you.


Paul DeArment Jr

Systems Engineer, Powershell Enthusiast, Lover Of Automating All Things.