It may surprise you to hear that if you are running a supported version of Exchange Server, you don’t need to install an Exchange Hybrid Server. Sure – many of your reading this will be wondering why I’m even stating the obvious, but a significant number of consultants and IT professionals configuring Hybrid for an Exchange migration to Office 365 install an additional server (or two) to support a Hybrid migration. To clear things up, here’s five reasons why you shouldn’t do this.
Exchange 2010 and newer already have Hybrid baked in
The most clear and obvious reason for not installing an Exchange Hybrid server is that you already have one – or probably, more than one! Exchange Server 2010 was built for Office 365, and served as the foundations for Office 365 in it’s earlier form, Live@Edu and the launched version of Exchange Online. By Exchange 2010 Service Pack 3, Hybrid was – and is – similar to what you see and use today.
The Office 365 Hybrid Configuration Wizard supports Exchange Server 2010 and works well to support migrations to Exchange Online. Millions upon millions of mailboxes have been migrated straight for Exchange 2010 to Exchange Online without additional “Hybrid Servers”.
The same goes for newer versions – whether you run Exchange Server 2013, 2016 or 2019 – you won’t see additional benefits from adding a newer version of Exchange Server. Areas like Microsoft Teams integration with Exchange 2016 and 2019 won’t become available to your mailboxes on Exchange 2013 – you’d need to move all mailboxes to the newer version of Exchange – so installing a newer version with the hope of seeing additional benefits will provide a fruitless task.
Installing an Exchange Hybrid Server won’t provide you better performance or flexibility
If you’ve got issues with your current Exchange implementation, then fix those issues if you don’t believe it will survive a migration. That might mean adding additional capacity if it already has far too little – but it might actually be the case that migration to Exchange Online will relieve stress on the current environment. Expanding the environment on-premises will involve mailbox moves, so potentially your better option might be migrating them straight to Exchange Online rather than to a so-called staging server first.
Additionally, if the hope is to offload migration load to “Hybrid Servers” by putting these as the egress point for migrations, you might be disappointed. Supposing you add an Exchange 2016 server in front of your Exchange 2010 Client Access Servers and DAG? The mailbox moves will still reach back to the Exchange 2010 servers, and naturally pull mailboxes from their storage, providing little or no benefit. You should not see any difference in user impact compared to a direct migration – and Exchange 2010 will throttle the Mailbox Replication Service to ensure that user access remains the highest priority.
From a networking perspective, sometimes people suggest that adding an Exchange 2016 server to publish services to the internet will provide them the flexibility they demand. In nearly every single situation this isn’t the case. Exchange Servers – whether these are your existing Exchange 2010 servers or additional “Hybrid” servers must have no firewall rules blocking communications between other Exchange Servers or Active Directory domain controllers. There isn’t a particular use-case for being able to install Exchange Servers within a DMZ. Instead, consider revisiting your load-balancer or reverse proxy configuration to publish the existing servers correctly. You’ll no-doubt need to do this if you install Exchange 2016 servers, anyway.
Adding a newer version of Exchange is quite complex
I know that for the purposes of “installing a Hybrid Server” you can get away with installing a newer version of Exchange Server into the environment, and then carefully avoid this from being accessed by clients, so that they access the current version of Exchange.
However, the correct way to install a newer version of Exchange includes moving your client access namespaces across to the newer version of Exchange. This generally means that you’ll see external client access, such as Outlook on the web, Outlook Anywhere, ActiveSync and Exchange Web Services – as well as AutoDiscover – reach your Exchange “Hybrid” servers and either respond to requests, or proxy them back to your older servers.
By adding a newer version of Exchange Server to your organization properly you are effectively preparing for coexistence prior to an Exchange upgrade. Granted – you haven’t had to size servers to host mailboxes, but effectively you should be in a position where everything – be it client access, or mail flow, is moved to touch your Exchange “Hybrid” servers first. This adds risk to client access and additional testing steps in line with an on-premises upgrade.
You don’t need to do this if you use your existing Exchange Servers to configure Hybrid – so why put yourself through it?
You’ll provide yourself with more areas to troubleshoot
It goes without saying that the more moving parts – the more components there are that can go wrong. With a normal Hybrid migration, you will more than likely perform some troubleshooting. You will most likely check the Migration Batch logs in Exchange Online, you will most likely check and investigate potential issues with free/busy or mail flow. During the migration itself, you might need to troubleshoot issues.
In most migrations, that might mean that you need to troubleshoot firewall configuration, load balancer configuration or NAT rules, view IIS and event logs – even with a single Exchange 2010 server. It goes without saying that your steps for troubleshooting almost every issue will involve an extra step. Most requests will eventually be received by your existing Exchange Servers – so you will need to troubleshoot issues within the Exchange “Hybrid” environment and trace those back through to corresponding older Exchange Servers. Don’t make life harder for yourself.
By the time you’ve installed your “Hybrid Server” you could have been moving your first mailbox
I hate stating this because it’s not true in every situation. There are many organizations that spend so long thinking about how they might move mailboxes that you could have moved them to a newer version of Exchange, let alone installed a few Exchange “Hybrid” servers. They are few and far between though and the issues are primarily down to the organization and not technical reasons.
For most organizations, the technical aspects of moving from not being able to migrate a mailbox to Exchange online to actually being able to move a mailbox are actually pretty straightforward. Forgetting Outlook versions, client access, and mail flow (which you’ll deal with “Hybrid” server or not) technically moving a mailbox from Exchange on-premises to Exchange Online isn’t all that complicated.
At a real push, enabling and publishing the MRSProxy service an stamping a few objects in Exchange Online and on-premises correctly is enough to grease the wheels to move a mailbox. And once the pre-requisites are configured correctly, executing the Hybrid Configuration Wizard and implementing the correct configuration to your Exchange Online environment to support your needs isn’t much of a stretch.
The majority of the complex supporting work in regulated industries or customers with complex compliance requirements is near identical and still needs to be done whether they installed an Exchange “Hybrid” server or not – except that work to add in a newer version of Exchange to “support Hybrid” could have been avoided if they realised what they had already was good enough to support their migration.
What happens when you decommission Exchange?
At the time of writing, May 2020, after your migration it is unlikely you will decommission Exchange Server entirely. Most organizations will use Azure AD Connect to synchronize their on-premises identities to Azure AD & Office 365. This means they have Hybrid Identity, which means they need to keep at least one Hybrid-enabled Exchange Server.
Microsoft are planning, later this year, to release capabilities to allow you to remove the last Exchange Server, but even if you could, you still might need an Exchange Server on-premises. If you need to relay email from application servers, photocopiers or other systems, then you might want to keep an Exchange Server (or two) on-premises to server as an unauthenticated SMTP relay into Office 365.
Therefore, once you have migrated all your mailboxes there is an excellent case to replace older Exchange 2010 or 2013 servers with one or more Exchange 2016 servers (there’s no free Exchange 2019 “Hybrid” licence), enabled for Exchange Hybrid. These servers will not need to serve clients, but will serve as a management server – the place you’ll enable new Office 365 mailboxes and change details such as email addresses that are mastered within the on-premises Active Directory. Some people suggest that it’s somehow easier to implement “Exchange Hybrid” servers at the beginning of the migration due to this. They are wrong. It’s much easier to implement a newer version of Exchange into your environment for longer term management once clients no longer access the environment and all the mailboxes have been migrated!
Steve is a Microsoft MVP for Office Servers and Services. He enjoys getting hands-on, solving some of the more complex problems associated with migrating to the cloud or to newer versions of Exchange Server.