On provisioning mailboxes in Exchange Online when in Hybrid

Published 05-20-2020 12:22 PM 22.4K Views

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:

  1. Enable-remotemailbox on the AD User (see below)
  2. 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!

Larry Dunnewin

Occasional Visitor

Hi Guys - The above references Exchange 2013 (or later).

How does this apply when your on-premise environment is Exchange 2010?

Are you able to provide guidance in that scenario too?



The EAC for New Office 365 mailbox only applies to Exchange 2013+.  For Exchange 2010 you will use the PowerShell cmdlets. 

Occasional Visitor

Great post, I was actually having a discussion with my team about this very subject on the same day this got published. Spooky!


I do have one question regarding however. In a Hybrid environment when changing a users UPN in Active Directory which has an Exchange Online Mailbox the primary SMTP Address does not get updated automatically on either end to reflect this. Exchange on-prem and EXO still show the original UPN. Even after forcing an update of the Email Address Policy. 


Typically we would need to change this when a member of staff changes their name, such as get's married for example.


To resolve this we have had to modify primary SMTP address within the proxyAddresses attribute under the users account within Active Directory then force a sync with Azure AD Connect.


Is there an official supported way of making the on-prem UPN and Primary SMTP address match between the two environments? 


Many thanks. 


Hi @Larry_Dunnewin, do you know the minimum CU version or was it included in RTM for Exchange 2013 & 2016? My gut tells me it wasn't included in RTM but I wouldn't trust that! :)

Regular Contributor

@GreigMitchell You can enable the synchronization of the UserPrincipalName attribute.


To check whether this feature is enabled run



and check if SynchronizeUpnForManagedUsers is enabled.


Caution: Setting SynchronizeUpnForManagedUsers to $true is a one-time operation and cannot be undone.


If it is true (which probably is not the case in your environment) then the UPN should be updated in the cloud after you change it on-premises. This can take a while.


An automation to match the email address to the UPN does not exist. Best you can do is having an active EAP that updates the email address based on the alias (mailNickname in Active Directory). In that case, when you change the UPN, you must change the alias, too.


The easiest way to do all of this in one step is to use Set-RemoteMailbox:

Set-RemoteMailbox jon.doe@example.com -UserPrincipalName jon.dane@example.com -Alias jon.dane 

And if you're like and like a clean user object, you can change the RemoteRoutingAddress with it as well:

Set-RemoteMailbox jon.doe@example.com -UserPrincipalName jon.dane@example.com -Alias jon.dane  -RemoteRoutingAddress jon.dane@example.mail.onmicrosoft.com


If you do not have an EAP, add the -PrimarySmtpAddress parameter.


The UPN change at Microsoft will take a while.


If SynchronizeUpnForManagedUsers is false, then you need to change the userprincipalname manually by using the Set-MsolUserPrincipalName cmdlet.


@Joshua Bines I do not know for sure if the "new office 365 mailbox' was part of RTM for Exchange 2013, however, I am on the side of it was, rather than it was not.  Regardless, best practice for Exchange Hybrid configuration is to have your on premises servers on the most current version.  

New Contributor

@Joshua Bines, Remote Mailboxes were introduced in Exchange 2010 SP1.  They got a lot easier to work with in SP2 when the HCW was introduced.


i.e. https://lh3.googleusercontent.com/proxy/-FxF5xk7hUoc7Wlcc8XKdunjfguHCL2D7TOvVkBKF0Qihw-HhS2uNbKlO-rl...


Senior Member



I can comment to say that the new Office 365 mailbox option is available in the EAC for Exchange 2016 when in Exchange Hybrid mode with Office 365.


We are considering removing the Exchange Hybrid configuration and did so in our test environment and noticed that the option to create an Office 365 Mailbox was no longer in the EAC for 2016.  We are hopeful that we can find a Microsoft supported GUI solution for this if we remove Exchange Hybrid but, it is not looking hopeful at this time. 


We are going to continue with an Active Directory hybrid configuration and would like to know if you have any account management/provisioning best practice links you could share after Exchange Hybrid is removed?





@Bentley_at_Work  Currently, when users are synchronized with AAD Connect, the best practice is to remain in a hybrid configuration with an Exchange on premises server for management of Exchange Online mailbox attributes. Why you may not want to remove all Exchange servers

Senior Member

Perhaps worth mentioning that you can create rooms, equipment and shared-mailboxes on-prem with the -room/-equipment/-shared switches for new-remotemailbox (or enable-remotemailbox) nowadays. In that way, you do not need to assign a license at the creation time.


In earlier versions, the only mailbox type that new-remotemailbox could create was a user mailbox, so you had to do that, wait for replication, and then change the mailbox type on both ends to match, and could revoke the license for shared mailboxes...which was a pain.


So so much easier now..

New Contributor

@GreigMitchell - UPN change due to Name Change

