In earlier blog post I explained how to create user account on-premises and accompanying Mailboxes in Office 365. This is possible with or without an Exchange server on-premises. The latter works, but it’s not supported.

There are also scenarios where you have cloud identities in Office 365 that you want to connect to user accounts in an on-premises Active Directory, so basically converting the cloud identity to a synced identity. This is a common scenario for example when moving from one tenant in Office 365 to another tenant, of maybe when moving from Groupwise or Notes to Office 365.

Suppose we have a cloud identity in Office 365 for a user named Chong Kim, he has an E3 license, a username ckim@exchangelabs.nl and this is also his primary SMTP address.

Logically the next step will be to create a user account in the on-premises Active Directory where the User Principal Name equals the User name in Office 365. This makes sense since the UPN is the common identifier and source anchor in Azure AD Connect.

However, when Azure AD Connect runs the two accounts conflict, and an email is sent to the tenant administrator’s mailbox containing the following error message:

Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [UserPrincipalName Ckim@exchangelabs.nl;]. Correct or remove the duplicate values in your local directory. Please refer to https://support.microsoft.com/en-us/kb/2647098 for more information on identifying objects with duplicate attribute values.

The problem here is that it’s not the UPN and User name that do not match, but it’s the SMTP address that does not match. The solution here is to match both users based on their Email address, so in Active Directory Users and Computers add the (cloud user’s) Email address to the mail attribute as shown in the following screenshot.

The next time when Azure AD Connect runs it will match both accounts based on the SMTP address, and the cloud identity is converted to a synced identity as can be seen in the Microsoft Online Portal:

To finalize the account on-premises you should RemoteMailbox enable it to make sure all Exchange related properties are set properly in the on-premises Active Directory. This way you end up in a fully supported scenario. To RemoteMailbox enable the account execute the following command in the Exchange PowerShell:

Get-User ckim@exchangelabs.nl | Enable-RemoteMailbox -RemoteRoutingAddress ckim@exchangelabsnl.mail.onmicrosoft.com

From this moment on the account is fully managed in your on-premises Active Directory (and on-premises Exchange server).