What is a Hybrid Exchange Mailbox?

If you’re a messaging administrator planning or managing an existing Hybrid Exchange environment, you may be wondering how exactly Hybrid Exchange mailboxes work.  Microsoft has made deploying Hybrid Exchange environments very easy by way of their Hybrid Configuration Wizard (HCW) and the Azure AD Connect directory synchronization tool.  When you’re dealing with small or newer on-premises environments, setting this all up is generally very smooth.  When things don’t go right, though, it’s very helpful to understand the anatomy of Hybrid Exchange objects.

Microsoft Exchange is tightly coupled with Active Directory

An Exchange mailbox is simply a collection of entries in the Exchange mailbox database.  The ‘mailbox’ is linked to an Active Directory (AD) user object, and much of the configuration for the mailbox is stored as attributes on this AD object.  In fact, almost all Microsoft Exchange recipient configuration information is stored in Active Directory– this includes distribution lists, contacts, etc.)  Some permissions, like Send-As, are stored in AD while other more frequently used permissions like Full-Access are stored in the mailbox database.

The Path to a Hybrid Exchange Mailbox

The best way to learn how something works is to dive right in and work with it.  In my hybrid lab, let’s walk through creating a new user and getting it provisioned for an Exchange Online mailbox.  This lab is running with Exchange 2016 and ADConnect for synchronization.

Creating a Test User

Normally you’d have an Identity Management system automatically provision you AD accounts for you, but for the purposes of learning I’m going to walk through the entire process.  From a computer with the ActiveDirectory PowerShell module installed, and connectivity to a domain controller, I’ll use the New-ADUser cmdlet to create the user.  The result of this will be a new user account object in the ‘Users’ container in AD.

New-ADUser -UserPrincipalName ‘hybridtestuser@domain.com’ -Enabled $true -Name ‘HybridTestUser’ `
-SamAccountName ‘HybridTestUser’ -AccountPassword $(read-host -assecurestring “Password”) `
-GivenName ‘Hybrid’ -Surname ‘TestUser’ -DisplayName ‘Hybrid TestUser’

Synchronizing to Azure AD

Now, at this point all we have is the object in AD and there is nothing configured for it for Exchange.  After ADConnect runs a synchronization cycle, the object will show up in Office 365 as a user.  To speed things up and ensure your changes are synchronized to Azure Active Directory quickly, you can target the same Domain Controller that ADConnect is configured to read from.  When using Verb-ADUser cmdlets, simply provide the -server parameter and give the FQDN of the Domain Controller.

If you’re wondering which Domain Controller your ADConnect is reading from, you can find that easily.

  1. On the server that ADConnect is installed on, open the Synchronization Service application.
  2. Click on the ‘Connectors’ button at the top left navigation.
  3. In the ‘Connectors’ pane, click the entry that corresponds to your Active Dorectory domain.
  4. In the Lower half of the screen you will see the name of the domain controller being used

Now that we know we’re targeting the same DC as the ADConnect service, we can initiate an immediate delta synchronization to push the user into Azure AD.  This isn’t a necessary step, I’m only doing it to break apart the creation of the user objects and then the creation of the Exchange mailbox.

To initiate an immediate Delta Synchronization, perform the following steps.

  1. From the ADConnect server, open PowerShell as administrator
  2. Run the following command

Start-ADSyncSyncCycle -PolicyType Delta

Now, in the Office 365 Portal I can see the account has shown up in the Active users section.

Creating a Hybrid Exchange Mailbox for the Test User

Now, you might be tempted to just go and license the user in Office 365 for at this point.  As you’d expect, this results in a mailbox being created in Office 365 and everything would probably seem fine, but it isn’t!  When you license for Exchange Online before the on-premises Exchange recipient has been configured, and that configuration has been replicated to Azure AD, you end up with an Exchange recipient that your on-premises Exchange environment is unaware of.  Meaning that any user with a mailbox on-premises wouldn’t see the new user in their Address List, and any mail flowing through the on-premises environment for the user would be bounced.

In order to get everything working properly you should use the on-premises Microsoft Exchange management tools.

Using PowerShell On-Premises to Provision a Mailbox in Exchange Online

  1. Open the Exchange Management Shell (EMS)
  2. Use the Enable-RemoteMailbox cmdlet to stamp the AD object with the Exchange attributes that make it a Remote Mailbox.

Mailboxes and Remote Mailboxes (MailUsers)

Now is a good time to explain what a remote mailbox is, right?  In a hybrid scenario, you will always have an object in the on-premises Active Directory and an object in Azure Active Directory.  The mailbox for HybridTestUser is hosted in Exchange Online and a copy of the user object is maintained on premises in the form of a MailUser with a targetAddress pointing to the @tenant.onmicrosoft.com address of the Exchange Online mailbox.  I can see this by using the Get-RemoteMailbox cmdlet in Exchange on-prem.

AD objects for mailboxes that exist in the on-premises Exchange environments are regular UserMailbox objects and the object in Azure AD is a MailUser with a target address of @domain.com.

The On-premises MailUser’s Attributes

The AD object has been stamped with some key attributes.  Here’s a screenshot of the current state of Exchange attributes on my test user.

proxyAddresses – Contains a list of email addresses that are valid for the recipient.  This can be different types of addresses; SMTP, x500, etc.
targetAddress – Used to forward mail to another address.  Local RemoteMailbox objects will have a targetAddress of the @tenant.onmicrosoft.com address.  Note, this property should be “SMTP:email@tenant.onmicrosoft.com.)  This is how Exchange on-premises knows where to send mail for Exchange Online mailboxes.
msExchRecipientDisplayType, msExchRecipientTypeDetails and msExchRemoteRecipientType – Defines the specific type of exchange recipient the AD object represents.  If you truly want to understand these attributes, you can read this excellent answer from answers.microsoft.com.  These are the attributes that kick off provisioning in Exchange Online.

Verifying the Mailbox Exists

My on-premises AD object now has the attributes which identify it as a remote mailbox and ADConnect will sync this to Azure Active Directory.  Next, a provisioning process will be kicked off to create the mailboxes in Exchange Online.  Again, you can speed this process up by using the steps outlined above.  In my test tenant, I can now see my Hybrid TestUser mailbox.  It is important to note that the mailbox exists and is functional, even though we have not licensed the Office 365 user.  It is now safe to license the user without fear of accidentally getting attributes out of sync.

To be continued…?