Apple iCalendar to Microsoft Exchange Calendar Migration Demonstration

I know we said we'd do a video in January but even if this technology has not been out of our lab yet it's been looking so good that we needed to share it before the end of the year.

Thus: server-to-server Apple iCalendar to Microsoft Exchange,  In this case Microsoft Office 365 but it's really the same thing.



We're reading the Apple PostgreSQL database.  We heard murmurs of Oracle being a secret option in some cases.  Oracle would be no problem.  As a previous posts indicated, we're taking as much functionality as we can and adapting it to the target Microsoft Exchange environment.

You'll see our application running on a Windows 7 virtual machine on the Macintosh desktop.  We found it far easier to use our existing Windows code base than to start anew.

There's a few things we've sloughed off until later (like attachments to meetings / appointments, and contacts) that we just need to bounce some ideas around on.  But it's very functional.

We're working on integrating our migration to Open Directory so it'll be even easier.

Again -- if you have a hundred users, unless you are very convincing on how you're going to be an excellent and loquacious test site, it's just as easy to do a client-side export and import. 

For email always use imapsync.

If you're an enterprise with at least a few hundred users and need to migrate, drop a line.

Can't send mail in Exchange 2016 OWA -- unsent mail in drafts folder

All was well in our Exchange 2016 environment until our recent scheduled server outage in which I applied the latest Microsoft security updates.  Then mail stopped flowing:  all messages ended up in the drafts folder.    When this happened earlier in the year, I restarted the transport services:




# Restart When mail won't flow  (gets stuck on OWA Drafts folder)
Restart-Service MSExchangeTransport
Restart-Service MSExchangeFrontEndTransport




No change.  Looking in the event logs, I see a mountain of red.  That is never a good thing!  I notice event id 3003 -- MS Exchange BackEndRehydration.  The NT Authority\System does not have token serialization permission. 







Something got tightened down or changed.  Our first suspect: permissions. According to Microsoft KB Article 2898571, this is often due to effective deny permissions on the ms-Exch-EPI-Token-Serialization user right on the computer object.  Groups that are DENIED ms-Exch-EPI-Token-Serialization user right are:
* Domain Admins
* Schema Admins
* Enterprise Admins
* Organization Management




Check the group membership via group policy (run this cmdlet:)
gpresult /scope computer /r





UGH!  the computer is now part of the Schema Admins security group.  I removed the computer from that group and everything is fine.




For the sake of completeness, the Exchange computer should be a member of these five groups:

Domain Computers

Exchange Install Domain Servers

Exchange Servers

Exchange Trusted Subsystem

Managed Availability Servers

@Apple #iCalendar Full-State Migration to Microsoft @MSFTExchange / @Office365

Well we got wind of someone large enough wanting to migrate from Apple Mac OS X Server iCalendar into Microsoft Exchange that we went ahead and actually.... you know.... wrote a conversion method.  It's kind of eerie how much Apple's scheduling solution functions almost exactly like Meeting Maker (down to adopting some down-right goofy functionality like the calendar-only inbox for comments and the "first weekend day" of the month recurrence pattern). But that was probably to be expected.

We did this for El Capitan, so it's based on the iCalendar server being in a back end PostgreSQL database.  Making it work with an Oracle back-end would be no problem.  We read directly from the database and still allow user mappings and create live meetings on the Exchange side when we are done.

This is not yet field-hardened so please do not contact us looking to go into production this weekend.  We won't let you make a decision that egregious.

There's also the issue of how we instantiate Travel Time (it goes in as an appointment with a Free-Busy Status of "Out of Facility").  See our previous post.

We've ignored Contacts for the moment.

Some screen shots.

So this on the Macintosh calendar:

Will become this on Microsoft Exchange:

And of course, meetings are really MEETINGS with guest responses.  So on the Macintosh when Jimi invites Jerry to a meeting and Jerry accepts:

migrating this will carry it through to Exchange or Office 365 as a meeting:

Travel Time, a feature not supported by Outlook or Exchange but loved in Apple calendaring we've implemented by inserting appointments with the appropriate durations in advance of calendar events.

So this on Macintosh

becomes this on Exchange:

The sharp-eyed among you will note that this does something different from our previous post -- it kept the name of the "seed" event in the travel time description.  We experiment a lot with these things.  Any preferences?

