view broker handing out sessions that are in use

[ryandeluca]

Having an issue with non persistent pools. Desktops start being given out fine as users log in. At somepoint the broker will start trying to pass off desktops that are already in use. The user enters credentials as usual and authenticates, when they see the desktop to connect to/click on, instead of saying "available" it will say "logged on". If they continue and double click on this desktop to connect, it will grab a session already in use. The user who had this session will be kicked out. I'm still trying to figure out exactly when this happens (no solid pattern yet). Of note here is that the username is the same for all users, it's the only account entitled to the pool. We've seen this in two different pools that we are testing. We are using view connection server 5 with hp 5565 thin clients, some are zero clients some aren't (5565z and 5565). We've tried both view client 4.6 (comes standard on these Thin clients) and an upgrade to view client 5. Sometimes when this happens, clicking cancel and then unchecking or checking use secure connection (port 443 vs port 80) to the connection server is a workaround and the desktop will say "available" and be a new desktop, but again there is no pattern to this, sometimes 80 works sometimes 443 works, sometimes both "steal". Let me know any other information needed. Thanks.

[mydearcosmo]

Sounds like a bit of a hassle. I am also having this problem with the available and logged on state. How can I fix it?

[royberk]

Ok, the username is the same. Its a generic account that anyone can use.

So the first person logs in domain\someone to Desktop1. He is working fine.

Now when the broker needs to assign a new one it looks at the user. domain\someone is trying to connect again. Is he trying to access the same machine or a different one?

Thats probably the issue.

My recommendation around this would be to issue several logins, not just one for an entire Floating Pool. But maybe there is a way around this and Im not remembering it.

[jjp333200]

With a floating pool there should be an option to 'allow multiple sessions per user' under pool settings.

[ryandeluca]

royberk - it should give the user another desktop, there are plenty of available desktops in the pool, if the pool somehow hits its maximum amount of desktops, users should receive a "no available desktops" error. We aren't even getting that far before sessions start to be "stolen", so instead of say 10 thin clients taking 10 desktops from a pool of 20, they might get to say the 8th handed out, then the 9th thin client steals one that is already connected, the user whose session was stolen reconnects and it pulls their desktop back, leaving thin client #9 disconnected again.

jjp - yes, that option is set.

[mittim12]

Just curious but is there any reason why you don't want to have unique usernames?   It would mitigate these problem and also making user tracking much easier.   

[ryandeluca]

User tracking to these desktops isn't neccesary. A generic account for x amount of users per pool (different pools for different business clients/contracts) works, they connect to other resources from the desktop with unique accounts. We don't want/need many additional AD accounts. fwiw we do have some pools with unique usernames for users that connect to resources by passing AD credentials. Also, this was never an issue for us (generic account/floating pool/desktops being "stolen") prior to view 5.

[dsiview]

When a user logs in and is able to "steal" an existing login are they always logging in from a new location (client)? When you enable multiple sessions per user, the broker allocates the desktop on the basis of the identity of where that user is logging in from, and if the same location is seen then it will look to see if a desktop has already been allocated for that client location and look to re-use it.  If this isn't the case perhaps you can provide broker logs (privately to me) for a period of time where a user has been able to steal a session.