When you are in an Exchange hybrid configuration and you have migrated the last Mailbox to Office 365, you might wonder what to do with the last (couple of) Exchange server that is still running on-premises. Can you decommission your last Exchange server because all your Mailboxes are in the cloud? From a supportability point of view the answer is still “No, you can’t decommission the last Exchange server because you need it for management purposes” and most customers think this is disappointing. Let me explain why we still need this last Exchange server.
The source of authority is where your accounts are managed. In the old days (before the cloud) you had Active Directory and Exchange server and you managed everything locally. Users are created in Active Directory Users and Computers and Mailboxes are created in the Exchange Management Console or Exchange Management Shell. In this case, the source of authority is Active Directory, this is the place where you manage your accounts. You can change user properties like street address, phone numbers, extended attributes, Email addresses, hide from addressbook, and lots more.
In a cloud only situation, you don’t do anything with an on-premises Active Directory, everything is managed in the Microsoft Online Portal, Azure AD PowerShell or Exchange Online PowerShell. For example, for my home accounts I have a tenant in Office 365 with User accounts, Mailboxes, OneDrive for business et cetera with no Active Directory. Every object is managed in the cloud, so the source of authority is Office 365 (or better: Azure Active Directory). Accounts that have their source of authority are also known as cloud identities. You can identify cloud identities in the Microsoft Online Portal by the cloud icon in the Sync Status column as shown in the following screenshot:
User accounts are managed in the Microsoft Online Portal (but can be managed in the Azure Active Directory Portal as well) while the Mailboxes in Exchange Online are managed in the Exchange Online Admin Center. In the Exchange Online Admin Center, you can change Exchange specific attributes like Email addresses, mailbox quota, and hide from addressbook as shown in the following screenshot:
Important to remember: Everything is managed in the cloud, there is no interaction with anything on-premises.
When you have Azure AD Connect in place things become a little different. Accounts live in your on-premises Active Directory and their accounts are synchronized to Azure Active Directory for use with Office 365. The accounts in Azure Active Directory are what I call ‘read-only accounts’, and the official name is Synced Identities. You cannot make changes to these accounts online. If you add an email address in the Exchange Online Admin Center on a synced Identity an error message is shown:
An Azure Active Directory call was made to keep objects in sync between Azure Active Directory and Exchange Online. However, it failed. Detailed error message: Unable to update the specified properties for on-premises mastered Directory Sync objects or objects currently undergoing migration. The issue may be transient and please retry a couple of minutes later. If issue persists, please see exception members for more information.
Instead, you have to make these changes in on-premises Active Directory and then the changes are replicated by Azure AD Connect to Azure Active Directory. So, the source of authority when using Azure AD Connect is the on-premises Active Directory.
In the previous section I explained that for environments with Azure AD Connect the source of authority is the on-premises Active Directory. All changes are made here.
This also applies to information regarding Exchange Online recipients like Mailboxes, Mail Contacts or Distribution Groups. These are maintained in the on-premises Active Directory and synchronized to Azure Active Directory. A Mailbox in Exchange Online corresponds to a so-called Remote Mailbox in on-premises Exchange, and this is where the Exchange Online mailbox is maintained. You can see this in the Exchange Admin Center where Remote Mailboxes are identified as Office 365 in the Mailbox Type column as shown in the following screenshot:
So, even when all Mailboxes are in Exchange Online you still need this last Exchange server for managing the Mailboxes in Exchange Online.
Isn’t there a workaround for this issue with the last Exchange server? Yes, there is. But, it’s an unsupported solution and I typically do not recommend implementing this. If the last Exchange server is uninstalled, the properties for the Remote Mailboxes are kept in the on-premises Active Directory. Using a tool like ADSI Edit you can manage these properties.
When trying to add a new email address to a mailbox in Exchange Online (the same account as in the previous screenshot) using ADSIEdit you have to modify the proxyAddresses property as shown in the following screenshot:
Using ADSI Edit is possible and editing email addresses is probably the easiest property to manage. Other properties are more difficult to find and can give unexpected results if you are not 100% sure of what you are doing.
When all mailboxes are moved to Exchange Online you still need that last Exchange server on-premises for management purposes. When using Azure AD Connect (please note that this is not related to Exchange hybrid) the source of authority is the on-premises Active Directory. Changes to recipients in Exchange Online are made in Active Directory, and then synchronized to Azure Active Directory. Another advantage of this last Exchange server on-premises is that it can be used for SMTP relay purposes to mailboxes in Exchange Online.
You can use a tool like ADSI Edit to manually editing the recipients, but this is prone to error and not supported.
Microsoft is fully aware of this problem and working hard on a solution where this last on-premises Exchange server is not needed anymore. But until then we are still stuck with this last Exchange server.
Watch all aspects of your Exchange environment from a single pane of glass: client access, mailbox, and Edge servers; DAGs and databases; network, DNS, and Active Directory connectivity; Outlook, ActiveSync, and EWS client access.