I have a global session timeout since we use F5 loadbalancers and their persistence record expires after 18 hours. Anyway, I set the session timeout to occur after 930 Minutes... I have multiple sessions open passed 18 hours which aren't disconnecting. Have any idea?
Which version of View are you using? In View 4.6 the only clients that were not disconnecting for me after our timeout was the Linux/Ubuntu client. Once I upgraded to View 5.2 all clients are now disconnecting correctly after the timeout.
I am using 5.1 View. It seems to work for some but most it doesn’t work. I have sessions that are even over a day running.
Are you getting this data by clicking on remote session in the View web console and sorting by duration? I am not 100% sure this time is how long they have been connected but maybe how long they have been logged into their VDI? I have my session timeout set for 16 hours and I have entries that show 1 day 18 hours +.
The Session time listed in the Inventory pages is not the value that the Global Session timeout uses.
The Session time is the total time a session has been active on that particular VM. This essentially means how long a user account has been logged into the Windows OS in the desktop VM.
The Global Session timeout only applies to single client sessions. So if I connect with my iPad and hit a timeout set at 930 minutes then I will disconnect. But if I connect for 600 minutes, disconnect and then immediately reconnect I can stay connected for another 930 minutes.
I can explain further if needed.
That is exactly the explanation we needed Mike. Thanks for the quick reply
I thought that as soon as they authenticate through a connection server the time starts ticking…. So if they reconnect it just reset the time? Maybe I need to look for more an idle clock that sits on the vm that will disconnect their session.
You're correct that the clock starts ticking as soon as you login to the Connection Server but only for the client connection itself. The session on the desktop itself is independent of this clock and is not affected directly.
The setting that you want to use to control this more tightly is the "Automatically logoff after" option in the desktop pool settings. This setting allows you to set various policies based on the type of pool the user is using.
For example, if you have a Floating pool used for task access with no requirement for persistence across sessions on the desktop itself you can set this setting to immediately. As soon as the client disconnects the desktop will be reset. Alternatively you can set the "After..." option to a small period of time, like 5-60 minutes. This allows the user to disconnect for a short period of time, such as a lunch or coffee break but still be able to log back in and continue on with their session, but the desktop will be logged off at the end of the day or into the evening once the session timeout is hit (if they leave the client logged in when thy go home).
Another common scenario is to have the logoff after disconnect option set to something like 17-18 hours. This allows a user to have a persistent session through the week so they get a consistent experience. It also means that each weekend, when the user isn't logging in within 18 hours the desktop will logoff and be released back into the pool.
If you need some amount of persistence but a hard timeout on a Windows session itself this would need to be handled by a 3rd-party utility inside the OS itself.
Hopefully this is helpful!