Enable-RemoteMailbox – Is It A Chicken Or An Egg

This post is to answer a recent customer question regarding if there is a requirement to perform a directory sync cycle after creating a new remote mailbox enabled AD user object before it could have an Office 365 mailbox created.

They believed that the on-premises Exchange tools were directly reaching out to Exchange Online and immediately creating the necessary mailbox in the service.   This is what they inferred as when they went to look for the mailbox after a period of time, it was present.

In reality though, the technology operates differently and things are related to the old adage of which came first, the chicken or the egg?


To illustrate how the remote mailbox changes flow to the tenant, let's create a sample user and see how things work.



In the example below we are using the Exchange 2010 MMC to create a new user object and remote mailbox enable the account.  This is the equivalent of the New-RemoteMailbox cmdlet in PowerShell.

The trick in Exchange 2010 is to set the focus on the correct node, and then the New Remote mailbox options are displayed.  In this case, we are right clicking on the Recipient Configuration node in the left hand navigation tree.

Locating Correct Location To Create Remote Mailbox in Exchange 2010 MMC


Stepping through the New Remote Mailbox wizard is straightforward.  We select to create a regular user account.

Note that the requirement to ensure a license is assigned is highlighted along the bottom.

Creating New Remote Mailbox in Exchange 2010 MMC


Fill in the relevant details.  In the example below the Stan Remote mailbox will be created.

Creating New Remote Mailbox in Exchange 2010 MMC - Specifying User Information

We will skip adding the Online Archive mailbox.  This can be added later if required.  See this post for the relevant details.

Creating New Remote Mailbox in Exchange 2010 MMC - Will Not Create Online Archive Mailbox

Now that we are done, we can click New.

Creating New Remote Mailbox in Exchange 2010 MMC - Confirmation

Exchange will create the new user object and stamp it with the necessary attributes to make it of type Remote Mailbox.

Creating New Remote Mailbox in Exchange 2010 MMC - Completion Summary

The status text is pasted below for accessibility.

Summary: 1 item(s). 1 succeeded, 0 failed.
Elapsed time: 00:00:01

Stan Remote

Exchange Management Shell command completed:
New-RemoteMailbox -Name 'Stan Remote' -UserPrincipalName 'sremote@Tailspintoys.ca' -FirstName 'Stan' -LastName 'Remote' -Initials '' -Password 'System.Security.SecureString' -ResetPasswordOnNextLogon $false

Elapsed Time: 00:00:01


So this means that the mailbox is now created in Exchange Online?


In a single word, no.    It is not.


We can see this if we immediately go to Exchange Online or Azure AD, we cannot find any objects called "Stan".

Unable to Immediately See New Remote Mailbox in Office 365


Chicken Vs Egg

The reason that the mailbox nor the Azure AD object is not visible is because all of these changes were made to on-premises Active Directory.  No changes were made directly to Azure AD.

The changes will get there, once Azure AD Connect synchronises them.  This is the expected behavior.

Running the New-RemoteMailbox or Enable-RemoteMailbox cmdlets writes the attributes to the local Active Directory.  By writing the attributes to AD, on-premises Exchange is aware of the remote mailbox in Exchange Online and this remote mailbox is visible in the on-premises GAL.  Note that even in Exchange hybrid a separate GAL is built by Exchange on-premises compared to the GAL that is build by Exchange Online.  If the relevant Exchange install does not have access to the attributes it is unaware of the presence of the mailbox and by extension cannot include the mailbox in its GAL.  The same concept applies for contacts and groups.  They need to be synchronised so that they are  visible in the GAL.  If not then you will have user complains and mail flow issues.



Laying the Egg

We can wait for AD to replicate and then wait for the next synchronisation cycle or manually force both of them.  In this lab, there is a single AD site and replication occurs in seconds.  Your environment may be different so follow your regular SOP for forcing AD replication.

Following the steps in How To Run Manual DirSync / Azure Active Directory Sync Updates.


Start-ADSyncSyncCycle -PolicyType Delta]/code]

Manually Running Azure AD Connect Delta Sync Cycle


The we can monitor the attributes which are being sent to the tenant using MIISClient.exe which is part of the Azure AD Connect install.

In the main window, which is in the background, note that a single ADDS operation was noted.  If we double click on that, the child window pops up.

Reviewing Synchronised Object Attributes in Azure AD Connect


We can drill into that and look at the attributes which are being added.

This is the account which we just created - Stan Remote.

Reviewing Synchronised Object Attributes in Azure AD Connect - Details Shown for Stand Remote Mailbox


In the about we can see the Exchange attributes in addition to the standard user object attributes.  The Exchange specific attributes include:

  • legacyExchangeDN
  • msExchRecipientType

So until Azure AD connect synchronises with the tenant, Azure and Office 365 are unaware of this object and cannot find it.




Rhoderick Milne [MSFT]

Leave a Reply

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