Office 365 email migration gotchas

One of the things I’m working on at the moment is moving the remainder of our Exchange organisation over to Office 365 / Exchange Online.

We moved the bulk of our accounts some time ago; students here have been on Office 365 Exchange email for a few years, but staff and ‘role’ email accounts have been held on local Exchange servers until this month.

The things I’ve seen people worry about on these migrations have actually been the least of my worries. All my mailbox accounts migrated using the Exchange Online migration tools without any real difficulty. The few gotchas I found here are that users with an online archive mailbox cannot be migrated ‘as is’, and users who do not have a ‘@domain.mail.onmicrosoft.com‘ address defined in their email addresses.

The most common cause for the email address is the default email address policy not being applied to that user, which is a tickbox in the EMC on your Exchange server recipients / mailbox user / email addresses dialogue, or can be enabled via powershell with:
Get-RemoteMailbox <name of mailbox> | Set-RemoteMailbox -EmailAddressPolicyEnabled $True

Or if you wish to apply this to all mailboxes (ensure it hasn’t been disabled for a reason if you have a large number of mailboxes in this state):
Get-mailbox –resultsize unlimited | Set-Mailbox -EmailAddressPolicyEnabled $true

Another issue is with password complexity rules and role /  service mailbox accounts. Based on our experience here, where an account has been set up some time ago, and subsequently the password complexity rules for your domain have changed so that the account’s password would no longer be valid, then even though it still is valid as far as your local domain is concerned and you can log into a domain workstation with the ‘old’ credentials, login to Office 365 may well fail. The answer is to update the password to one that meets your new complexity requirements.

Lastly, and again this might be an issue with older service accounts, ensure that the UPN is sensible (I suggest it should match the email address, and I think most people would agree with me).

We’ve been able to update things like database email settings, role mailboxes and third-party apps to send SMTP mail directly via Office 365, rather than a local relay, using those caveats around passwords and the mail server settings below:

SMTP Server : smtp.office365.com
Port                 : 587
SSL / TLS      : Yes (note that if your app uses really old SSL 2.0 and nothing newer you may have trouble. It’s time to upgrade)

Authenticate with:

Username : user@domain.com (should be the full UPN as defined in Active Directory User & Computers)
Password  : {Active Directory Password}