Demystifying Exchange Online Provisioning: Architecture, Exchange Object Types, and Attributes

We wanted to demystify the process of syncing and provisioning of various recipient objects in Exchange Online. Some of this content might be already familiar to you but some will be new and will (hopefully) help you understand and troubleshoot most issues around Exchange objects provisioning.

Due to the extensiveness of the topic, this will be a series of blog posts instead of one, and to ensure there’s a way for everyone to understand the content, regardless of your experience, we will start with the basics.

Architecture Fundamentals

The simplest architecture when referring to Exchange on-premises is a ‘single forest’ topology, where you have your local Active Directory (AD) and the Microsoft Exchange organization in the same forest. Therefore, we have a single user object that is also Exchange-enabled.

Exchange Online has a separate instance of Active Directory like the concept of Resource Forest topology (which we are going to refer to as Exchange Online Directory Services) and differs from the single forest topology because Entra ID (formerly Azure Active Directory) is where authentication takes place for all user accounts. This means we have two Active Directories and therefore two user objects.

User accounts (and other mail-enabled objects) are synchronized between Entra ID and Exchange Online using processes known as ForwardSync and Dual Write. Objects in Exchange Online are linked to the ones in Entra ID via the ExternalDirectoryObjectID property that will contain the value of the ObjectID of the associated user account in Entra ID.

You will find that a similar design also applies to other workloads like SharePoint Online, Teams, and so on…

Now let’s introduce the Microsoft Exchange hybrid environment as a new element. A Microsoft Exchange hybrid environment can be quickly defined as a relationship between 2 Microsoft Exchange organizations with a synchronization between an on-premises Active Directory and Entra ID in place. Thanks to the magic of the Hybrid Configuration Wizard (HCW), this will behave as one organization.

HCW isn’t the only thing that makes a hybrid environment work. In fact, HCW will only configure both Exchange organizations to trust each other in many aspects to ensure that the different features work, but we still need the recipient objects to be synced between the two.

For that synchronization to take place, you need one more element in your topology, and that is Microsoft Entra Connect (this component changed its name several times, so you might know it as DirSync, AAD Sync or AAD Connect). Microsoft Entra Connect ensures that your objects are synced between your on-premises Active Directory and Entra ID. With the ‘Exchange Hybrid’ optional feature enabled (checked during the Microsoft Entra Connect configuration) we ensure that all of the Exchange properties any object might have, are included in the sync as well. From there, they are then automatically synced to Exchange Online Directory Service thanks to the ForwardSync and Dual Write processes we already mentioned.

So, ForwardSync and Dual Write form the synchronization engine we have in the service to keep the Entra ID and the Exchange Online Directory Services objects in sync, just like Entra Connect does. However, there’s a difference: while Entra Connect pushes changes to Entra ID, ForwardSync technically doesn’t push the changes from Entra ID to Exchange Online Directory Services, instead Exchange Online Directory Services will periodically query Entra ID and see if there are any changes that need to be synced, and if so, it will sync them.

Here's a visual summarizing of all the pieces working together:

Object Types

Microsoft Exchange isn’t just about mailboxes, it also handles other objects like plain users that aren’t mail enabled, Mail-Enabled Users, groups, contacts, etc.

However, Exchange Online and Exchange on-premises differ in object types, and you may find some of them only available in one of those environments. Consider the image below as a summary where the left side shows Exchange on-premises object types, and the right side shows the Exchange Online ones:

While you can have a plain user on both sides, you are not going to find a remote mailbox object type in Exchange Online (at least not exposed to tenant admins), but you will in Exchange on-premises. The same applies to the Microsoft 365 Group showing up as a unified group in Exchange Online, while in Exchange on-premises it does not.

Another thing to consider is that even though you see the dynamic distribution groups on both sides, they are not synced by Entra Connect. Those in Exchange Online are pure cloud objects. The reason for this is quite simple. Dynamic distribution group membership is based on a particular filter, and if a dynamic distribution group was to be synchronized with the same filter, the membership would be different on both sides.

What defines the object type we might have on one side or the other? The answer is – attributes. Depending on the Microsoft Exchange Server version on-premises, one object might have more attributes than another.

Among the many attributes that make an object healthy, there are 3 specific ones that will define the object type, and those are the msExchRecipientDisplayType, msExchRecipientTypeDetails and msExchRemoteRecipientType, which will map to RecipientType, RecipientTypeDetails and RemoteRecipientType properties respectively. You’ll see those when you run cmdlets such as Get-Recipient, Get-MailUser or Get-RemoteMailbox:

Now that we’re talking about attributes: did you know that the only supported methods for creating or modifying an Exchange object are through Exchange Management Shell (EMS) and the Exchange Admin Center (EAC)? We don’t even support Set-ADUser even if it’s run from the EMS (unless explicitly under supervision of Microsoft support). The reason is because Set-ADUser, attribute editor, ADSIEdit or any 3rd party tool will just stamp the value you want on a specific attribute without validation while EMS and EAC will check if the value you’re attempting to stamp on a property is valid or in use by another object (email addresses are a perfect example). They will also make sure that any other required attributes are also changed (for example, enabling an archive by just stamping the ArchiveGuid is not everything that is needed to have archive working).

We are not going to go through all the mappings here, but you can see the most relevant ones below:

