I can't see it in the screenshot, but both sessions of that user are active?
Actually the user is having two connected sessions and one disconnected session.
But according to the pool setting "Allow multiple sessions for user-No" is the thing we have in our environment.
But I don't know how user is able to connect two sessions at a time.
Can anyone help me out on this?
I've seen this happen before in extreme circumstances. The user locked up their desktop in the floating pool, quit that desktop, logged back into the broker, and was assigned another desktop. I'm unsure if the locked up desktop simply wasn't updating it's status in View Administrator or what was going on but we ended up have to hard power it off.
Here the user can have two options.
1)Lock the session and logon to some other thinclient.
2)Disconnect or reset the session and connect again.
If he goes with the first step the session will be transfered from there to here, if he goes with the second step he will get a new session but the previous session will be in disconnected mode.
But the problem here I am having is user having two connected and one disconnected session.
Has any one faced this issue earlier?
Just wondering if you had a resolution to this issue?
We've experienced the same issue intermittantly. There'll be mutliple connected sessions when the "allow multiple sessions per user" option is set to "no". It's a rare event but it does happen and causes the user issues with regards to roaming profiles etc.
Please let me know your thoughts.
We recently had a repeat of this issue and thankfully we were able to do some trouble shooting before the user logged out. As stated previously the user had multiple sessions open even though the pool configuration was set to not allow this.
In the users original session the VMware agent running on their virtual machine had hung because an application they were running had crashed. This caused everything running on the virtual machine (including the VMware agent) to hang. The user then disconnected from this session using a button on their zero client.
Our theory is that the View connection server was then unable to communicate with the VMware agent on the original virtual machine and it therefore allocated the user another virtual machine when they subsequently logged in. We were able to repeat this process several times whilst the "hung" virtual machine was running and each time it allocated the user a different virtual machine in the pool.
Our conclusion is that these multiple sessions are caused by the VMware agent being in a hung state and unable to communicate with the View connection server.