Showing results for 
Search instead for 
Did you mean: 

STM's Load Balancing VMWare View Security Servers - Persistence not working

New Contributor

STM's Load Balancing VMWare View Security Servers - Persistence not working

Hi all,

First time asking a question on here so any help much appreciated. We seem to be having a problem with a newly purchased pair of STM's load balancing VMWare View Security servers across two different sites. The first issue is during the initial authentication, firstly the user enters their username and one time passcode, then the user hits submit to validate these credentials. The next step is for the use to enter their windows username and password, they then click login. Now at this point occasionally the user is returned pretty quickly back to the first login prompt where they have to enter their username and one time passcode again and start the whole process again. This might happen some half dozen times before the user is finally logged in.

The second issue which seems related is when you first start the VMWare view client and hit connect then cancel when you get to the first login box and try this again it fails unless you close the VMWare view client down and re-open. This will keep happening working then not working, working then not working and so on.

We currently have the persistence class set as JSESSIONID as defined in the VMWare view deployment guide, all these problems go away if we switch to using the IP persistence base class. We want to avoid doing this as we have large number of users connecting from behind a single IP at multiple sites.

Any help with how to debug or enable detailed logging would be much appreciated. It would also be nice to hear from anybody who is using the Riverbed's for a similar function.


New Contributor

Re: STM's Load Balancing VMWare View Security Servers - Persistence not working

Just for reference we got this working firstly by using a traffic script rule to get the JSESSIONID and store this in the persistence table then direct a returning connection to the correct pool. This worked even though the JSESSIONID persistence class didn't.

We then improved this further by capturing the username and using the username to direct to the user back to the same VMWare View Pod based on a timeout of 24 hours in the persistence table, this is for users who get disconnected and try to reconnect during the working day.

We are wanting to take this further by adding integration into VMWare View to determine if the user is connected to a specific View Pod or not, this way we'll always be able to check if a user has a session disconnected. This is going to be done by using a custom in house made integration component. There's a bit of work involved with this so it'll be a few weeks before we get that done.

If anyone needs any help with STM's and VMWare View deployments let me know.