#CalDAV to #MSExchange calendar migration tool

A quick gut-check from our loyal readers: do you guys want a CalDAV to Microsoft Exchange migration tool?

UPDATE December 2016:  Folks: We did this.

The Cookbook Version of Exchange 2013 Migration Rights

Gentle reader,

No matter what you want to do with calendars server-side in Exchange, you are going to need to become conversant in Exchange permissions.  It's the devil's bargain: if you want to migrate all your calendar data and preserve its utility with guest lists and responses, then you need to be able to manage Permissions on your Exchange users.  

So here we're putting out our best effort at a cookbook guide to Exchange 2013 permissions for migrations.  Even though full-state calendar migrations will never be a purely cookbook operation we think this will get you there (and we have some field experience taking a couple of novices through it this way),

First:  GLOBAL ADMINISTRATOR rights are NOT enough.  These rights give you administration rights over Exchange / Active Directory, but they do not give you the rights to access mailboxes – which is what you will need to move in data and re-create state.

We’re going to take this in stages.

Background. Your ADMINISTRATOR account needs to be able to:

• Use REMOTE POWERSHELL to Log into Office 365
• Create a separate service account (this keeps your ADMIN function separate from your MIGRATION function)
• We call the Service Account EXSU.  When you create it, make sure it is mailbox-enabled (you will be sending email on behalf of this account
• Grant EXSU three rights:
• Impersonation
• No throttling.  This is relevant (i.e., in your control) only for on-premises Exchange.  For Office 365 you will need to contact your Microsoft rep and explain what you are doing and ask throttling turned off for the duration of your migration.
• FULL ACCESS to mailboxes (this makes it easy to use OWA with this account to check the results for individual users in testing and migration)

Execution.  To do this – use the various Exchange PowerShell cmdlets which execute the appropriate actions.

Start POWERSHELL.

REMOTE to your OFFICE365 account

IMPERSONATION: You’re creating a ROLE called “_suImp8” that allows Impersonation and then assigning it to EXSU

THROTTLING: You’re creating a policy called SuThrottling Policy and then assigning it to EXSU.  (Otherwise Exchange 2013 might shut you off mid-migration)

FULL ACCESS:  this grants access to ALL MAILBOXES in your domain to EXSU.

Test.  Can you put the EWS URL in a BROWSER and when prompted for credentials get this?

Log in with your EXSU credentials.
You should see this:

This example shows access to Office 365.  Obviously if you are going into your on-premises or your own hosted domain, your URL and service name will be different.

Now to test FULLACCESS go to the URL box and modify it as I have with a user on your domain:

Hit ENTER

Now you will be prompted for your end user mailbox credentials.   Use the service account (EXSU) and the password to access to the mailbox.  This is where FullAccess comes in – you don’t have to crack all of your end users' passwords!

NOW it should display your test users’ mailboxes in OWA

If all of these are successful, now you can do a test insertion!

Congratulate yourself.  Permissions are historically the worst learning curve in a migration.

Hosted Oracle Beehive to Office 365 Field-Proven

We had an informal bet, Zyg taking the side that Hosted Beehive to Office 365 was not going to work the first time out and Russ figuring that it was.

Russ won. 

Data goes in like a champ in the current version of the Beehive migration code.

Since we're having to go through a proxy server performance is much lower than we see in on-premises migrations -- but that is what multiple instances are for.  Stay tuned for more news.