• Insights

What to Do About Account Conflicts in Office 365

Dominick Ciacciarelli

3 min read

All Insights

If you have ever experimented in an Office 365 tenant before going all in and syncing Active Directory, you may have encountered a situation in which you connected an on-premises account with a pre-created cloud account, and possibly a mailbox. A number of issues can arise from this situation, but the one most likely will be the inability to migrate the mailbox from on-premises to Office 365.  When this happens there are a number of steps that need to be taken in order to sever the ties between these two accounts.

First, you have to understand something about Office 365 account types and domains. When an Office 365 tenant is created, the default domain will be something like Contoso.onmicrosoft.com. The “Contoso” portion is an identifier that is chosen by whoever secures the tenant. Microsoft adds the “onmicrosoft” portion as it owns that namespace, and all Office 365 tenants live under that umbrella.  But as we all know by now, companies that live in Office 365 don’t change their email addresses to onmicrosoft.com. In order to allow Microsoft to send and receive email on your behalf, you need to provide proof of ownership of the domain. Once you do, you will be able to create accounts and assign them UPN’s of User@Contoso.com.

So now that we are able to use our real domain, we can create our first user: JDoe@contoso.com. Once we assign a license to our user, unless we specifically exclude email services, a mailbox for this user will be created. Of course, because your MX records are still pointing to your on-premises environment, this user will not receive mail addressed to  JDoe@contoso.com. The mailbox will, however, receive mail bound for JDoe@contoso.onmicrosoft.com and because the UPN is JDoe@contoso.com an smtp address for JDoe@contoso.com will be included in the list of proxyaddresses for the user.

At this point, the JDoe@contoso.com account in the Office 365 tenant is a cloud account. This means it has absolutely no connection to any other account. This will change once the on-premises Active Directory is synced with Office 365 and its underlying AzureAD tenant. Once Azure AD Connect begins the synchronization process, it will see the UPN for JDoe@contoso.com, and create an association between the two accounts.  Once this occurs, the account in question will cease to be a cloud account, and will now be categorized as “Synced with Active Directory.”

The issue here should be clear – JDoe@contoso.com now has two mailboxes: an on-premises Mailbox and a mailbox in Office 365. This will cause a host of issues. First of all, any attempt to migrate JDoe@contoso.com to Office 365 will fail, as the corresponding account in Office 365 already has an associated mailbox. Second, any users who are properly migrated to Office 365 will be unable to email JDoe@contoso.com’s on-premises mailbox because the message will land in the office 365 mailbox after seeing that target first.

In order to rectify this situation, a number of steps must be taken:

First, move the user account to an OU that is not being synced with Azure AD, and force a sync. This will perform a soft delete of the account in the cloud.

Next, run the following command in in Azure PowerShell (not Office365 PowerShell):

Get-MsolUser -ReturnDeletedUsers | fl UserPrincipalName,ObjectID

Get the ObjectID from the deleted account from the output of the previous command and run the following to remove it from the recycle bin:

Remove-MsolUser -ObjectID <ObjectID from previous command> -RemoveFromRecycleBin -Force

That will get rid of the account, but the mailbox will remain in the recycle bin, and if you were to re-enable the account, it would match  your account because of the SMTP Addresses…  So the mailbox must be connected to a new Azure AD account (a cloud-only account) by running the following in Office 365 PowerShell (not Azure PowerShell):

New-Mailbox -InactiveMailbox <UPN of Deleted Account> -name tempdelete1 -MicrosoftOnlineServicesID tempdelete1@contoso.onmicrosoft.com

This creates a new cloud-only account, for this mailbox. You then need to go into that account and delete all of the SMTP addresses (which you can now do because it is cloud-only).

Next, move the AD account back to its proper OU and force a sync. It will now appear in the cloud as any other Synced user. You will need to reapply the license. As far as the cloud is concerned, this is a new account.

Lastly, delete the tempdelete1 account from the portal, which will in turn delete the mailbox, and give you back the license.

Careful planning of your AzureAD/Office 365 deployments can prevent situations like this, but when accidents do happen, it helps to have a way around the issue.



The Azure Files: A Law Firm's Guide to Cloud Migration