Horizon 6 Session Disconnects

[briansparks]

We have production machines that run three shifts seven days a week.  Up until now we have had the forcibly disconnect setting set so that they never disconnect.  After upgrading to Horizon 6 they now disconnect approx. every 20 hours even when set to Never in Global Settings.  Is there a work around that anyone here is aware of?

[Linjo]

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.

// Linjo

[briansparks]

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.

[eeg3]

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."

[Linjo]

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?

// Linjo

[mpryor]

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.

[Bleeder]

Updating clients is not possible in all environments due to another issue:

Horizon View Client (2.3 and 3.0) Silently Dropped Support for 32-Bit Macs? (Core Solo, Core Duo)

[briansparks]

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.

[dasfreund]

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?

[SVTPro]

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..

[BigDigital]

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 - 6.2.2.3508800

Connections Servers - 6.2.23508079

Composer Server - 6.2.2.3505505

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.

[Cael1382]

All you need to do is modify LDAP.

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=20914...

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.

[alejandrovmw]

Hello Cael1382,

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 :

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=20914...

has corrected the issue with the zero clients in your View 7 infrastructure ?

Thanks in advance for your reply.

[RyanChristopher]

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.

[RyanChristopher]

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).

[Ray_handels]

Not taking credit for anything that has been said here, the link referred to and the change in LDAP is the fix.

We have had the exact same issue with P25 TC's (and all-in-ones for that matter) and didn't see the issue with people using the client so we kinda though people were fooling us .

We use the Connection server to set up connection but then directly connect to the VDI itself and bypass the connection server.

This setting works, believe me... Unfortenatelty it does We now have people using a TC and having sessions that surpass the 2 week limit and then some.. Nice when you need to update your pools due to Windows patches..