How to create a remote “Office 365” mailbox in a hybrid deployment

I’ve recently seen the same issue pop up in a few different environments so I thought I would put together a short post that explains how to create a “Office 365” mailbox when using a hybrid deployment of Exchange. One of the questions I’ve had had answer a few times recently is “Why do newly created Exchange Online mailboxes not appear in the on-premises Exchange Admin Center as “Office 365” mailboxes like migrated mailboxes do?”

There appears to be some confusion around provisioning of new user mailboxes once a hybrid deployment has been configured as this issue is caused when the mailbox has not be correctly provisioned in the on-premises environment.

cap3

While it is technically possible to create a new user account in Active Directory, wait for AAD Connect to provision that account to AAD and then assign an Exchange Online license to that user to create their mailbox, but the problem with that process is that it does not set the msExchRecipientType (and other) Exchange related attributes for that user object and that is why it will never appear in the on-premises Exchange Admin Center:

cap2

In order to correctly popular these attributes, you either need to create the new user and mailbox via the Exchange Admin Center by clicking on the “+” icon and selecting “Office 365 Mailbox” or you need to enable a remote mailbox for a previously created user using the Enable-RemoteMailbox cmdlet

cap4

Many organizations already have automated provisioning processes in place so adjusting the mailbox enablement workflow may be the preferred method, an example of the cmdlet is shown below:

#Syntax is: Enable-RemoteMailbox <user> –RemoteRoutingAddress <user@tenant.mail.onmicrosoft.com>
Enable-RemoteMailbox homer -RemoteRoutingAddress homer@gooselabs.mail.onmicrosoft.com

cap1

The Enable-RemoteMailbox cmdlet can be run immediately after creating the user account in Active Directory so there is no need to wait for the next AAD Connect synchronization cycle to complete before enabling the mailbox. Once the user account has been provisioned to AAD, the mailbox will automatically created and the appropriate license should then be assigned to the user.

More information on the Enable-RemoteMailbox cmdlet can be found on TechNet here

Post navigation


