Tuesday, June 23, 2015

Manifesto for Calendar Server Migration

What are the current gaps in calendaring migration?

Calendaring is fundamentally different from email even though it usually uses it as a transport protocol.

Historically all migration solutions have focused on email.  Not surprising since email is a mission-critical concern.

But where email is static once you have sent or received it, calendars have a crucial difference:  they contain evolving meetings that are linked to the calendars of other individuals in the enterprise.  In Exchange changing a meeting updates the calendars of attending resources and individuals.

And in a real migration you need to take these links and the data associated with them along or you’re only doing part of the job.

Nobody except Sumatra Development does this for calendaring.

Solutions other than Sumatra's treat calendars exactly like email:  they create the events but do NOT recreate live meetings because they ignore the guest lists, responses, recurrence patterns and resource  bookings.

Think if it like this: they take a print-out of a calendar and migrate that. We call this a “flat” migration. Most do not even take recurrence patterns. 

Sumatra re-creates the state, creating live meetings with guest lists (which you might have to map to new domains or addresses), responses, recurrence patterns, exceptions, and resource bookings.

We call this “full-state.”

Even in the on-premises Exchange to Office 365 world, Microsoft focuses on email and does not even offer a calendar migration path.  So we went out and blazed our own full-state migration method.

For small sites this is a tractable (if unpleasant) problem. It's still a productivity loss, but we’re talking a couple of hundred users.

For sites of 500 or more users the productivity hit can be immense.

Put another way:  after a full-state Sumatra migration the user and resource calendar data experience a seamless transition:  as though the enterprise had been using their new calendaring system all along.  With other solutions users actually need to find and recreate their meetings to make them live and update-able.

Finally, other solutions willfully ignore the possibility of failure.

We have an UNDO strategy to gracefully remove only the data we put in in in the event of catastrophe.  (We have seen servers fail in the middle of migration).

This is of course an overview from jet plane altitude and by the time we get through the first test phase with a client we’ve brought them to tree-top level.

Our web site: http://www.sumatra.com

It shows how our migrations work, and it also highlights some of the things
we’ve done in calendaring.

In a nutshell: if it involved MS Exchange calendaring / scheduling we can do it.

Thursday, June 18, 2015

On-premises @MSFTExchange Migration to #Office365

A PowerPoint Presentation about migrating from on-premises Exchange to Office 365.

The Migration section does not specifically call out calendar migration -- but that's what we specialize in.

Towards the end the notion of a back-out plan is one of the main things we constantly harp on.  Our calendar migration can take Exchange to Office 365 preserving guest lists, responses, and recurrence patterns, and do it in BOTH directions and it includes an UNDO to selectively remove only the data inserted.

Tuesday, June 16, 2015

Microsoft Exchange Virtual Machines and your Calendar Migration Test Environment

These days everybody's doing migration testing in their virtual environments.  That's cool with us.

You should start your project by reading Best Practices for Virtualizing and Managing Exchange 2013.  It's a little dense and abstract.

But we also have a few Cliff's Notes (which is a trademark of somebody other than us which we use here metaphorically) to put in front of you for the calendar migration you are testing:

  • Space consumption is a constant battle. To sway the odds in your favor we recommend:
  • DNS vs Firewall. You want to get mail to flow locally, but not leave the testing sandbox.  This is always tricky and you should make sure you've got it right before you go to any appreciable scale with your testing.
  • Keep your Active Directory on a separate Virtual Machine from your Exchange components.  Why?
    • The Exchange VM already has enough to do – don’t add another function to its workload
    • Next, a separate VM for AD should mimic your production architecture. It allows different administrators to manage discrete roles. You might as well start by following best practices.

Keep in mind, these are guidelines for your testing phase to make sure you do not run out of space in defined and constrained virtual environments.  You will want to adopt other behavior when you move to production.

Further good reading:

Thursday, June 11, 2015

Move mailboxes between on-premises and Exchange Online organizations in 2013 hybrid deployments


Do any of you have field experience with:

Move mailboxes between on-premises and Exchange Online organizations in 2013 hybrid deployments


We'd really be interested in the field stories of SPEED, RELIABILITY, and ISSUES.

You do not need to identify yourselves or even put it in the comments, we'd appreciate your confidential experiences via our contact page.

Closely related to this is Single sign-on with hybrid deployments.

Tuesday, June 09, 2015

Mapping Resource Names in Oracle Calendar Server to Microsoft Exchange Migration.

In Oracle Calendar Server, resources are database objects.

In Microsoft Exchange they are SMTP addresses with calendars.

So, while your export file names for Users should match the target SMTP address. the resource mapping file will actually map the ICS file name to the SMTP address.

For example, the export file:

             erp conference room 1 tiger.ics  

gets mapped to cr_colonial_222@YOURDOMAIN.COM


Side note: If you have parentheses in your Oracle Calendar Server resource name, for example:

                     ERP Conference Room 1 (Tiger)

Drop the parentheses or other nin-permitted characters and use the same mapping.

You will get results like this:

I.e., you will have the mapped resource as an Attendee, and the old resource name as the location (because in the source data it's just a text string we insert).

Tuesday, June 02, 2015

Follow-up to #CalDAV to #MSFTExchange calendar migration tool - round 2

If you have read #CalDAV to #MSFTExchange calendar migration tool - round 2 and said "all very well and good, but I want to LEAVE Microsoft Exchange for some other calendar server" -- WE CAN DO THAT.

We  can already read calendar data directly from the Exchange server and insert it full-state into another Exchange Server or Office 365, as you see here:

Taking all the data out of the source is (for us) simple, inserting it into another target is certainly within our expertise.

If you have at least 1000 users or a realistic budget we can discuss this.