Keep an eye on this blog for one of our videos showing this in real-time.  Probably after New Year's.  We've got a lot of migrations going on in December.

To give you an idea what the configuration for this looks like:

You're going to need to map resources to SMTP addresses (not a big surprise I hope).  You'll also notice above we set up the capability to read from a different Postgres database which makes it easier to copy your Apple iCalendar database to a more powerful Windows environment for insertion.

Make Google Calendar Stop Automatically Adding Events

From today's New York Times a good question and answer:

How do I make Google Calendar stop automatically adding events mentioned in Gmail?

Certainly it is possible but heed this warning: "Google warns that doing so removes all the past events added from Gmail."

This is totally bush-league!

Google should be ashamed they foisted that kind of slipshod capability on the public.

@Apple OS X iCalendar: “Travel Time” and Migration to @MSFTExchange or @Office365

Spoiler alert: We've been skunk-working a project for migrating Apple iCalendar to Microsoft Exchange and we've come up with a few things we should blog on.

First, read OS X Mavericks: Using “Travel Time” in Calendar.

Travel Time is a very cool feature and I remember sites asking for it when I was on Meeting Maker way back in the prior century.  

Apple implemented it.

The question becomes: what do you do with Travel Time in OS X Server El Capitan when you migrate calendars to Microsoft Exchange?

For appointments, it's very simple: you insert another appointment adjacent to the one with travel time and set it up with a reminder at the time you need to leave.

For meetings you do the same thing -- but as nearly as we can tell Travel Time only applies to the Organizer of the meeting (what Apple refers to as the CHAIR) not the attendees.  This makes it really simple for us, but as always, we put this out in the blogosphere for comments and for power users to say "not so fast!".

So what looks like this on the Macintosh for Janis Joplin:

Will become this on Office 365:

There's a couple of  things here that we're working with:

• Defining the Travel Time Free-Busy status on Exchange as "OOF" or "Away" as Office 365 now refers to it.  Somehow that seems more true to the intended spirit of the feature than "busy."  And "Free" is just right out.
• Since Travel Time is not defined with an actual name in the Apple iCalendar data structures we're going to keep all the times singular.  In English "3 hour travel time" makes more sense than "3 hours travel time."  (Those of a certain age will remember the immortal line: "A 3 hour tour....a 3 hour tour.")
• Reminder will kick off for Travel Time at the start of Travel Time.