In the old Exchange 2010 we would just modify the Alias and it would update the email address since our policy states that it is the alias@domain.com.  But in Exchange 2016 Microsoft does not make that field available, so we just edit AD to change their mailNickname field which is the field that stores what Exchange labels "Alias".  We then force it to apply our rule.  We then have their old smtp address in there and their new SMTP address.  We schedule and let them continue having both email addresses for 60 days to clean up all of their newsletters.  After 60 days we remove their old email address.

New Contributor

I'm also very curious what the Microsoft supported way is for changing names (marriage/divorce).
What are the supported issues for changing mailNickname, targetAddress and userPrincipalName.

Is it allowed to change them in AD and let the changes sync, or does it have to be done with Exchange PowerShell commands (or GUI)?

And what is the best practice? Correct everything or leave the mailNickname and TargetAddress alone?


I really would like an official answer from the Exchange team.

Regular Contributor

@Ron Houet  There is an official answer. In a hybrid environment with Exchange you must use Exchange to manage that. SO either through the ECP or with PowerShell (*-RemoteMailbox). Everything else is not supported.


@Ron Houet  If you want the offical answer. 


The Exchange Management Console, the Exchange admin center (EAC), and the Exchange Management Shell are the only supported tools that are available to manage Exchange recipients and objects.



The Azure AD Product team are working on removing this requirement ATM. 


New Contributor

@Joshua Bines Thank you for your answer and I already read the link you reffered to. But I don't want to use third party solutions nor do I want to use ADSIEDIT. If a property of a user changes (like the UPN) you can change that in Active Directory Users & Computers. Exchange command's aren't capable of that. If you do that the other properties like mailNickname and targetAddress will not be changed. You can change those in ADUC with attribute editor but I believe that's not a supported way.


So again, thank you for your answer but I really would like an answer from the Exchange Team regarding changing those values.

Also regarding the recommended way whether you should change the mailNickname and targetAddress or if you should leave them alone. (which leads to discrepancies in the attributes)

Regular Contributor

> If a property of a user changes (like the UPN) you can change that in Active Directory Users & Computers. Exchange command's aren't capable of that. If you do that the other properties like mailNickname and targetAddress will not be changed.


@Ron Houet  Set-RemoteMailbox can change the mailNickname (Alias), targetAddress (RemoteRoutingAddress) and the userPrincippalName. Have you read the docs for the command I gave you, because it's very well documented in there.

New Contributor

Hi Daniel, my apologies, I see now that the remote mailbox commands can change all that too.
But still, I would like to hear the best practices in streamlining the targetAddress and Alias or leave them in the original state when changing a username?

Occasional Visitor



I'm a newbie at this, so forgive me if it's an obvious "can't do it". I have to modify old codebase that creates an AD user using System.DirectoryServices. The code creates an AD account, but now I need to add the enabling of the remote mailbox. Is there a way to do the same as new-remotemailbox and enable-remotemailbox in DirectoryServices? Or is it only thru PowerShell?




Senior Member

Unfortunately there are a lot of features missing. For example enabling existing Users in the GUI. This is possible if you create an OnPremises Mailbox but not when creating an O365 mailbox (why?). Furthermore, if you create Room/Resources, they are shown in the "mailboxes" tab and not in the "resources" tab. This is confusing to delegated admins.


Shared O365 mailboxes cannot be created in the GUI - did you forget the entry in the dropdown when the mailbox is created?


O365 resource/shared mailboxes cannot be added to groups via the GUI. (this is btw a simple change in the GroupPicker.as* file - the filter there is simply missing some recipient types...)


And last but not least: https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/6412831-remove-requireme...


The solution that the AAD Team is working on, has a status of "Started" for exactly one year with no updates how it is proceeding...

Senior Member

We are planning to start cloud mailbox provision. At present we are stuck with shared mailbox permission issue. basically you can take advantage of any of this PS command  New-RemoteMailbox, Enable-RemoteMailbox, Set-RemoteMailbox to create Shared mailbox in EXO. problem is after that how can we grant SendAs and Full Access permission as there is no remote command available for Add-MailboxPermission. 

Issue is if you are creating shared mailbox using script you will have to silent your script for 30 minutes or go in loop until this is replicated on Azure-AD. You can not run Add-MailboxPermission until mailbox is provision on EXO.

Has anyone came up with solution to grant mailbox permission with minimum admin activity?

Frequent Visitor

I did not see an answer to the question by Ron above that I am also looking for.


When we are required to change the username and email address of an end user in an Hybrid O365 configuration.  What is the best practice for the targetAddress(Remote Routing Address) and mailNickName(Alias) attributes? 


Specifically, should we change/update them, adding the old email address to catch any mail that may still be sent to the old address, or leave them in the original state and just add the additional email address needed and disable the address policy so the new address can be set as the Primary address?


NOTE: Our current email address policy makes the mailnickname/Alias the primary address and sets the remote mail address to the mailNickName@tennant.onmicrosoft.com)?


Version history
Last update:
‎May 20 2020 12:22 PM
Updated by: