Avoid hidden pitfalls when migrating to Office 365

Office 365 is widely used in businesses of all sizes. At Bridgeall, we have migrated many companies from Exchange to Office 365 and, now we know the pitfalls, we have created a slick migration process. To save you time and effort we thought it would be useful to share details of the niggles we’ve encountered.

Pre-Migration

We always follow best practise and therefore before we start the migration we recommended carefully auditing and documenting the on-premise exchange environment. This includes full details of mailboxes including email addresses, permissions, mailbox size, mailbox rules etc. as well as details of contacts and groups. On top of this, we document all of the exchange configuration details including retention polices, transport rules, email address policy, send / receive limits, public folders and whitelists.

To determine which AD / exchange attributes need to be updated before the migration, we use a tool called IDfix, full details can be found here.

One important thing that the migration tool doesn’t pick up is the flag on distribution groups determining if external users can use them. Once you have migrated all of your groups under delivery management they will all be set to accept mail from:

“Only senders inside my organisation”

It’s obviously an easy fix but one that is good to know about before users do.

During the Migration

The biggest hurdle we have found was a permissions issue when using the Office 365 migration tool. We were performing a cutover migration and were able to migrate all user accounts, contacts and groups, but the mailboxes kept failing.

We would receive this error message:

Transient error MapiExceptionLogonFailed has occurred

A quick google will tell you that this is a permissions error and you should ensure your migration account has full mailbox access and ‘receive as’ rights. We had checked this and it was not the issue. When we created a new account on the local exchange we discovered that it would migrate without issue. It was clear that the older accounts had different settings. These accounts had been migrated from earlier versions of exchange.

After opening a call with Microsoft we were asked to run the PowerShell command:

Get-MailboxPermission ProblematicMailboxAlias | where {$_.deny}

This allowed us to see if deny permissions were causing the issue. Having discovered that the accounts did have a number of inherited deny permissions we were asked to run the command below:

Re-running the migration after this worked for the majority of the accounts. There were still a couple which didn’t work, so we had to run the following PowerShell to pick up the few accounts that were missed by the previous command:

After running this for each of the “failed users” we discovered that users migrated as expected.

Synching AD with Office 365

Unless you are a large business you probably won’t be going down the road of ‘Single Sign On’ using ADFS. But using DirSync may interest you as it allows your users to have the same password for both local and cloud accounts.
In my experience it is preferable to edit DirSync to only sync selected OUs, as this will keep your office 365 environment tidier. Before synching a user you should ensure their UPN name is the same as their office 365 username.

To check the UPN, open active directory users and computers, open a user and choose ‘attribute editor’ and scroll down to UserPrincipalName.

Open the properties of the Active Directory Connecter (under management agents), choose configure directory partitions and then click on containers.

You may be prompted to enter the domain username and password of an admin account.

From here you can choose from the lists the OU’s that you want to sync.

DirSync will sync every three hours, (it’s almost immediate for password changes), but you can force a sync by running the following two powershells commands.

Import-Module DirSyncStart-OnlineCoexistenceSync

You will discover that there are a number of fields that you are unable to edit for synched users in office 365, one of these is email addresses. If you want to add an additional email address then you need to do this from your local domain. It is likely that you won’t have on-premise exchange so it needs to be from ADUC.

You need to open attribute editor for the relevant user in ADUC (per instructions above) and navigate to proxy addresses. It is likely this will be empty if the user doesn’t have any other email addresses, if so you will need to make sure you add both the primary address and your new alias, noting the SMTP should be in uppercase for the primary address: