Hi,
We're having some reports of calendar/appointment oddities from one of our users at the moment. The details are fairly vague, but include:
* one (unfortunately important and almost missed) appointment that 'disappeared', and
* intermittant appointments that are an hour out.
I've re-indexed the user's mailbox (a couple of times over the past month or two) but that doesn't appear to have stopped the reports. We do not have other users reporting similar issues with appointments being an hour out. I am currently trying to get more specific details to try and troubleshoot based on facts, but I'm not 100% certain that it's not a PEBKAC.
In the meantime, I would like to try and discover is the most appropriate way to hunt the issues down through logs, etc.
So far, I've seen INFO level log entries indicating when an appointment is created or removed in mailbox.log - I've also seen that increasing the mailop logging for the user to debug by running 'zmprov aal user@domain zimbra.mailop debug' shows more details, so that if it happens again (as of now, and assuming I don't forget to run it again if I restart the server), I might have more info/evidence.
Is there any other advice that can be offered that might assist when trying to hunting down these kind of vague/random issues? For example, does the SQL db store all the calendar records somewhere in such a way that one can track the history of an appointment, even if it were deleted? (I'd love to be able to search it for the appointment name, find the times it was created, modified and/or removed).
thanks for any assistance that can be offered!
Tracking down calendar 'issues'
Tracking down calendar 'issues'
I have had one employee recently ask about an appointment that disappeared. It was no longer on his calendar, but was still on all of the invitees'.
However, I'm running 5.0.10 so I can't really say if this is still an issue or not. I'm hoping to convince management to let me update more often :)
However, I'm running 5.0.10 so I can't really say if this is still an issue or not. I'm hoping to convince management to let me update more often :)
Tracking down calendar 'issues'
We have had sporadic reports of disappearing events, as well. It's very difficult to get any evidence to report to Zimbra, though. For all we know, these users are accidentally deleting the event from their calendars.
The calendar data is stored in MySQL in the mboxgroup*.appointment and mboxgroup*.mail_item tables if you want to poke around. It seems like deleting an event from your calendar doesn't remove it from MySQL, but I cannot decipher the metadata to determine what makes an event "deleted". I have tried running zmcalchk but it usually hangs after a few events and never recovers.
The calendar data is stored in MySQL in the mboxgroup*.appointment and mboxgroup*.mail_item tables if you want to poke around. It seems like deleting an event from your calendar doesn't remove it from MySQL, but I cannot decipher the metadata to determine what makes an event "deleted". I have tried running zmcalchk but it usually hangs after a few events and never recovers.
Tracking down calendar 'issues'
All,
Sorry to bring up an old thread, but I also have a user report appointments 'disappearing' from the shared calendar.
Other than the mailbox.log, is there a way to easily track appointments on a shared calendar? A possible solution is for emails to be sent out to a user/group when appointments are created/modified/deleted. It would greatly help in auditing.
Any suggestions?
Sorry to bring up an old thread, but I also have a user report appointments 'disappearing' from the shared calendar.
Other than the mailbox.log, is there a way to easily track appointments on a shared calendar? A possible solution is for emails to be sent out to a user/group when appointments are created/modified/deleted. It would greatly help in auditing.
Any suggestions?
Tracking down calendar 'issues'
It won't help in backtracking an existing issue, but you can turn on extra logging for specific users, which apparently will last until the next server restart. We ran the following:
Zimbra Support also suggested we add
From there, it's a matter of waiting until the user in question reports an issue that occurs and hope you can see some information to use (or provide to Zimbra Support).
zmprov aal zimbra.mailop debug
Zimbra Support also suggested we add
zmprov aal zimbra.soap debug
From there, it's a matter of waiting until the user in question reports an issue that occurs and hope you can see some information to use (or provide to Zimbra Support).
Tracking down calendar 'issues'
Thanks to mbd, I have been able to locate an appointment that has disappeared.
Here are the details on the appt from mailbox.log:
It appears that this appointment is a modified instance of a recurring series.
I have confirmed that modified instances are also deleted when the parent series is deleted, but I need to verify the same has happened to this appointment.
From the above, any suggestions on how I should proceed in tracking down this missing appt?
Release 6.0.5_GA_2213.RHEL5_64_20100203001950 CentOS5_64 FOSS edition.
TIA
Here are the details on the appt from mailbox.log:
2010-02-26 12:11:23,701 DEBUG [btpool0-4494://xxxx/service/soap/SearchRequest/SearchRequest] [name=mr@xxxx;aname=lp@xxxx;mid=3;ip=xxx.xxx.xx.xxx;] soap - SOAP response:
{
"Header": {
"context": {
"session": {
"id": "11153",
"_content": "11153"
},
"change": {
"token": 90610,
"acct": "9af45478-9335-422c-93d5-1808664b38fa"
},
"_jsns": "urn:zimbra"
}
},
"Body": {
"SearchResponse": {
"sortBy": "none",
"offset": 0,
"appt": [
{
"or": {
"a": "mr@xxxx",
"url": "mr@xxxx",
"sentBy": "lp@xxxx"
},
"x_uid": "0d3d4285-cb2f-484d-930a-bc72ffdc16d0",
"uid": "0d3d4285-cb2f-484d-930a-bc72ffdc16d0",
"inst": [{
"s": 1268265600000,
"ridZ": "20100311T000000Z",
"ex": true,
"invId": "9af45478-9335-422c-93d5-1808664b38fa:270-6758",
"compNum": 0,
"fr": "2/25/10--1515 NO NOTES DUE TO PRIOR SYSTEM FAILURE.",
"name": "E F C 1500",
"recur": false
}],
"ptst": "AC",
"fb": "B",
"fba": "B",
"transp": "O",
"name": "M, B, C, Other",
"loc": "",
"isOrg": true,
"id": "9af45478-9335-422c-93d5-1808664b38fa:270",
"invId": "9af45478-9335-422c-93d5-1808664b38fa:270-269",
"compNum": 0,
"l": "9af45478-9335-422c-93d5-1808664b38fa:441",
"status": "CONF",
"class": "PUB",
"dur": 7200000,
"recur": true,
"f": "",
"t": "",
"rev": 84793,
"s": 0,
"d": 1264803977000,
"md": 1267139746,
"ms": 90501,
"cm": true,
"score": 1.0,
"sf": ""
},
It appears that this appointment is a modified instance of a recurring series.
I have confirmed that modified instances are also deleted when the parent series is deleted, but I need to verify the same has happened to this appointment.
From the above, any suggestions on how I should proceed in tracking down this missing appt?
Release 6.0.5_GA_2213.RHEL5_64_20100203001950 CentOS5_64 FOSS edition.
TIA
Who is online
Users browsing this forum: Bing [Bot] and 15 guests