In this blog post we will cover a very common scenario faced by customers who have moved all of their mailboxes from on-premises to the cloud. How do you create mailboxes directly in the cloud? The task might seem simple, but in support we see a fair amount of confusion around it. And there are certainly opportunities to do wrong things here!
You have set up Exchange hybrid configuration with Exchange Online (EXO) and have started or even completed your mailbox migrations. At some point, you decide that you want to have new mailboxes created as EXO mailboxes instead of creating them on-premises (and then migrating them to Office 365). But you quickly learn that if you create on-premises users, allow them to sync, and then just license them for Exchange Online, you’ll be unable to manage the Exchange attributes because there is no mail-enabled user in the on-premises Exchange organization.
If you’ve ever been in that position, this is the post for you. The process below will enable you to correctly provision mailboxes in EXO.
Once in hybrid, the Exchange 2013 (or later) Admin Center gives the admin the choice to create a New Office 365 Mailbox instead of a Mailbox. Using this option will create the AD User AND the Mail-enabled user (MEU) object with the remote routing address (such as jsmith@contoso.mail.onmicrosoft.com). This will then be synchronized to Azure AD by AAD Connect. Because we now have a MailUser object on-premises, EXO creates the corresponding Mailbox user.
This same operation can of course also be accomplished with the new-remotemailbox cmdlet.
Now, whichever way you used, to avoid potential issues if you ever need to offboard this mailbox back to on-premises, we recommend the EXO Exchange GUID be added to the on-premises MEU:
Set-RemoteMailbox “user identity” -ExchangeGuid “value from Exchange Online”
But let’s say you didn’t follow this process, and instead you just created the AD User without the remotemailbox. If this is your scenario then you’ll have to use the PowerShell cmdlet(s) to enable-remotemailbox.
The way forward then is to:
- Enable-remotemailbox on the AD User (see below)
- Validate synchronization to Azure
Here are a few notes regarding the usage of enable-remotemailbox instead of new-remotemailbox. Let’s say you run this command:
Enable-RemoteMailbox jsmith@contoso.com -RemoteRoutingAddress jsmith@contoso.mail.onmicrosoft.com
Since this did not specify a PrimarySMTPAddress then your Exchange Email Address Policy (EAP) will add both the primary via the Email Address Policy (EAP) and secondary proxy address - jsmith@contoso.mail.onmicrosoft.com. If this is what you wanted, you are good to go!
Sometimes though, we have seen some customers get into trouble when they include the –PrimarySMTPaddress parameter. They want a primary SMTP address that doesn’t match their EAP default. In that case, you’ll need to also add the secondary proxy address jsmith@contoso.mail.onmicrosoft.com in a subsequent PowerShell cmdlet (or use on-premises EAC).
You cannot unfortunately include the secondary proxy address that matches the remote routing address using the Enable-RemoteMailbox cmdlet as it is not a supported parameter. This needs to be done separately using the Set-RemoteMailbox Cmdlet. The ‘EmailAddresses’ parameter is a multi-valued property and needs to be ‘added’ to the existing values as follows:
Set-RemoteMailbox -Identity jsmith@contoso.com -EmailAddresses @{add= ‘jsmith@contoso.mail.onmicrosoft.com'}
This will add the secondary in the MEU proxy addresses on premises and AAD Connect will synchronize it to the O365 mailbox proxy addresses, enabling delivery via the matching remote routing address. Again, once the EXO mailbox is created, make sure you add the EXO Exchange GUID to the on-premises MEU.
I wanted to thank Nino Bilic, Ben Winzenz, Mirela Buruiana and Greg Taylor for their review of this post!