VMware View 4.6 on Server 2008 R2, ESXi 4.1, Windows XP desktops.
Anybody seen this? Occasionally, the View connection server is assigning a user a new session every time they disconnect (not logoff---disconnect) while also maintaining the previous one(s) and staying logged into all of them --obviously causing an issue for this user. The user is getting a new session on every reconnect and AD login logs show the user getting 18 unique workstations just on Friday between 10:40am and 10:44pm! There seems to be a pattern of certain users having repeat problems. We have seen one or two users per week experiencing this issue.
The only way to break the loop is assign the user to a new pool... but we have seen at least 2 or 3 users call back saying they have the same problem. In View admin, we reset all of their desktops and they appear to be fine after that.
What type of pool is this? Floating or Dedicated?
If Floating, there is a setting that enables a user to have multiple sessions, try to uncheck that if checked.
// Linjo
In additon to what Linjo has said I have also seen this happen when a VM gets locked up or goes into a not responding state. I'm curious if you were to RDP and try to login as the user on the disconnected session if it would allow you.
The users in question were connecting to floating pools that have the "Allow multiple sessions per user" set to No.
What about the pool settings "Log off immediately after disconnect"
If this is configured obvously new desktops will be given from floating pools
"Automatically logoff after disconnect" is set to 1440 minutes (24 hours). "Delete or refresh desktop on logoff" is set to "Refresh Immediately". Nothing seems to be misconfigured as it generally works fine, just sometimes certain users get a new desktop during logon instead of the existing one they just had.
This is a longshot, but do you have any locations where end-point devices are scripted to automatically connect to a specific pool on login? We had a really odd set of issues with that once: a user would disconnect from a session in one pool, then go to a location where the client was scripted to connect to another pool. View would get all confused, because it would want to connect the user to the disconnected session in the first pool, but would be forced to connect them to a session in the new pool. If they were to disconnect from that second session, rather then logging off, then it seemed to create lots of problems for View when the user would login again later. Essentially, the users would end up with orphaned disconnected sessions, and then wouldn't be able to log in correctly later.
Also, is there any chance that the users are using the shade to select "Autoconnect to this Desktop" from the Options menu?
Like I said, it's a long shot.
Dave
Interesting idea. We do not script where folks are directed when connecting based on their physical location, only based on which pool they are assigned to.
We have the exact same problem, Windows 7 x64 VM's. Are still testing our new non-persistent environment but have seen this happen with multiple users. Did you find any solution for this?
--
Regards
Carsten Keller
VMware support has suggested that the guest desktop VM that is selected for the connection is unable to process the connection request beause its CPU utilization is too high. After a 10-second timeout, the broker chooses another desktop if the first does not respond. We can confirm this seems to be the case.
I have this exact same problem.
Windows 7 x64 pool, floating....
However, my problem seems to be limited to only one user. Everyone else seems to be reconnected to their disconnected session with the exception of one person. For that person, every time they reconnect to the floating pool, a new session is allotted to them.
-Pete
We are experimenting same issue here:
Windows 7 VM
Floating pool, Composer
View 5.2.0 build-987719
any updates?
Is there anyway to extend the connection server broker timeout?