Local Failure Notice

[woo]

Hi,

I'm an IT consultant for a company who uses Zimbra 5.0.15. A user is receiving local failure notices; a sample can be seen below. Granted, I'm not very experienced in analyzing the logs so maybe someone can help me out. She is using ZimbraOlkConnector-5.0.15_GA_2850_5.0.2931.15

Local Failures were detected. No action is required.
This e-mail was generated for technical support purposes.

Sync Type: Delta Sync

Sync Token (before request): 30491

Sync Token (most current): 30507

Store: Zimbra - Mendel

Computer Name: SUELAPTOP

Version: 5.0.2931.15

Error IDs:
id (5103) type(appointment) message([Subject: Updated: DISCERN Team
Meeting]
[Details: could not find occurrence for this date(TZID=Pacific Time (US &
Canada):20090720T130000 Main appt time zone: Pacific Time (US &
Canada))ERROR - Problem processing an exception. Inconsistencies may
result
])


I have 4 attachments that I would be able to privately send:

obj_mime_5103.txt (7.5 kB)
obj_request_5103.xml (0.6 kB)
obj_response_5103.xml (19.7 kB)
sync_response.xml (0.9 kB)

If anyone can help point me in the right direction, I'd really appreciate it. Thanks in advance.

[fsiegel]

Outlook sometimes gets local failures (especially on calendar appointments) when it can't process some data. We don't want to sync these appointments, because they are bad in the first place, and syncing them generally makes things worse. A lot of times, this is the result of bad migration data. Sometimes it's a bug on our part, but in cases like this, it's usually bad data. We've fixed a lot of these -- it's possible we're causing the bad data, but not likely.

In this case, Outlook is getting an error because there is a recurring appointment that has a recurring id that is unable to be found. The date of the recurrence is 7/20/09. Probably 7/20/09 isn't a date that is addressed by the rule. For example, maybe the rule said Every Wednesday, and 7/20 is on a Monday, so Outlook wouldn't be able to find the rule. Or maybe the first occurrence isn't until 7/25, etc.

To find this out, the file to look at out of the four would be obj_mime_5103.txt. In here, there will be an RRULE which should tell you the recurrence rule (or if you synced from the web client, you can just look at the recurrence rule by drilling down on the offending appointment). [Make sure you're not looking at the RRULE in the TIMEZONE struct.] You can also send that file, but you should be able to tell what is going on just by looking at the rule.

I notice that you're using 5.0.15. We have fixed (basically coded around) some local failures since then, like an appointment where the bad recurrence id is before the first occurrence, out of order occurrences, etc.

So you can try a later version and see if it goes away, post that file, or take a look yourself. If this is too confusing, just send the file. Also, it would help if you happened to remember anything about the history of the appointment.