Migrating to Office 365 Part 2: Exchange Cutover migration tips

Reading Time: 5 minutes

So in Migrating to Office 365 Part 1: Business Case I’ve discussed reasons for migrating, budget and the selected solution. Now I’m going to discuss the technical migration of on-premises Exchange 2010 SP1 mailboxes to Office 365 Exchange Online.

Cutover migration

As I have chosen the P subscription, my options are somewhat limited as you can see in this matrix. So, cutover migration it is!

The Office 365 help has a step-by-step description of the necessary steps that you need to take, but basically it’s:

  1. Prepare and connect your on-premises Exchange environment with your Office 365 account.
  2. Start replication of mailboxes and wait for initial replication to finish and continue to replicate until you are ready to change MX record and your client settings.
  3. Change MX records, finish the replication, disable On-premises Exchange and change client settings.

In most to all cases the Microsoft manual is sufficient, however I ran into some issues ad want to share them with you.

The first account

You can start with just a trail account, just to get things started. But be sure not to create an account which already exist in you current Exchange environment, as it will probably fail with synchronization.

But If you read this too late, you can also make another admin account, delete the previous one and start again.

Due remember that this account will need a license (you cannot have an logon only account). So, if you want to separate users from admins take that into account in your budget.

DNS and Domain Names

My domains in the admin console page of Office 365Make sure you have access to the DNS settings of your domain. In order to add a domain name to Office 365, and thus use the same email address domain as you do now, you must be able to add an TXT record or MX record specified by Office 365 to prove that you own and control it.

I’m not sure, but you have to set up the domains before you can synchronize the contents of your Exchange mailboxes. The SMTP addresses of the users are immediately migrated (as other settings), this could potentially be broken if not all domains are active in Office 365. You can add SMTP addresses later, but only if added in your Office 365 account.

Oh, and do mind that if you already have experimented with Office 365. A domain can only exist once inside Office 365, so remove them from potential older test accounts.

And for those who were wondering: I haven’t encountered a limit on domains. I currently have three (excluding the default Office 365 domain).

Outlook Anywhere

If you have Outlook Anywhere working, you already okay for the most part. If not, you have to implement this before continuing as Office 365 uses this to synchronize and migrate the mailboxes.

Unfortunately you cannot use a self-signed certificate for the migration. You have to use a trusted certificate, you cannot let Office 365 ignore whether it is trusted or not.

Luckily, there are free 30 day trail certificates available in certain countries. For example VeriSign has such a deal. 30 should be enough time to finish the migration. If you do not have access to such a deal, you have to buy a certificate. In most cases a single label certificate with just domain validation is adequate and they are not that expensive.

Choosing accounts

You cannot choose the accounts you want moved to Office 365, it's all or nothing! So, remove unwanted Exchange Mailbox enabled accounts in order to keep your synchronization shorter but also the amount of subscriptions low.

Even if you have cleaned it to bare essential mailboxes, you will get some error messages. Here are some I’ve encountered:

A Windows Live error occurred while provisioning for "DiscoverySearchMailbox{AABBCCDD-46A6-415f-80AD-7E09AABBCCDD}@test.nl". The e-mail name contains invalid characters.

This is the Discovery mailbox, you cannot synchronize this but you don’t need it. So, you can ignore this error.

dmstork@test.nl,"The name ""dmstork"" is already being used. Please try another name."

Well, quite clear error message. Apparently you already synchronized before and are trying another sync, or you already made an account by hand with an name that already existed on you On-Premises environment. Delete or rename the account.

dmstork@test.nl,"Failed to update one of the recipient properties. Couldn't find object ""/o=NT5/ ou=3ba9ab9c2d5d5c4c9fd473ce5c674fa6/ cn=343626c72807c6488729101507fd6177"". Please make sure that it was spelled correctly or specify a different object."

This one gave a lot of pain. The synchronization could not be successfully finished due to this error, so it was quite the showstopper.

Luckily I discovered others where having the same or similar issue, as you can read here. It turns out that if an account had Send-On-Behalf permissions, the synchronization process wants to synchronize those settings. That is actually good.

But here’s the thing, it turns out that certain properties are not removed when the Send-On-Behalf account has been deleted. It does disappear in the Outlook Delegates screen, making this an hidden problem.

Luckily you can remove the property via ADSIedit.msc, an description can be found here. After that, the error should go away.

User configuration, like Primary SMTP

Normally with an cutover transition every relevant attribute will be transferred as it is in your On-premises environment. Even user’s theme settings and rules and forth. But it is possible you need to change the Primary SMTP, the reply mail address.

The ECP web console does not give you the possibility to change the primary SMTP. There are two options to resolve this, by using remote PowerShell or by using a local Exchange Management Console by adding an Exchange Forest (select Exchange Online for FQDN and provide your Office 365 admin account credentials).

Local client settings

You will probably have to reconfigure every Outlook located in the internal network. The reasons why depend on On-Premises Exchange version and configuration. I had to manually reconfigure every Outlook client (luckily just three PC’s) after I had removed my On-premises Exchange. Another option is using an PRF configuration file at the first Outlook startup, something that is scriptable.

In my case Outlook when using Autodiscover to create a new profile, it tried to connect to both servers for various reasons (Split DNS, internal Autodiscover SCP record in AD) resulting in no working connection at all. So, calculate that that when you have finished your migration to Office 365 that you will probably have to remove all remnants of you On-premises Exchange.

Issues with stil a local SCP record, JAEL.* was my internal Exchange server and Outlook.com is that of Office 365

There probably a lot of workarounds possible, but those would probably very specific for each environment. As you apparently do not have any need for On-Premises Exchange, removing it is possibly the fastest way to resolve these issues.

This would not be the case if you had the option for an Hybrid environment, but for that option you would have to have an E plan subscription for each mailbox. Which is more expensive than the P plan.

Conclusion

Even with these issues I felt the migration was quite uneventful and smooth. There were some hiccups, but they were resolved quite quickly.

Undoubtedly there are more issues one can run into. But I hope that mentioning some of I have encountered here, will make your transition to an Office 365 P plan subscription a lot smoother. Even more smoother than mine. Winking smile

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.