Decommissioning On Premise Exchange 2010 and Office 365 Hybrid Environment
Late last year, Microsoft made changes to Office 365 which broke the ability to manage an Office 365 hybrid environment via Exchange 2010 management tools (the Exchange Management Console aka EMC). Most likely, this was due to the behind the scenes upgrade to Exchange 2016 underlying the Exchange Online offering in Office 365.
In response to these changes, customers are decommissioning on premise exchange 2010 and Office 365 hybrid environments.
This blog will drill into the changes that were made, how to plan for a hybrid decommissioning, and common questions that are asked.
One of the great benefits of Office 365 is that Microsoft rolls out the latest and greatest server-side software to their cloud before they release it to the general public. But there’s a dark side to this practice when unforeseen consequences impact the Office 365 user base.
If you migrated to Office 365 in the past 3-5 years and elected to deploy Exchange 2010 hybrid servers, then you might be seeing something like this when you try and connect the on premise EMC to your Exchange Online tenant (“object does not match target type”):
I won’t bore you with the Google analysis and Office 365 Service Health Dashboard digging that was required to figure out why this was all of a sudden happening. Suffice to say that Microsoft posted an update to an Exchange Online service issue stating the following:
"Although engineers took the precaution of investigating Exchange Management Console (EMC) functionality, it was determined that the EMC is not the appropriate tool to manage cloud-based mailboxes. Administrators are instructed to use the Exchange Admin Center (EAC) or Exchange Management Shell (EMS) for any Exchange Online management scenarios."
What they’re really saying is: Exchange 2010 EMC isn’t going to cut it anymore, you need to start using Exchange 2013 management tools (the Exchange Admin Console aka EAC) to manage your hybrid environment and cloud users. Of course, you can’t just install Exchange management tools alone, you have to install a full blown Exchange server in order to get a functional EAC.
Deploying on-premise Exchange servers isn’t something that should be taken lightly: there are a lot of moving parts, and planning is required.
Planning your hybrid decommission
Chances are that you’ve finished migrating all mailboxes to Office 365 a long time ago, so the hybrid co-existence environment is not serving a real purpose any longer.
Creating new users, managing mail flow, and performing other administrative tasks are more complex in a hybrid environment, so if all your mailboxes and data are already in the cloud, let’s talk about decommissioning your hybrid environment.
Each environment is unique considering the number and version of on-premise Exchange servers, identity management (FIM, DirSync, AADSync, AADConnect), authentication (Single Sign On, Same Sign On, ADFS, Password Sync), etc. Microsoft provides good high-level guidance based on different scenarios here:
But, not every environment fits nicely into one of their documented scenarios, nor do they provide in-depth guidance on hybrid decommissioning. Let’s start from the 30,000-foot view though and look at planning. You will need to consider at least the following areas as part of your hybrid decommission plan:
- Any remaining mailboxes, public folders, or other on-premise Exchange data
- Mail flow and DNS records (MX)
- SPF DNS record
- On-premise mail relay requirements
- Autodiscover DNS records and Service Connection Points (SCP)
- DirSync / Azure Active Directory Sync (AADSync) / Azure Active Directory Connect (AADConnect) upgrade
- Exchange Server 2013 or 2016 deployment (for user management)
- Hybrid relationship removal and cleanup
- Legacy Exchange Server 2010 (or earlier) removal and cleanup
If you are currently using ADFS for Single Sign On, there are additional steps to leverage AADConnect Password Synchronization for Same Sign On. While this doesn’t provide true SSO, it greatly simplifies your Office 365 deployment and troubleshooting, not to mention reduces reliance on your own on-premise or co-located servers.
There are usually a few common questions that come up during a hybrid decommissioning planning conversation.
Common questions during hybrid decommissioning
Why do I need to keep any Exchange servers on premise? I would love to completely eradicate my on-premise Exchange environment.
This would be very nice, but the fact is that if you’re using a directory synchronization tool (which should be AADConnect), then you must maintain at least one on premise Exchange server in order to manage your cloud user objects. This doesn’t mean that Exchange is a pre-requisite for AADConnect or other directory sync tools, it’s not and AADConnect will run just fine without Exchange. What it does mean is that you will have a very difficult time managing Exchange attributes for your cloud users (i.e. SMTP/proxy addresses, hide from GAL, mail nickname, etc.) using only ADSIEdit as the alternative to proper Exchange management tools. Most importantly, Microsoft does not support the use of ADSIEdit in this scenario. There are many benefits to using a directory synchronization tool that I won’t go into right now, but most organizations will continue using directory sync (AADConnect) after a hybrid decommissioning project.
What does the Hybrid relationship between my on-premise Exchange organization and my Office 365 tenant really consist of?
Hybrid is basically four pieces: 1) Mail flow connectors; 2) Autodiscover records pointing at your on-premise Exchange servers; 3) Organizational relationships to control information sharing; and 4) AD objects which contain the hybrid configuration. A misconception is that there are actually “hybrid” Exchange servers. Actually, there are just specific mail connectors (that can exist on any number of Exchange servers) and MRS endpoints to aid in mailbox migration (that can exist on any number of Exchange servers). Autodiscover in a hybrid deployment works the same way as a non-hybrid deployment. However, when you’re thinking along the lines of decommissioning, the two main and significant changes you will make are pointing your MX records and Autodiscover records to Office 365. This effectively sends all traffic around your hybrid deployment. At that point, assuming you’ve completed all your other prerequisites, you can proceed with removal and cleanup of hybrid mail flow connectors, Service Connection Points, hybrid objects in AD, and organizational relationships.
Whether or not you’ve been bitten by the sudden lack of Exchange 2010 management tool support or not, hybrid decommissioning should be on your IT to do list if your Office 365 migration project is complete and your organization is living happily in the cloud.