Avoid hidden pitfalls when migrating to Office 365

Posted on

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:

Get-Mailbox -ResultSize unlimited -Filter {(RecipientTypeDetails -eq ‘UserMailbox’) } | Add-MailboxPermission -User migrationAccountName -AccessRights fullaccess -InheritanceType all -Deny:$false

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:

Add-MailboxPermission -Identity “failed user” -User MigrationAccountName -AccessRights FullAccess -InheritanceType All -Deny:$false

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.

To edit what OU’s are synched navigate to (%SystemDrive%\Program Files\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\UIShell) for 64 bit installations. 32 bit installations would be (%SystemDrive%\Program Files\Microsoft Online Directory Sync\SYNCBUS\UIShell)

And open up miisclient.exe

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

 

Office 365 Active Directory Connecter

 

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 DirSync
Start-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:

Primary Address SMTP:FirstName.SecondName@Domain.com
Secondary Address smtp:FirstName.SecondName@Domain.com

If you don’t enter your primary address then post sync the cloud account will change the users “Primary Address” to FirstName.SecondName@Domain.OnMicrosoft.com

 

If you would like to know more about the benefits of migrating to Office 365 then contact us today.

 

 

Share on FacebookShare on LinkedInTweet about this on TwitterEmail this to someonePin on PinterestPrint this pageShare on Google+Share on Reddit

Tags: , , , ,


Leave a Reply

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