Tuesday, August 25, 2015

#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.

Thursday, August 20, 2015

#zimbra client-side vs server-side calendar ICS exports for @MSFTExchange migration

Gotta give props to the guys at Zimbra.

Usually when there's client-side export method and a server-side export method, the results are different.

Here, exporting calendars as ICS gives exactly the same result regardless of doing it client-side (via Preferences-Import/Export)

Or server-side via zmmailbox

And here's the proof.  But stay tuned next week for some additional consequences of different clients on the Zimbra calendar and what it means for migrating calendars in a scheduling-centric enterprise.


Tuesday, August 18, 2015

#Oracle Calendar Server migration to #MSFTExchange: Users OUTSIDE your organization

Got this question in:
What do the partial and full Oracle calendar server migration options do with meeting invitations to guests outside the organization? 

Gentle reader of calendar migration-mindedness:

Re-sending proposals to users outside your domain is OPTIONAL, as below in yellow.

In general – this is confusing as heck to outside users, since they’ve already responded to an invitation and you probably do not keep them all informed about your migration plans. Your internal users KNOW a migration is going on (well, most of them, let's be realistic). But you have ZERO control over users outside your domain.

In general we recommend you NOT re-send them (though we've had one or two that demanded it).

We insert the address in the agenda, so it’s straightforward to keep track of these and add them post-migration if a meeting updates (which is the real issue)

Your call, but I’d treat it as a training and post-migration issue.

Thursday, August 13, 2015

@Zimbra Enterprise Calendar Migration to @MSFTExchange Options

So we have one enterprise site that is serious about migrating calendars from Zimbra to Exchange 2013.

Again, we're talking full-state, live meeting migration we do, not the semi-functional, "well it's a calendar, so what if the meeting changes don't update now?" that some folks settle for.

This has caused us to look at our migration methods for large-scale Zimbra to Exchange calendar / tasks / contact migration.  We've got a long-standing weirdness.

In Zimbra an attendee can DECLINE a recurring meeting and ACCEPT a single instance.

This is NOT allowed in Exchange.  You decline a recurring meeting in Exchange and it is gone.

So what we've done in the past is have the attendee accept the series and decline all but that one instance.

We're re-thinking this and might just make the single acceptance a one-time meeting with appropriate modifications on the master recurrence pattern exceptions.

Strong feelings about this?  Let us have your feedback.

Tuesday, August 11, 2015

Au revoir #MSFTExchange PST

Our love/hate relationship with PSTs is well-documented in our postings.

It is therefore with an odd sense of both elation and dread that we see Redmond itself advocating Deep Sixing PST Files !

Elation is obvious. Dread because.... what proprietary data format horror will they come up with next?

Still, a good read with excellent references for how to handle your transition.

Thursday, August 06, 2015

Windows 10 and Calendar / Contact Privacy

For those of you who have upgraded to Windows 10 (and if you had Windows 8 this was a no-brainer), you HAVE to read:  Windows 10 is spying on almost everything you do – here’s how to opt out and Windows 10 defaults to keylogging, harvesting browser history, purchases, and covert listening and Digging into and Understanding Windows 10’s Privacy Settings

The most sober reading I've seen comes from Lifehacker.

Now since we're calendar geeks, we're going to show you how to keep your calendar and contacts private, which should be the default in the first place, but is not.

You do not have many choices in your Calendar.  If you want to use Cortona to set your appointments, it needs to check your calendar.  If you are worried Cortona is a nosy rhymes-with-witch who is ratting you out at every opportunity, then turn this off.

You have more choices in your Contacts -- but what "App connector" and "Windows Shell Experience" are is 1.) unclear 2.) why these are options for contacts but not calendar and 3.) WTF?  Microsoft support ducks the question not only about what they are but why they need specific access.

Short answer: beats the heck out of me -- but I dialed my privacy settings to the max.

My main previously unanswered question:  I'm happy with Windows 7 on my desktop.  How do I get rid of the Microsoft annoyanceware in my lower left hand corner?


Click that nearly invisible "Up" triangle:

Then select: GWX "Hide icon and notifications"
Yeah!  I get to keep Windows 7!!!!!  And NOT be badgered about it!!!!!!

Our conversion server for Meeting Maker to Exchange still runs Windows XP.  I needed to take the darned thing off the network to make sure Microsoft / Java / Whoever didn't "improve" it by making it unusable with an automatic update.

Tuesday, August 04, 2015

Mitigating bad user behavior during an #Oracle calendar migration

Got this from the field a few weeks back:
What if we set up inbox rules on each migrating account to redirect invites and responses to some other (non-INBOX) folder - would oCalReader still be able to find them when it comes time for it to respond and clean up responses?

Please do not do this.
Since Exchange delivers the invites to the root mailbox we look at the root mailbox.
Any other folder is strictly verboten.

But -- what you can do:
  • Disable Outlook access for the migration period.
  • Hide the conference rooms in the GAL (stops a preemptive land rush from users -- this HAS happened)
  • Shut off ActiveSync/BES (handhelds are actually a bigger problem than Outlook)
  • Tell your users we know who's been naughty or nice from the logs