Comments

  • Ryan

    Great stuff, saved me a lot of grief going down the wrong road.

    Thank you.

  • Sameer

    If i create the mailbox on cloud using the above method, can we move the mailbox back to on premise

  • Chris

    Hi Sameer,

    Yes you can move a mailbox back on-premises.

    Cheers,

    Chris

  • Steve Dubrava

    Don’t do it Sameer— Chris the problem with creating a user only in cloud is there is not an AD entry for the user. Set-MsolUser and SetMsolUserMailbox does great if you don’t want them on your AD as a user. Works to create a cloud account, add licenses, even sync to the onPrem Exchange in hybrid, but no AD account…

  • Chris

    Hi Steve,

    Yes, you are correct that creating a user directly in Azure AD doesn’t create a corresponding user in the on-premises AD, however, the instructions in this post is not for that. What we are doing here is creating a mailbox in Exchange Online for a user that has already been created in AD (on-premises).

    Sameer’s question was about moving a user back on-premises that had been created using the method in the post and the answer to that is yes, it can be done. There are screenshots above showing the properties of the AD account.

    Cheers,

    Chris

  • Duncan

    Hi Chris,
    We have the exact issue described above. If the mailbox was not created using the on-prem EAC but created when the Office365 license was applied, would using Enable-RemoteMailbox allow it to appear in the on-prem EAC? User syncing is ok and mail flow is good with manually set AD attributes (mailNickname, ProxyAddress, TargetAddress).

  • Chris

    Hi Duncan,

    I believe that will do it – I’ll look through some notes/test it and let you know what I find.

    Cheers,

    Chris

  • Niels

    Hi Chris and Duncan,

    Same situation as Duncan.
    I already have a couple of users that got a cloud mailbox thru adding a license, and now AD and EAC is lacking info.

    How to convert a cloud mailbox to a remote mailbox?

    Regards
    Niels

  • Chris

    Hi Niels,

    This should do it for you (run on your on-premises EMS): Enable-RemoteMailbox “John Smith” -RemoteRoutingAddress “john.smith@tenant.mail.onmicrosoft.com” – obviously be sure to lookup the remote routing address already being used by the user.

    Cheers,

    Chris

  • swati

    Hi,

    In my setup Enable command gives following error,it never works,though the user i m running this command has all the required privileges. Please suggest a way out.

    Enable-RemoteMailbox : The term ‘Enable-RemoteMailbox’ is not recognized as the name of a cmdlet, function, script
    file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct
    and try again.

  • Chris

    Hello.

    What version of Exchange Server are you running? Also, are you sure you are running this in the EMS and not regular PowerShell?

    Chris

  • MichaelT

    I ran this but I am getting an error stating the following:

    ExchangeGuid is mandatory on UserMailbox.

    Database is mandatory on UserMailbox.

    ExchangeGuid is mandatory on UserMailbox.

    Database is mandatory on UserMailbox.

  • Marco

    Great Post Chris. Between this post and Script to create O365 mailboxes it helped me out a lot.

  • Chris

    Hi Michael,

    Could you provide some more detail? What was the exact cmd you ran?, where are you running it?

    Thanks

  • Joe

    Does ExchangeOnline contain these attributes, if so is it not possible to writeback these to the users OnPrem Account?

    Does this apply to Shared Mailboxes, if created in Exchange Online these will no appear onPrem?

  • Chris

    Hi Joe,
    Nope, these attributes are not currently written back. There are very few attributes written back to AD from AAD, for a list of these see: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#exchange-hybrid-writeback

    You are correct about shared mailboxes – the recommended approach at the moment is to create it on-premises and then move it to exchange online.

    Cheers,

    Chris

  • Nav

    Hi Chirs,

    If i have hybrid setup without ADFS servers, would enable-remotemailbox command work. ADFS servers are optional though recommended. I have been tried enable-remotemailbox command but it fails with an error that it couldn’t find the object on local dc.

  • Chris

    Hi Nav,

    Yes, that will work fine. AD FS isn’t even really a recommendation – it really depends on your authentication requirements.

    Are you able to send me a screenshot of the error you are receiving?

    Cheers,

    Chris

  • Naveen Kumar

  • Wayne

    Hi
    ive run your command but when I try to off board the users is cant find the user exchange GUID on the exchange server it says it cant find the user but he shows up in the exchange admin now

  • Wayne

    Hi
    P.S
    I have a large amount of users that are on prem accounts synced to 365 with 365 email never touching the on prem server but know need to migrate them back

  • Gregory Damon

    Great article. I use this link to hand out to customers after migrations. Good to see someone I know posting good stuff. Thanks Chris!

  • Chris

    Thanks Greg!

  • Chris

    Hi Wayne,

    Did you get this figured out or are you still having the problem?

    Cheers,

    Chris

  • Lukas

    Thank you very much – The command saved my life.

    I did however had to change the msExchRemoteRecipient value to 4 in my case in AD Attributes (4=migrated [not on DB on premise anymore]) –> I was aware of this from another case I had earlier this year. Because of that I saw that the attribute msExchRemoteRecipient was not even there before entering the shell command.

    – I hope this helps someone else as well – Maybe it’s something Wayne and

  • Chris

    Awesome, thank you Lukas.

  • Khalil

    The Command successfully enables the user mailbox, but with the Exchange GUID empty. I can’t figure it out.

  • Hari Prasad

    Hi Chris,

    Thank you for sharing the article. I’m at the same situation after migration to cloud the RecipientType has changed to MailUser and RecipientTypeDetails =RemoteUserMailbox.

    The problem is that the user is unable to access the On-prem 2013 ECP and is being rejected upon supplying the creds. Why is this and what is the solution for users to update their DG’s per se if they wanted to update as the sync is happening from On-prem. Please advise.

    Thanks,
    Hari

  • Chris

    Hi Hari,

    What you are describing is expected behavior, once a user has been migrated to Office 365 they will no longer be able to access the on-premises ECP. The solution to allow users to continue DG management is to move those DGs to Exchange Online but be aware that users who are on-premises will no longer be able to modify them. There are third-party solutions that help with this as well.

    Cheers,

    Chris

  • Jaime

    Thanks Chris and Lukas! I had both the msExchRemoteRecipientType and the msExchHomeServerName attributes for my users set incorrectly.

    I had to clear msExchHomeServerName as described in the linked article that Naveen Kumar posted.

    Additionally, I set msExchRemoteRecipientType to 4 as Lukas posted, and then I was able to correctly create the remote enabled mailbox.

    Thanks everyone!

  • Gregory Damon

    Thanks again, Chris. One more of your blogs that I point to using a hyperlink in my customer documents.

Leave a Reply

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

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>