Zimbra

Jbrabander · #1 (**permalink**) 01-06-2009, 02:30 PM

I've run into an odd one that I just can't figure out. Sometimes I don't always hear if someone's left the company, so I look at last login time in the Admin UI to see who hasn't checked mail in a while. But sometimes the last login time seems to be off. For example, I've got a user who's last login time shows as 12/29. But, if you look at her inbox, messages from the last couple days show as read.

Any thoughts?

mmorse · #2 (**permalink**) 01-06-2009, 03:13 PM

The server will update the user's zimbraLastLogonTimestamp attribute at most once every zimbraLastLogonTimestampFrequency.
Default is 7d to cutdown on ldap writes every time you auth. You can set it to values like: 1d, 1h, 1m, 1s, or 0 for disabled:

Code:

zmprov mcf zimbraLastLogonTimestampFrequency 3d

Think of the pure volume of some systems, updating an attribute for several million active users all day long makes for a lot of writes and replication. Prompted implementation of: Bug 18972 - provide way to completely disable zimbraLastLogonTimestamp (setting to 0).

Your /opt/zimbra/log/audit.log is continuous anyways so you can always check that. There is a MYSQL database entry in zimbra.mailbox for last_soap_access (getLastSoapAccessTime) not ported to a LDAP value because that would be nuts.

For some, 7 days does seem a little high though given the average installation size and faster systems. To that end, someone had an bugzilla entry in to get the default changed from 7d > 3d but I don't know what happened to it. If you have the time/ability for a large scale performance test go for it.

Some others:
Bug 19670 - record last login timestamp in the db
Bug 18765 - Last user access (not logon)

Jbrabander · #3 (**permalink**) 01-06-2009, 03:25 PM

I may try that. We've only got about 160 licenses is use (counting of course all the built in accounts). So I don't think going down to 3 days will hurt anything on our system.