• A MailUser in Exchange on-premises can either be a MailUser or a UserMailbox in Exchange Online (depending on whether it has an Exchange Online license assigned or not).
• A RemoteMailbox object in Exchange on-premises is a sub-type of MailUser, however you won’t be able to list it by running a Get-MailUser. Use Get-RemoteMailbox instead. Ideally, you would end up seeing it as a mailbox in Exchange Online. Speaking of which, remember that not all mailboxes need to be licensed (shared or resource mailboxes), but regular mailboxes do, and if they don’t have a license assigned, you might not be able to see them as mailboxes, but as MailUsers instead. We’ll talk about this later.
• You won’t see the Dynamic Distribution Groups being synced from Exchange on-premises to Exchange Online, so if you see a Dynamic Distribution Group on either side, that means the object is not synced but created on that side only, so don’t expect any changes applied to it to sync on the other.
• Regarding Microsoft 365 Groups: Exchange on-premises doesn’t know about them at all, but if you have the Entra Connect Group Writeback feature enabled, it will create a mail-enabled Universal distribution group in Exchange on-premises for each Group. This is an optional feature you’ll have to manually enable in Entra Connect.

Provisioning

Let’s now jump into how provisioning works for the different object types in Exchange Online.

The easiest way to explain this is with Distribution or Security Groups. Let’s say you create a group with 3 members on-premises, and once Entra Connect syncs, it will be pushed to Entra ID and from there to Exchange Online Directory Services via Forwardsync/DualWrite. Sounds easy, right? Synchronizing a group with 3 members will go through sub-steps on Entra ID. One of them is called ‘normalize’, and that step will make sure to break one task into simpler ones.

Taking the group I just mentioned, the single operation will break into 2 different tasks: the group creation and adding the members to it. Adding members will also break into 3 actions, one for every user to be added add as a member of the group.

Provisioning mailboxes – things to note:

Source of Authority

Before we even start talking about mailbox provisioning in a Microsoft Exchange hybrid environment, we must understand the main advantage of this environment is to be able to create and manage all identities on-premises. To avoid falling into conditions where the same object could be updated in different directories, there must always be a side that will prevail over the other. This is known as Source of Authority (SOA) and in this environment type (hybrid, with Entra Connect synchronizing Exchange attributes) your on-premises directory will be the SOA (with very few exceptions). Keep this in mind from now on, as that will be key to understand certain behaviors.

30-day grace period

Whether we provision a new remote mailbox on-premises or migrate a mailbox that never had an Exchange Online license to Exchange Online, the service will allow a period of 30 days for the admins to assign an Exchange Online license to the user. Note that this is not a way to get 30 days of service for free, but to help customers with their own provisioning defined processes and give them some time to assign an Exchange Online license to a regular mailbox instead. Our recommendation is to ALWAYS assign a license as soon as you see the mailbox provisioned in Exchange Online, and in migration scenario, even before the move is injected.

Remote Routing Address and other properties

The next thing to know about is who is responsible for stamping the remote routing address (this is the @YourDomain.mail.onmicrosoft.com) on an Exchange on-premises recipient. Exchange on-premises will always be the one responsible for this depending on the following scenario:

• For all users using Exchange on-premises:

The default email address policy is modified by the Hybrid Configuration Wizard (HCW) to include the YourDomain.mail.onmicrosoft.com address as a secondary address for all on-premises recipients. If this Email Address Policy is enabled, there’s no other policy with a higher preference that would match the object, and of course the recipient EmailAddressPolicyEnabled property is set to ‘True’, the address will show up under the ‘EmailAddresses’ property of the user (which maps to the ‘proxyaddresses’ AD attribute).

• When a mailbox gets migrated to Exchange Online:

The ‘ExternalEmailAddress’ property for the on-premises user (which maps to ‘TargetAddress’ AD attribute) will be stamped with the remote routing address value (which should be present already in the EmailAddresses for the given user) by the Mailbox Replication Service (MRS) once the hybrid migration of on-premises mailbox completes.

• When a remote mailbox is being provisioned from on-premises:

Regardless of how you provision the remote mailbox (either using the Enable-RemoteMailbox, New-RemoteMailbox or the EAC) you need to specify the ‘RemoteRoutingAddress’ mandatory parameter with the YourDomain.mail.onmicrosoft.com address, and this will be shown on the ExternalEmailAddress property and under EmailAddresses as a secondary address when you run the Get-RemoteMailbox cmdlet from your Exchange on-premises.

The remote routing address is important as it will allow other Exchange-related services like Autodiscover, Hybrid Mailflow (Transport) or Free-busy requests to be redirected to Exchange Online.

Now, don’t confuse the remote routing address (YourDomain.mail.onmicrosoft.com) with the Microsoft Online Email Routing Address - also known as MOERA - (YourDomain.onmicrosoft.com). While the remote routing address is stamped by Exchange on-premises, the MOERA will be stamped by Entra ID, except when you create the user in Entra ID directly without an Exchange Online license assigned at that very moment) in which case no MOERA will be stamped on the object).

Another important property is the LegacyExchangeDN which will be written back to the on-premises remote mailbox object as an X500 address when you have a mailbox in Exchange Online that is synced from on-premises.

The ExchangeGuid will be generated by the Microsoft Exchange organization that first creates the mailbox:

• Exchange Online if the mailbox was provisioned from on-premises by running the New-RemoteMailbox, Enable-RemoteMailbox from the on-premises Exchange Management Shell, or creating an Exchange Online mailbox from the Exchange Admin Center.
• Exchange on-premises, if you create a mailbox locally and then decide to migrate it to Exchange Online.

The ArchiveGuid property will always be generated by Exchange on-premises regardless of what Exchange organization will be hosting it (on-premises or online), and this will be synced to Exchange Online.

Any provisioning or changes in Exchange Online can take up to 24 hours. We do a very good job trying to make those almost instantly, but sometimes we may see some delays due to resources being consumed more than usual. See this article for more information and a link to a self-serve diagnostic to help you further.

And with that, we come to the end of part 1 of the provisioning series articles. Stay tuned for part 2!

Alberto Pascual Montoya and Ben Winzenz