The user sessions table was made hard delete for performance reasons I think. The very issue you raise was one that has been raised before, but I'm not sure what LANDesks best practise alternative is at the moment to provide what was standard functionality. I did pencil in a workaround which was to use the new features in 7.4 and 7.5 to be able to create an entry in an integration table each time an object was created. This is currently used in LANDesk to allow request processes to pass out parameters to an external application, such as the LANDesk Management Suite and is nicely described in the manuals.
Although there are big warnings against using the facility on objects which are updated too often, it did strike me as a away of retaining when a user sessions table was created and (from memory) deleted.
Triggers might be another alternative to stash the contents of user sessions somewhere safe and arrange to delete them every so often.
I don't think MI in 7.5 would help because it only runs once a day to collect the stats.
As I say it was just something I played around with when the change in functionality kicked in. Ideally a LANDesk article might appear with a better way [Hint to LANDesk!]
We are adding more analysts to service desk a 3rd time, and managing who is fixed vs concurrent obviously depends on how much the analyst has web desk open during the day. I have a query which shows active user sessions, which is great.
But, history would be really nice. When you say triggers, I assume you mean a trigger in SQL to dump the user sessions table elsewhere everytime it's updated?
Has anyone done this? And has anyone seen any issues result? Thanks.
I would assume trigger is a SQL trigger, it's the only thing that makes sense.
My DBA is always harping on me about using triggers. Their the easy button but they also add overhead to everything you do and your forget about them.
What I have done is enable event manager settings on the user session table on create and delete events. So when LDSD creates a session (login) and deletes when they logout. This gives you a legit method of recording when someone logged in and when they logged out. You can then use this as a source for quite accurate reporting data for user sessions.
Note I don't think you need to be licensed for event manager to generate this list of data, but you'd need to check and also keep the table of records generated under control.