Migrating Exchange to the Cloud? You'll Want to Keep One Server On-Prem

When you decide to move your Exchange environment to the cloud, you might be confused to discover that you still need to maintain an on-premises Exchange server. There are several reasons for this, stemming from the migration process and on to Identity Management.

If you’re moving from an active on-premises Exchange deployment, you’ll first configure an interim “Exchange Hybrid” environment which hosts mailboxes within Exchange Online and your local Exchange server. The two locations share namespace, address books, free-busy, calendars, really every Exchange functionality is synced between them. Mail flow and other functions appear to be internal, but might actually be processed and stored in the cloud environment.

When you create a mailbox in Exchange, you’re creating a user or group entry in Active Directory (AD) as well, with its associated attributes like the e-mail address itself, permissions, version numbers, really any associated account data. Those attributes create an Identity Management problem once you have moved your Exchange mailboxes and data to the cloud, because your AD attributes are still living locally. You probably know this already because you had to use Azure Connect to sync AD to Azure AD.

The “source of authority” is your on-premise AD server in this scenario and all AD attributes remain read-only within Azure. That means that you can only update or change AD attributes on-premises. From there, Azure AD Connect syncs to Azure AD, which in turn “backsyncs” to Exchange Online Directory Service (EXODS).

But what about after you’ve already moved all your mailboxes to the cloud?

You’ve gotten rid of your last Exchange Servers on Premise and are no longer running in Exchange Hybrid. So why keep a local Exchange server running?

Simply put, most of your attributes in AD are still read-only on Azure AD. If you try and modify them from your cloud Exchange servers and Azure AD, there is no way to change them. You probably would need to develop a script to help you make successful batch edits. You can’t use native Exchange/AD management tools to make changes, you instead must go into each record manually and know where and how to change attribute. There are limited attributes whose source of authority can be transferred to the cloud, but the vast majority are best maintained from an on-premises server.

Now you don’t need to maintain the same type of Exchange server. You can use a VM with fairly limited resources as this is strictly left in place for ongoing AD management and sync to the cloud.

There are some benefits to maintaining a simple Exchange server on-premise even as the bulk of your mailboxes and data move the cloud, as well. You can use the remaining server as an SMTP relay for all network-connected devices that send email, so you don’t have to configure firewall settings for each and every one of them. Think of the workstations, printers, scanners, even applications and SQL servers, really anything that needs to send mail — this can really help you streamline admin.

What if you want to go cloud-only?

It’s certainly possible. You must first remove the synchronization server, which will make all objects editable in Azure AD. Meanwhile your local AD will begin to suffer drift, if you’re still using it, with attributes changing online but not locally and vice versa. You can’t use it as a relay or enforce some specific policy attributes, like e-mail address formats.

Need help navigating the move to O365 or a cloud-hosted Exchange server? Green House Data can help with fully managed O365 or a one time consulting project.