After completing a migration to Exchange Online, it is common to have questions like:
1) What is the best practice for provisioning mailboxes?
2) How do I provision mailboxes?
3) Why should I keep this Exchange server around?
Well, these are good questions. Let’s start with the last question. When an organization migrates to Exchange Online, it is quite commonly thought that Exchange is no longer needed on-premise. From a deeply technical perspective, this is true… but it is a bad idea. As a matter of fact, it is such a bad idea that I wrote a very blunt response to another blog post suggesting that keeping hybrid in place is not really necessary. Well, if you want to live in a world where you are maintaining your own tools, have only skilled individuals provisioning mailboxes, or you have lesser skilled folks poking around directly with Active Directory attributes, knock yourself out. Also, this doesn’t apply to organizations that don’t synchronize their on-premise Active Directory to Azure AD. For those that want to limit their heartburn and remain in a supported configuration, however, you must not only keep an on-premise Exchange server, but also keep it in a hybrid configuration.
Microsoft goes a long way to explain it in their article: How and when to decommission your on-premises Exchange server in a hybrid deployment.
The problem is that this article is buried deeply out there in the web and very hard to find. Microsoft doesn’t make this very well known because this information is hard to find. Here is the basic summary: You need to keep an Exchange server around on-premises in hybrid not because of Exchange, but because of directory synchronization. AAD Connect (and its predecessors AAD Sync and DirSync) is built on what is now know as Microsoft Identity Manager 2016. This is a metadirectory product that helps to synchronize and provision identities. While there can be some bi-directional synchronization of attributes, there has to be an ultimate source of truth. This means that when you are synchronizing to Azure AD, your on-premises Active Directory is that source of truth. Users must be provisioned there and many attributes must also be maintained there. Since these objects, like mailboxes, distribution groups, and mail contacts, must exist in on-premises Active Directory, it makes sense to have an administrative interface. One could manually edit the attributes like ProxyAddresses and know that the primary SMTP address should be meet the following requirements:
1) Be prefixed with “SMTP:”
2) Be unique throughout your organization
3) Have its value saved to the Mail attribute
Other values in ProxyAddresses should be prefixed with “smtp:” or their address type prefix. Because of these challenges, Microsoft has made it a support requirement that Exchange remain on-premises. In fact, they have made it easier by giving all enterprise Office 365 customers a free license key for use with hybrid co-existence servers.
Aside from the support requirement, there are plenty of reasons to keep an Exchange server on-premise. First, it makes support magnitudes more simple. You can use the on-premises RBAC model and grant support staff the rights to provision recipients from your Exchange system without even granting rights to Office 365 or Exchange Online administratively. Another big reason is that Exchange Online does NOT have Email Address Policies. By maintaining a hybrid co-existence server, Email Address Policies can be established and executed there and the subsequent AD writes will be synchronized to Azure AD, this giving you Email Address Policies for Exchange Online recipients. Finally, many time you need to relay mail from on-premises devices and applications; this is far easier if it is done centrally from a server on-premises that is granted relay rights through Exchange Online. This simplifies firewall rules and keeps the configuration within Exchange Online to a minimum. This relay point may as well be the hybrid co-existence server that you should already have. Servers with hybrid co-existence perform Exchange Authentication and have a privileged existence from the standpoint of spam filtering. Finally, if you take the server out of the topology by not keeping it in hybrid configuration, you lose access to many of the cmdlets and web interface means to properly provision recipients in Exchange Online.
Now we know why we should maintain this server, but how do we effectively utilize it? Well, it is not a walk in the park unless you are well-acquainted with Exchange Management Shell. Microsoft has been very inconsistent about its tools. In the web interface, you can create a User Mailbox in Exchange Online from your on-premises server if you create a new Active Directory user account at the same time, but you cannot use an existing user account. Also, Microsoft makes it easy to create Equipment and Room mailboxes, which are types of Shared mailboxes, but not Shared mailboxes themselves. Microsoft recommends that you create a Shared mailbox on-premises and migrate it to Exchange Online. This is just bad, Microsoft… you should fix this and make it work well and consistently.
Here is my cheat sheet for provisioning mailboxes and it requires Exchange Management Shell connected to the on-premises environment. These commands count on existing AD user objects. Let’s assume that we have the following AD user objects for which we must create Exchange Online mailboxes with their intuined types:
User Mailbox (AD user object name: “User Mailbox”):
- From Exchange Management Shell: Get-User “User Mailbox” | Enable-RemoteMailbox -RemoteRoutingDomain TenantName.mail.onmicrosoft.com
- Wait for a sync cycle or manually synchronize from AAD Connect: Start-ADSyncSyncCycle -PolicyType Delta
Room Mailbox (AD user object name: “Room Mailbox”):
- From Exchange Management Shell: Get-User “Room Mailbox” | Enable-RemoteMailbox -RemoteRoutingDomain TenantName.mail.onmicrosoft.com
- From Exchange Management Shell: Get-RemoteMailbox “Room Mailbox: | Set-RemoteMailbox -Type Room
- Wait for a sync cycle or manually synchronize from AAD Connect: Start-ADSyncSyncCycle -PolicyType Delta
Equipment Mailbox (AD user object name: “Equipment Mailbox”):
- From Exchange Management Shell: Get-User “Equipment Mailbox” | Enable-RemoteMailbox -RemoteRoutingDomain TenantName.mail.onmicrosoft.com
- From Exchange Management Shell: Get-RemoteMailbox “Equipment Mailbox” | Set-RemoteMailbox -Type Equipment
- Wait for a sync cycle or manually synchronize from AAD Connect: Start-ADSyncSyncCycle -PolicyType Delta
Shared Mailbox (AD user object name: “Shared Mailbox”):
- From Exchange Management Shell: Get-User “Shared Mailbox” | Enable-RemoteMailbox -RemoteRoutingDomain TenantName.mail.onmicrosoft.com
- Wait for a sync cycle or manually synchronize from AAD Connect: Start-ADSyncSyncCycle -PolicyType Delta
- From Exchange Online PowerShell: Get-Mailbox “Shared Mailbox” | Set-Mailbox -Type Shared
That’s it. Distribution groups are created on-premises just like normal and members added from on-premises. Mail contacts are also created just like normally on-premises. Each of these synchronize properly to Azure AD.
Ensuring that you properly provision your mailboxes on-premises means that messages relayed from on-premises devices and applications do not get NDRs and that email addresses get assigned via policies, reducing the opportunity for human error. One thing to keep note of is that Shared mailboxes are still inconsistent from the rest; they are created as regular mailboxes and then converted to Shared mailboxes in Exchange Online directly. I wish Microsoft would change this as it is possible… if you manually set the msExchRecipientDisplayType and msExchRecipientTypeDetails attributed to the proper values, they will be provisioned in Exchange Online properly, but this should be a requirement.
Dustin Dortch 