I don't think "Never" is an option but the default is 600 minutes (10 hours).
Try to put it to something really high like 9999 or something.
Never is an option, but after reading it appears that Never is actually 20 hours. We use to be able to set a very high number and it work but since the upgrade 20 hours is the max.
It appears that's how it is documented now, as well: Documentation Center for VMware Horizon 6.0 with View - Global Settings for Client Sessions
"For clients that do not support application remoting, a maximum timeout value of 1200 minutes applies if the value of this setting is Never or greater than 1200 minutes."
Oh, sorry about that, it seems that I missed that new feature in v6!
If I read the docs properly it seems that older clients might have this limitation but newer clients might not (3.0 and later)
So to the OP, what clients are you using and if its something else then 3.0 could you try that one?
You need to update your clients to support the new "never" setting - the new horizon clients will occasionally send updates to the connection server, so that it knows to keep the session alive. Older client versions won't do this and only communicate with the server on an explicit action such as a desktop launch. An unlimited timeout is therefore not possible for old clients, as it would result in leaking session data every time one lost network connectivity or was reset - from the server side there would be no difference vs one that's simply idle.
All of our production machines are using Dell/Wyse P25 zero clients with the latest firmware. They still disconnect after the 1200 minutes maximum timeout is reached.
We are in the same boat with 500 Teradici zero clients. It looks like the fix in this KB (VMware KB: VMware View Session Disconnects at 20 hours (1200 Minutes)) doesn't address zero client firmware based disconnects after 1200 minutes. We have a lot of zero client kiosks running 24/7. Have you figured anything out for preventing the 20 hour max session duration on a Tera1 or 2 device?
I would also like to know if anyone found a fix or work around.
I only have a small pool of 10 Dell wyse P25s that we just deployed about 3 months ago to see how well they would work for us so im still learning the whole View system..
We are also having an issue in our Production environment. We are running Non-Persistant, Floating Assignment, Link Clone Pools and are a 24/7 Shop. We recently upgraded from a 5.3.4 View Environment.
Environment consists of:
View Clients - 4.0.1 Build 3698521
View Agents - 220.127.116.1108800
Connections Servers - 6.2.23508079
Composer Server - 18.104.22.16805505
After the upgrade I noticed that the existing value for "Forcibly disconnect users" was set to 9999999 from the previous version and was outlined in Red as if it was not longer valid. I changed the value to "Never" and am still getting sessions that disconnect after about 20 hours. Not sure what is going on. Curious to know how this was resolved by any of your issues. I have a ticket open with VMware as well.
All you need to do is modify LDAP.
FYI this will only take effect for new sessions (works for thin clients, zero clients, thinOS, etc).
Testing to see if this same fix works on View 7 as we just upgraded and went live today. Works like a champ in View 6.x and drove me crazy until I found the fix.
Will update tomorrow if same fix works in View 7.
We have the same issue here. Dell Wyse P24 and P45 clients.
We are still having this issue ( before ) with View 6.1 and now with View 7
We have done the workaround and set the "Forcibly disconnect users" option to 999999 as suggested by some forums but nothing happens.
Can you please tell me if the LDAP modification you have done, based on :
has corrected the issue with the zero clients in your View 7 infrastructure ?
Thanks in advance for your reply.
Any further updates on this? Specifically if Teradici will be releasing an updated firmware to support this natively without modifying the ADAM database on the Connection Servers?
We are running Horizon 7.0.3 with Tera2 firmware 5.3 and have this issue (without the workarounds 1) ADAM DB 2) Set High Number in VMware global settings applied).
Edit: I did see a note on Teradici's support site that with firmware 5.2/5.2.1 this is reported as an issue. The workaround is to set the VMware global settings value Forcibly Disconnect Users to a high number (from never) but not sure if that works as was indicated in a post above.
As an update, changing the settings under the VMware global settings Forcibly Disconnect Users to a high number as recommended in the Teradici release notes for 5.2.x does not work with our zero clients. Still getting disconnected right at the 20 hour (1200 minute) mark after setting this to 10,080 minutes (7 days).
Looks like the only workaround may be to modify the ADAM DB per the VMware KB article. But that only applies for connections going through the Connection Servers (and not, for example, a Direct Connect Plugin connection as some have mentioned).