One of the clever things about the Macintosh calendar user interface is that in monthly view the travel time does not appear  (heck, maybe it's a bug and no one's fixed it yet and everyone's really complaining about it -- but I think it keeps down on visual clutter).

So here's what a monthly view looks like for this event on the Macintosh:

And here's what it will look like in Office 365.  

A little advance training on your users will do wonders. 

#MDaemon to @Office365 International Migrations - Character Sets Deuxième partie

FOLDER NAMES!

Dagnabbit -- we forgot folder names in UTF-8.

This was one where the file system was replacing the “Tâches“ with “T&AOI-ches”

So we updated the code to handle it,

The latest build,  mCalreader_v4.1.17 addresses this issue.

To be safe, I recommend deleting these four lines in the XML config file and then re-running the code’s setup/configuration if you are already in a migration:

  

NB: Don’t worry if the config values look odd.  We save the localization values in “HTML-Friendly” format, so the “&” becomes “ampersand;”  (except in Blogger it gets interpreted into something not plain text)

For the curious, this is the table so you can handle your own cases:

           

Note that this is also a problem in email migration:  http://www.linux-france.org/prj/imapsync_list/msg01976.html

#MDaemon to #Office365 International Migrations - Character Sets

Let's say that you are happily migrating calendar data from MDaemon to Microsoft Office 365 or Exchange and you're someplace other than the USA with various accented characters.

Most times we've had no problem out of the box with the MDaemon calendar migration (and we see many migrations in Europe).

But one French site reported "é"s (as well as every other accented character) coming out incorrectly.  For example:

This is a classic symptom of the original character set being UTF-8 and that not meshing with the default Windows Western European character set.  Note that the e-acute in "Migré" was inserted under program control as a string already in the Windows character set.

No worries.

Modify the _Config_mCalReader.xml file to contain the following line:

Run your insertion.  It'll come out correctly in Exchange:

What if I forgot my #Oracle BEE_DATA Credentials in a Beehive to #Office365 Migration?

Our Oracle Beehive to Microsoft Exchange migration reads the Oracle database directly, which makes things WAY easier for a migration.

Using the BEE_DATA credentials gives us access to all the data email migration products do not take.

Recently though we had someone who inherited their Beehive installation and did not have their BEE_DATA password.

Yuck!  Normally we do not like to advise things like just changing the password on a running system, since you have no idea what else it affects.  As Buckaroo Banzai advised: "No, no, no, don't tug on that. You never know what it might be attached to." 

This script will create a user called “sumatraTestBeeData” with all the privileges we need.

--------------------------------------------------------------------------------------------------------------------------

--Using SQL*Plus, 

connect sys as sysdba/PASSWORD;

select tablespace_name, status, contents from user_tablespaces where tablespace_name like 'bee_%';

drop user sumatraTestBeeData;

--create user command:

CREATE USER sumatraTestBeeData IDENTIFIED BY PASSWORD  DEFAULT TABLESPACE BEE_DATA TEMPORARY TABLESPACE temp QUOTA UNLIMITED ON users  QUOTA UNLIMITED ON BEE_DATA;

grant sysdba to sumatraTestBeeData;

grant create session to sumatraTestBeeData; 

grant ALL privilege to sumatraTestBeeData;

Grant UNLIMITED TABLESPACE to sumatraTestBeeData;

--sumatraTestBeeData needs access to these three tablespaces:

--BEE_DATA, BEE_LOBS, BEE_INDEX

alter user sumatraTestBeeData quota UNLIMITED on BEE_DATA;

alter user sumatraTestBeeData quota UNLIMITED on BEE_LOBS;

alter user sumatraTestBeeData quota UNLIMITED on BEE_INDEX;

--------------------------------------------------------------------------------------------------------------------------

Then use these Beehive credentials in bCalReader:

Full-state Calendar Migrations from #Oracle, #Zimbra, #MSFTExchange, etc into @Office365

There must be a forest around here somewhere, I just cannot see it through all these trees.

These are Sumatra's full-state calendar migrations into Microsoft Exchange that 

• re-create meetings
• keep recurrence patterns 
• preserve guest responses. 
• book conference rooms and resource
• make it like your users have been using Outlook and Exchange all along. 

• Everyone else who claims to do calendar migrations skips over all this functionality. To be fair, it is hard to execute correctly (and most of them have their hands full convincing you to do email when imapsync does it so well and so much less expensively), and it's not too important if you have a few hundred users. But it is the whole ball of wax if you're any real-sized corporation.

Exchange to Office 365

with Incremental Sync

Oracle Calendar Server to Exchange / Office 365 (via ICS files, which we still use to create live meetings):

Oracle Beehive to Exchange:

MDaemon to Exchange (we don't do full-state on this)

Meeting Maker we've been doing but we didn't do a video on it.  And at this point -- why bother?

Zimbra to Office 365:

Check out Setting the Colour of a calendar using EWS and Powershell in Exchange

Those of you looking for instructions on Setting the Colour of a calendar using EWS and Powershell in Exchange should head over to Glen's Exchange Dev Blog.

Microsoft and Linux: Sign of the End Times?

My amazement is complete.

Read: Microsoft Built Its Own Linux Because Everyone Else Did

Never would'a thunk it.

For Exchange it makes PERFECT sense -- but I would have bet against this ever happening.

Enterprise Calendar Migration @Zimbra to @Office 365 @MSFTExchange

Per request, a video of  migrating calendars from Zimbra into Office 365.

Of course this keeps meetings as genuine, functional, updateable meetings when they are migrated to the Microsoft Exchange side.

We are reading calendar data directly from the Zimbra database, a technique we also use for our full-state Exchange to Exchange migrations and our Oracle Beehive to Exchange migrations.

Microsoft Deprecating the REST API preview endpoint

Microsoft is Deprecating the REST API preview endpoint on October 15.

Now this is the PREVIEW endpoint, not the functionality.

Since we're on something of a roll, we're considering using REST to pull calendar, task, and contact data out of Zimbra at some point.  Our experiments make pulling the data from Zimbra look relatively straight-forward.

Our experiments putting data into Office 365 indicate more trouble and uncertainty than it is worth -- so we're likely to stay with our current methods.

Converting a Meeting Maker server to a relational database

We had someone ask us "Can you guys convert a Meeting Maker server to a relational database?"

Short answer is: Yes - that's how our migration process has always worked.  Raw Meeting Maker data exists in an object-oriented database format that I have described as a cross between a PhD thesis and a junior high school science project. 

Even though we formally ended our MM to Exchange migrations we've been contacted by some Friends of Sumatra who've been through migrations with us before so we've kept our conversion software running.

Time frame: depending on how much history you have and how many users are on your Meeting Maker server we can convert your data into an Microsoft Access database in (at the most) an afternoon.  Usually it's only a few hours but breaking out and spinning up the conversion server is the real hassle.

This converted database alone is insufficient to run a full migration into Exchange.  Do not allow that idea to entertain your mind.

The converted database is completely appropriate for converting / archiving Meeting Maker servers into a standard database format so that you can do searches for legal compliance, history, investigations, or whatever your data-driven needs require.

#Zimbra Email Migration to #Office365 using #imapsync

Today we'll show you how to use imapsync to migrate email from Zimbra to Exchange 2013 / Office 365.  We got some good feedback from our initial post on Zimbra calendar migration to Microsoft Exchange and wanted to add some value on the issue of email migration.  When we did that for MDaemon everyone was very grateful and it led to much calendar migration.

You can license the technology and purchase the support to migrate your email for 100 Euros. Remember this only moves email.  You will have to budget additional funds to move your calendars.  This gives your end users a complete solution -- email and "live" (with guest lists and responses.) Plus, your conference rooms and resources are fully functional when you're done with your migration.  That's what we do at Sumatra.

We found imapsync to be the most  efficient and cost-effective, email migration product.  Just license imapsync and get support at the same time.

Is this imapsync email migration guide exhaustive?  Hell no!  There is no way to document all the "creative" ways user behavior can wreak havoc -- and some of them are going to be downright pathological.  We are aiming for the 80% side or the 80/20 rule here.  You get that much down you can make a good stab at the rest if you find yourself in difficulties. Barring that imapsync is very forgiving and its model of incremental syncing is laudable in its simplicity and effectiveness.

Migrating your email probably also takes you through 80% of what you need in a migration.  If you're happy with that -- glad to be of service.  If you need the calendaring to come over with fully-functional meetings, guest lists, responses, resources, contact Sumatra and we'll set you up with a trial.

Preliminaries

Zimbra has excellent guide on using imapsync with Zimbra.  We would suggest you add a valid non-self-signed certificate to their requirements.  imapsync runs in Linux and Windows (via the Command Prompt.) We'll demonstrate the Command Prompt since Microsoft Exchange / Office 365 is our target system.  Editorial comment: one of the smartest things Microsoft could do is put Exchange on Linux, but it's more likely some weenie there will recommend porting Windows to the iPad first.

Remember before you test,  you will have to enable IMAP in Exchange 2013 and for your end users in Office 365.  See how to do this in our blog post.

Migrating one user Zimbra to Exchange

In the simplest case migrating from Zimbra to Office 365 looks like this for our user Jimi Hendrix (if you use individual passwords for users).

imapsync.exe ^

--host1 sumatra.com --user1 jimi.hendrix@sumatra.com --password1  "XXXX" ^
--host2 outlook.office365.com --user2 ^
jimi.hendrix@sumatra.onmicrosoft.com --password2 "XXXXX"  ^
--ssl2  --sep2 /

If you set up a service account with FullAccess on Office 365, you accomplish a migration without knowing any password except your service account by using a command like this (where password2 is the service account password):

imapsync.exe ^
--host1 zimbra.sumatra.com  ^
--user1 jimi.hendrix@zimbra.sumatra.com --password1 "XXXX" ^
--host2 outlook.office365.com --port2 993 --sep2 / ^
--user2 jimi.hendrix@sumatra.onmicrosoft.com ^ 
--authuser2 SERVICE_ACCT@sumatra.onmicrosoft.com ^
--password2 "XXXXX"  --ssl2

Note in  the above, for an Office 365 target system we need to use the "--sep2 /" command. 

Confused about Exchange permissions and setting up your service account?  Read our post The Cookbook Version of Exchange 2013 Migration Rights.

If you want to use a Service Account on Zimbra as well, similar syntax should work using either the "admin" or "zimbra" account.

Note also that this gives you the direct capability to map your user ID, for instance from "jimi.hendrix" on your legacy system to "jhendrix1967"  or "jimi.hendrix1967" on your target system.

Iterating over a user list

In any event you are going to need to generate a user list to migrate email.  Can you keep your migrating user list separate from your migration script?  Answer: YES. This method assumes your legacy ID is the same as your target ID, but allowing for this to change is not a hard extension.

The imapsync ZIP file contains a script for iterating on a user list:

sync_loop_windows.bat

Which also contains an excellent primer on running imapsync in parallel.  

This batch file assumes a text file in the form "User1;Password1;User2;Password2;..."

Zimbra's Guide to imapsync includes a couple of batch processing script examples.

To get  a user list from Zimbra you can use either zmprov (this gets a list of accounts without passwords, so use a Zimbra admin account to get data, and please edit out the spam, A-V, etc. IDs): 

cd /opt/zimbra/bin  

and 
sudo ./zmprov -l gaa >~/accounts.txt

You could also use ldapsearch if you already have scripts for that. 

It has been said that the "death is in the details."  We say, "success is set in the details."

Now come the details

Throttling in Exchange/Office 365: Your Migration Nemesis

Note that I did not write "enemy."   You're more likely to be throttled in Office 365 since the controls to that environment are largely out of your hands.

As per our usual mantra: test everything before you go into production.  

If you get throttled, there are two imapsync switches you can tweak.

One limits the transfer rate to a specific number of messages:  
--maxmessagespersecond

Start at 10 (say) and work up or down from there.  In calendar migrations we start with 25, but our gut experience tells us calendar data is smaller per object on average.

The other limits the transfer rate by byte if that works better for your network environment.

--maxbytespersecond

You can also check out our post Throttling in Exchange 2013.

Really helpful options

• --buffersize 8192000  imapsync has a default I/O buffer of 4 Kb.  Upping this to 8 Mb will probably speed things for you
• --syncinternaldates: some email systems misuse email dates and you therefore run the risk of the receipt dates on your target system (what imapsync refers to as host2) becoming the date of insertion.  This command avoids that unfortunate event. 
• --fast:  this prevents flags from being synced and therefore makes the process (wait for it....) faster.  Not an option to invoke if you want / need to sync flags! 
• --dry:  this is a really useful option for development and debugging,  It just goes through the motions of logging onto both source and target system and displays the status -- a dry run.  Use this or debugging options -debug and -debugimap

Other idiosyncrasies

The imapsync FAQ recommends these additional settings when migrating from Zimbra.

imapsync ... ^
--exclude "Conversation Action Settings" ^
--exclude "Quick Step Settings" ^
--exclude "News Feed"

Although we have not seen those folders in Zimbra in a while, your implementation could be different.

Sent, Junk, and Trash

However, there are differences in Folder names between the two environments that may be relevant to you.  Specifically what Zimbra calls "Sent, Junk, Trash" Office 365 calls "Sent Items, Junk E-Mail, Deleted Items" as seen in this side-by-side comparison.

To successfully migrate these folders, use this command sequence to map the folders: (see Zimbra Documentation):

--regextrans2 's/Sent$/Sent Items/'
--regextrans2 's/Junk$/Junk E-Mail/'

--regextrans2 's/Trash$/Deleted Items/'

Notice how we lined these up so it would be easy to repeat if you needed this for other systems, or different language packs.  These being regular expressions you could also take several related folders and migrate them into a single one on the Office 365 side, but I leave that to your wits and imagination.  If you do find something that works, let us know -- we'll update this post (of course, crediting you!)

Exchange IMAP Prerequisites

Did you configure IMAP?  If not, see how in our blog post:

On the Zimbra side:
Make sure you are enabled for IMAP access. 

Check "Enable clear text login" for the IMAP service via "Global Settings" or under "Servers" under IMAP in the Zimbra Administration Console.

If you need to install Perl modules, this is an excellent tutorial on how to do so.

Sample Scripts

These sample scripts for major migrations / multiple users will help you out a lot.

http://imapsync.lamiral.info/examples/sync_loop_windows.bat

http://imapsync.lamiral.info/examples/file.txt

Final word on really considering what you need in Zimbra migrations Diatribe: Migrating email is about moving tonnage.  Migrating calendars is about preserving responses, recurrences, and resources.

But a full migration methodology has to include more than just moving this data. We have a comprehensive suite of scripts and tools so that before any email or calendars are migrated we take care of:

• Reading the Zimbra user list (and passwords)
• Provisioning users in Exchange
• Re-configuring Outlook to point to your Exchange server and removing the Zimbra Outlook connector. (Note: there are publicly available scripts but we wrote our own after we found they did not work.)
• Pre- and Post-cut over scripting so that legacy emails are moved to the target system, and new emails redirected to the target system.

If you have a few dozen users, it's difficult to make an automated process cost-effective and you might as well do it on your own one at a time.  You can export PSTs or export files from Zimbra, then import those PSTs into Exchange.  Tedious and time-consuming, yes, but free.

If you are a larger site with the need to preserve your meeting guest lists, recurrences, responses, and resources post-migration feel free to contact Sumatra.

Quick guide to Enabling IMAP in @Office365 / #MSFTExchange 2013

Let's say you're going to want to start migrating email from a legacy system like Zimbra into Exchange 2013 or Office 365.  You're going to need to get IMAP running on either your on-prem Exchange environment or in O365.

This tells you how to do it.

In a few days we'll show you how to start moving your Zimbra email.  Why are we picking on Zimbra?  We're not, we're responding to market demand to move Zimbra (which is not hard to see since Exchange continues to improve linearly and Zimbra has developed in fits and starts from being independent to being a quizzical part of Yahoo to being remaindered to VMware to passed off to Telligent and now just sold to Synacor). 

There are three pieces to get IMAP working:

1. Start the IMAP service (Exchange 2013.)  Office 365 can skip this step
2. Enable the IMAP Connector
3. Enable the IMAP mailbox feature for user accounts

Start the IMAP Service

The first step is to start IMAP on your Exchange 2013 server (see below).  Once set, you can then enable the IMAP mailbox feature for each user.  (Office 365 customers can skip this step.)  These are the four shell commands:

Set-service msExchangeIMAP4 -startuptype automatic
Set-service msExchangeIMAP4BE -startuptype automatic
Start-service msExchangeIMAP4
Start-service msExchangeIMAP4BE

Step 1: Start two IMAP4 services (and configure those services to automatically start if you wish.)

By default, in Exchange 2013 the IMAP4 service(s) are stopped:

To start those services: On the computer running the Client Access server role:

1. Set the IMAP4 service to automatically start:

     Set-service msExchangeIMAP4 -startuptype automatic

2. Start the Microsoft Exchange IMAP4 service.

     Start-service msExchangeIMAP4

On the computer running the Mailbox server role:

1. Set the Microsoft Exchange IMAP4 Backend service to start automatically.

     Set-service msExchangeIMAP4BE -startuptype automatic

2. Start the Microsoft Exchange IMAP4 Backend service.

             Start-service msExchangeIMAP4BE

In our case, the CAS and Mailbox server roles are on the same box:

Configure Exchange IMAP4 External Connection

This allows users to see (and thus use) the IMAP server.  Here is how via the powershell SET-IMAPSettings cmdlet, e.g.:

     Set-ImapSettings -ExternalConnectionSetting {:993:SSL}.

Note: This requires you restart IIS.

This is true even if you are working within the firewall  Thus in our case, the External Connection is the same as the InternalConnection.

Finally,  Verify things are working, using OWA’s Options select Account, then pick the “Settings for POP or IMAP access” link.

For more information see: http://technet.microsoft.com/en-us/library/bb124489(v=exchg.150).aspx

Enable IMAP for your users
Next, ensure your user mailboxes are enabled for IMAP.
You can do this one-user-at-a-time using the Exchange Admin Center (EAC):

Or via Remote PowerShell for Office 365:

 Set-CASMailbox jimi@sumatra.onmicrosoft.com -MAPIEnabled $True

Which can be set for all users by piping from Get-Mailbox (note that this correctly excludes resource accounts for email migration):

Get-Mailbox -resultsize unlimited ^
  -filter {isResource -eq $false} | set-CASmailbox ^
  -MAPIEnabled $True

You know you are a calendar geek when....

You know you are a calendar geek when you go to the Museum of Modern Art and on seeing this painting:

your first thought is "Out of Facility."  

I'm pretty sure that is not the reaction Ruscha intended.

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