View 4.5 session timeout ignored, sometimes

[AllanMarcus]

We are using View 4.5. Our session timeout is set for 600 minutes. Some users get disconnected exactly 10 hours after they log in. Some users have been connected for over a day!

So, my simple question is how can this be? If the session timeout is set for 10 hours, how can multiple users be connected for over a day?

Thanks,

Allan

[Linjo]

I am not 100% sure how its counted but I think its per session, so if the user disconnects during lunch and connects again after lunch then he/she will have another 600 minutes.

Do you get this information from the View Admin console or from the users?

// Linjo

[AllanMarcus]

I get the info from the View console.

We use non-persistent linked clones, so if the user logged out and back in again, he would get a new session. If he was simply disconnected, then we would be in the same session.

What's odd is that this only happens to a few people, and not the same people each time. Very odd.

[mittim12]

I always thought a disconnect and reconnect constitutes a new session as well.    I know if I do stay logged in and I hit my session limit it simply puts my desktop in a disconnected state.

[AllanMarcus]

looks like I will have to open a ticket with support to find out.

[mpryor]

The time shown in the View admin UI console is since the initial login, if the user is disconnected at session timeout and reconnects again the time shown for the session length won't be reset to zero.

[AllanMarcus]

The odd think is that for most of our users, when they go home at night and do not log off, when they come in in the morning, they are logged off and must do a full log in. For a few users when they go home at night and return in the morning, their Windows screen is locked and they only have to unlock the screen.

This is an int he same pool of non-persistent linked clones.

Our confusion is why some users are logged off at the Mac session time, but others are not.

[mpryor]

Oh I see, the client is still connected. Possible that you're hitting the bug mentioned in the 4.6 release notes? Not the stuck in logoff_in_progress obviously, but you should see whether the "preventing [...]" log message is on your desktops.

Using View Administrator to log a connected end user out of a View desktop sometimes failed. The log message "Preventing the View Client's 'Disconnect and logoff' option, because the username/password or PIN dialog is being shown" would be generated by the agent on the affected virtual machine. Disconnecting and reconnecting with the same end user would fail with a LOGOFF_IN_PROGRESS error until the session was truly logged out, either by using direct RDP or a vSphere console or by rebooting the virtual machine.