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.
New-RemoteMailbox
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.
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.
Fill in the relevant details. In the example below the Stan Remote mailbox will be created.
We will skip adding the Online Archive mailbox. This can be added later if required. See this post for the relevant details.
Now that we are done, we can click New.
Exchange will create the new user object and stamp it with the necessary attributes to make it of type Remote Mailbox.
The status text is pasted below for accessibility.
Summary: 1 item(s). 1 succeeded, 0 failed.
Elapsed time: 00:00:01
Stan Remote
Completed
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".
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]
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.
We can drill into that and look at the attributes which are being added.
This is the account which we just created - Stan Remote.
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.
Cheers,
Rhoderick
