For some customers after a migration from on-premises Exchange Server to Exchange Online there is a desire to completely decommission the on-premises Exchange servers. Whether it can actually be done will depend on a few different things.
At the beginning of an Office 365 project I like to discuss with the customer what they need for their long term identity model. I start with identity, even though some customers want to jump straight to how mailboxes and other data will be migrated, because the identity model is a big factor in determining the best migration method. The discussion usually comes down to one of two scenarios:
- The customer plans to retain the on-premises Active Directory for other requirements, and wants directory synchronization and password hash sync so that users have a single set of credentials to remember for authenticating to Office 365 cloud services
- The customer has no intention of retaining the on-premises Active Directory and doesn't need directory synchronization
The key here is the use of directory synchronization. Microsoft has published guidance on TechNet for decommissioning on-premises Exchange in a hybrid deployment. The title is a bit misleading because it's not the hybrid configuration that ultimately determines whether you can decommission on-premises Exchange or not.
When directory synchronization is enabled for a tenant and a user is synchronized from on-premises, most of the attributes cannot be managed from Exchange Online and must be managed from on-premises. This is not due to the hybrid configuration, but it occurs because of directory synchronization. In addition, even if you have directory synchronization in place without running the Hybrid Configuration Wizard, you still cannot manage most of the recipient tasks from the cloud.
The article links to an older blog post that was written in the Exchange 2010 era, but still applies to later versions of Exchange.
For organizations intending on keeping DirSync in place and continuing to manage user accounts from the on-premises organization, we recommend not removing the last Exchange 2010 server from the on-premises organization. If the last Exchange server is removed, you cannot make changes to the mailbox object in Exchange Online because the source of authority is defined as on-premises. The source of authority refers to the location where Active Directory directory service objects, such as users and groups, are mastered (an original source that defines copies of an object) in a hybrid deployment. If you needed to edit most mailbox settings, you would have to be sure the Active Directory schema was extended on-premises and use unsupported tools such as Active Directory Service Interfaces Editor (ADSI Edit) for common administrative tasks.
To summarize the two quotes above, if you have directory synchronization in place, then you need to manage the mail attributes of users, groups, and contacts in the on-premises Active Directory, and then allow those changes to synchronize to Azure Active Directory. And the only supported way to manage the mail attributes on-premises is using the Exchange management tools, which requires at least one Exchange server to be running.
So where does that leave customers? Here's a few scenarios to consider:
- If you need directory synchronization, a cutover migration is not a good choice. I am no fan of cutover migrations in general, but in particular for directory sync scenarios it is very difficult to retrofit directory synchronization after completing a cutover migration. Better to choose a migration method that utilizes directory sync up front.
- If you need directory synchronization, strongly consider using a hybrid configuration to facilitate the migration to Exchange Online and the ongoing management. Hybrid requires a little more work to set up at the beginning, but offers a far better admin and end user experience during the migration of mailboxes to the cloud. Yes, you will retain the on-premises Exchange server, but you can downsize it to the minimum hardware spec or run it as a small VM.
- If you need password synchronization for ease of user login, but don't need sync of other Active Directory attributes, then consider using the Windows Server Essentials role. Essentials supports up to 100 users and allows you to link on-premises users with Office 365 users so that on-premises password changes are automatically synced with Azure Active Directory. An on-premises Exchange server is not required for Essentials-based integration with Office 365. This solution is ideal for customers who need to retain Active Directory on-premises, perhaps for just a few requirements like a legacy app that won't run in the cloud. I've migrated former SBS customers to Essentials-based solutions and it works fine.
What if you absolutely insist on removing Exchange but keeping directory synchronization running? For those scenarios you've probably found some third party tools, or someone who tells you that it works just fine and all you need to do is write some scripts or use ADSIEdit. Yes, from a technical perspective it's possible. But using anything other than Exchange to manage mail attributes in Active Directory is not supported by Microsoft, and I'm not in the habit of promoting unsupported solutions.
In all of the above I haven't gone into complex scenarios, nor have I mentioned AD FS. For customers with a lot of complexity or who have federation requirements I generally find that they have already learned and accepted the requirements for on-premises Exchange Server in certain scenarios. The advice above is mostly for the small to mid-size customer who feels the need to remove all on-premises Exchange servers to reduce their management overhead.
Maybe one day it will be possible, but not for now.