Hello guys,
I created an RFE for BigFix to create a BigFix Console timeout option to be set through BES Admin (the current timeout options timeoutLockMinutes or loginTimeoutSeconds just times out the session and don’t finish the connection).
Please take a look and help to vote so this can be considered by BigFix dev.
Create a BigFix Console timeout option to be set through BES Admin (current timeout options don't finish the connection)I upvoted it.
[forum padding]
The issue with the current timeout options for the windows console is that they don’t seem to stop the console from communicating with the root server when they are idle for too long.
It would be ideal if consoles that have been idle for X time would pause themselves and not communicate with the root server again until they are no longer idle, or perhaps until the user authenticates again.
This would reduce the load the console puts on the root server DB for operators who are not actually using it.
Would this mean that whenever re-authentication occurs, not only do users have to wait for the re-authentication to occur, but also must now wait longer for the console to catch up with the server? This may be an undesirable change for large customers where freezing consoles are already an issue under normal operation. Perhaps halting communication during re-authentication would be ideal as an optional mode for the console.
even so there should be a way to timeout the session and close the communication finishing the TCP socket. What currently happens today is that the Console even after timeout keeps the TCP socket opened consuming bandwidth between Console and Root server.
It functions this way because the expectation is that the user will re-authenticate and want to continue working, but a random person can’t come along and just deploy actions. Keeping the console up to date regularly would be less impact than having them do it all at the end, unless they are gone for quite a while. For that case, we are adding a feature in Q4 to allow the console to be automatically closed once an inactivity timeout is reached. I think that will address your request (though in a slightly different way).