#Zimbra calendar behavior with different clients: what it means for enterprise @MSFTExchange migration.

There are a few acid cases we always look for in calendar migrations.

Welcome to one of them.  Well actually three of them all at once.

We are looking at these cases of course because we are revising our full-state calendar migration from Zimbra to Microsoft Exchange, but this will also be interesting to people who wonder why their different clients can sometimes give different results when looking at the same calendar data.

Let's say Jimi Hendrix invites Janis Joplin to a recurring meeting let's say we create it on Saturday November 14 and set it for recurrence every weekday for 5 instances.  Let's also say Janis declines the series and accepts ONE instance  (on the problematic nature of this capability see our previous post).  

Now, for the FIRST weirdness.

Jimi's calendar in Zimbra using the web client looks like this:

The recurrence pattern states every weekday, but the seed instance is on a weekend day.  The Zimbra web client lets you do this perfectly fine, and data is data, so there we are.

But if we open up Jimi's exact same calendar on the exact same Zimbra server in Outlook configured for Zimbra we see something different:

A few things to notice here:  Jimi's recurrence pattern now starts on the MONDAY, which is the next instance of a weekday and continues for 5 instances. The same thing happens with a similar "wrong" seed date "Every other Tuesday" which Outlook now interprets do be on the wrong Tuesday.  Opening up the SERIES shows this:

Which is a total brain-fluck  (note spelling those of you easily offended). 

If we look at Janis's calendar in Zimbra web client and overlay Jimi's, her declines are correct and her acceptance is in the correct spot.

BUT if we take her ICS file and just look at it in Outlook (without importing it though that does not make a difference), then we see data consistent with Jimi's calendar, except that Janis looks as though she's ACCEPTED all instances (they all in fact have BUSY Free/Busy status).

Keep in mind -- we do not deny these are some weird cases.  They are also weird cases that are really easy to create and propagate and we know they exist in actual customer data.

So the question becomes: in an enterprise Zimbra calendar migration which data interpretation do we take as definitive? Even if you're doing it yourself via PSTs (for gosh sake do not use PSTs, keep an eye on this blog for your better alternative) or export files you need to be aware of the issue.

We started doing full-state calendar migrations into Zimbra a few years ago, but interest has risen in the past few weeks from some larger sites and we’ve determined there are two paths we could follow:

Option 1  is reading the Zimbra database directly and then inserting into a database exactly like the one we used for Meeting Maker migrations.  It’s a little more complicated for admins since they need to map users in database tables.  This is well-suited to a big-bang all-in migration.

Option 2  is exporting Zimbra ICS files and using our tools to insert then and re-create meetings.  This simpler to implement and execute but it will probably take longer to run the process end-to-end.  This is also easier to run in segmented bunches of users rather than as a big-bang migration.  But it will also result in the kinds of behavior you see above.

Both of these options yield the result as though users had been on Microsoft Exchange or Office 365 all along: meetings will immediately be live and updateable including resources.  Nobody else does this with calendars.

Internally we all have strong opinions about the path we’d prefer to take, but we’d rather hear more feedback from the guys who’ll have to live with it.

Drop us a line if you have strong opinions on the matter.  In the meantime we're proceeding with Option 1 (though not taking it to the limits we can) because it's just so much less work on the customer side even though it is considerably more work on ours.