ConsoleWorks browser sessions are timing out
From TDiWiki
Clyde Poole, Director of Professional services responded quite well to this question raised by one of our customers.
Clyde,
I’ve noticed since moving to the new ConsoleWorks Instances that I and other SAs are being auto-logged out, and/or our sessions are rendered expired after some time. I found 2 settings that may correct this, however I have a question about the difference between the 2. I assume the “Inactivity Timer” is the main one I want to increase from 30 minutes to something larger to stop the short-lived sessions. What, however, is the “Retention Timer”? It too is currently set to 30 minutes, but it caps out at 240 minutes instead of 1440 like the “Inactivity Timer”. Can you please define these and explain the differences for me?
Thanks!
CR
---
CR;
The “Inactivity Timer” is for user session credentials. After logging in, if ConsoleWorks does not see activity on the connection from your web browser or CWterm connection within the specified time, your credentials will expire and you will need to log in again. This is a security feature to discourage leaving a ConsoleWorks session “laying around”. Also, Just so you know, if you have NAT between your desk top machines and the ConsoleWorks server, NAT address assignment time outs will often cause similar behavior. ConsoleWorks views the change in IP address “source” caused by the NAT address reassignment as a change in session. The same thing will happen with short time outs on DHCP address assignments where a renewal gets you a different address. This case is rather rare.
The “Retention Timer” is the time AFTER the session credentials expire or you log out, that a trace of your session is left in the “Users>Sessions” window. I think of it as “bread crumbs” that stay around for diagnostic purposes. There typically is no reason to make this time out very large.
You might look to see what the “Inactivity Timer” is set to on the old invocations and use it as guidance. Personally, I think it is a security risk to make the timeout very long.
In the future, you should probably send requests like this one directly to support@tditechnologies.com. That way your information request is logged and you are assured of a response even when I am not available.
Clyde
