Wednesday, July 16, 2014

Lessons learned with a migration to Office 365

Today we are going to write about Office 365 and the recent migration of one of our clients.


  • The client want to migrate their mailboxes from on premise Exchange servers to Office 365
  • The client requieres password synchronisation (just an active directory sync, not federation or SSO)
  • The client has Exchange 2003 and Office 2007
  • The Exchange 2003 in our client's implementation is not standard
  • The client wants a gradual migration to have time window to deploy Office 2013 on their computers in multiple stages.

For this migration, we decided to do an IMAP migration, the main reason to do it, was the bad implementation of Exchange 2003, which didn't allow us to use an alternative method like cutover.
Here are multiple migration methods

We decided to do an Office 365 outbound connector between the on premise server and Office 365. It allows us to route the mail between Office 365 and on premise. So we can point the DNS records to Office 365 servers instead of on premise servers. If you do it and you do not create the email account on the Office 365 servers, the email is going to be forwarded to on premise servers. It can allow you to do a migration step by step, for example you can migrate a few hundred accounts to Office 365 and still have another hundreds working on premise.  Here is a graphic which illustrates how it works.

You can find some info about the outbound connector here:

Lessons learned:

First lesson:
Password sync error, we were running the directory sync tool in its 64 bits version on Windows 2008 SP1, it "works", it creates the accounts, but it doesn't sync the passwords. Just 32 bit version sync the passwords and this version is not longer available. We noticed this error when we saw in the event viewer (application) an event with ID 611.

Second lesson: 
We need to add an extra account as default account, to do this you have to modify the following attributes at your on premise Active Directory servers as you see in the example:


This fields are key sensitive, if you use capital letters in the SMTP, this account is going to be a the principal account.
Here is more information about this topic

Third lesson:
To delete a ghost user from Office 365, we deleted users on the on premise but they still appeared in the Office 365 users list. So we had to login via Powershell into Windows Azure Powershell and execute the following commands:

Fourth lesson:
We got an error when we were trying to sync existent Exchange 2003 accounts and we could solve it following the next link: .
Basically when you have an exiting account there is a msExchMailboxGuid attribute and you have to delete it from the synced attributes.
If you have synced users before knowing about this attribute issue, you have to sync the OU , move the users from the OU (without sync), remove the users from Office 365 via Powershell and finally sync again without the msExchMailboxGuid attribute.

Interesting links to read before a migration:


  1. This comment has been removed by the author.

  2. Nice Explainer. I've had good experience with EdbMails Edb to PST recovery tool - which provides a complete solution to recover Exchange Database (EDB) files. It is quick and uses deep scan to recover most data out of even corrupted databases.It supports public, private folder recovery. And also supports migration to Live exchange and Office 365. Archive mailbox migration is also supported by edbmails

  3. Thanks for sharing this information about how to migrate from exchange to Office 365, I also look at this article ( ) which provides the step by step information related to this topic and allows you to create migration batches to migrate each or a subset of mailboxes that you want to migrate.