There’s a common misunderstanding that Exchange Server hybrid (whichever version you may be running) is needed to be kept on-premises forever if you have Azure AD Connect. AADC syncs on-premises Active Directory with Azure AD. When AADC and federated identity is enabled, MOST of the cloud attributes in Azure AD are READ ONLY. From that statement it’s been understood that hybrid is needed to be maintained to do all that Exchange Online remote management goodness. Wrong!
I hate to burst the bubble here, but, I’m going to burst the bubble. It can be done with just Exchange Server itself. Continue reading to find out…
Being a consultant, I’m going to do that frustrating thing and say those famous words: “it depends on the situation”. I love being ambiguous sometimes as it affords room for different options and ideas which is great for brainstorming and architecting.
Looking at Exchange Server hybrid functionality independently of thinking about the common tech phrase “hybrid”, what does Exchange Server hybrid do? Put simply, which isn’t very clear on TechNet or other publications, hybrid creates send and receive connectors between on-premises and Office 365 EXO. It’s now just a wizard / setup application that completes a few commands that can be achieved manually through powershell. It’s not even an Exchange Server role anymore.
From there though, with the additions of AD FS and Azure AD Connect + Azure AD, a seamless solution that “joins two disparate ADDS forests and Exchange organizations” so an enterprise can complete a staged migration. Hybrid alone won’t do any of that apart from allow for mail to be sent as “internal” between on-premises and Exchange Online. That’s as simple as it gets.
It’s quite easy to complete a staged migration to EXO and leave a handful (two’s enough really, even Microsoft recommend that) of Exchange Server servers on-premises with hybrid enabled. For larger or enterprise customers that perhaps have SMTP relay requirements for legacy on-premises applications, leaving hybrid is a requirement to keep that mail flow and connectivity between cloud and on-premises for an ongoing basis.
Mid to large deployments where federated identity is enabled could also leave hybrid enabled without impacting the solution in any negative way either.
Hybrid is there to make the journey to Office 365 Exchange Online easier through staged migrations. In all but one of the transitions to Office 365 that I’ve worked on, only one has not needed to use hybrid. In that circumstance there was no federated identity requirements and the migration of ~300 mailboxes was orchestrated through a ‘big band’ migration approach.
Timing is key in any migration or transition to the cloud. Hybrid provides the warm blanket or comfort in that it assists in affording more time to the transition.
Once hybrid is in place, Exchange server in a federated identity world should be kept on-premises indefinitely. If you want Microsoft support, then you’ll need Exchange Server to do the remote management goodness.
Third party tools (mentioned further down) are available, BUT, and the is but in caps for a reason; Microsoft won’t provide you support if anything breaks with that service. You’ll likely need to source expertise that could get rather expensive. Protip: don’t do it.
Looking at an example where we have migrated all on-premises mailboxes to Exchange Online and there is no need for large on-premises legacy Exchange Server servers. The on-premises footprint is reduced to a handful of servers and one has the Hybrid Configuration Wizard run on it.
There is a tidy up process (see the following checklist) to remove hybrid integration, but, allow for remote management of Exchange Online:
Set-OrganizationConfig -PublicFoldersEnabled local
is run from Office 365 / EXO powershellGet-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri $Null
Remove-HybridConfiguration
For more information on the process, check out this TechNet article.
There’s two pieces of this puzzle to understand.
On-premises Exchange Server integrates with Active Directory. As all data is stored in this lovely (depends on how you look at it) database/directory, Exchange reads this and through various attributes knows that mailboxes are remote or config is associated with Office 365.
The second piece of the puzzle is powershell. Having the Azure AD and Office 365 powershell modules available additionally allows for streamlined remote management. This process can be tricky and I’ve written a quick piece (available here) should you get stuck trying to install the Online Services Sign-in Assistant.
With both of those items understood, the majority of what you need to do can be achieved just as easily without hybrid as with hybrid.
Let’s flip the coin and explore the wonderful (or other) world without hybrid. This world mainly consist of a “cloud first” or “born in the cloud” approach to IT. Not every organisation would want to implement a complex AADConnect, AD FS and hybrid mail environment. Well managed migrations to Office 365 can certainly be achieved without the cost and time expenditure on getting a hybrid and federated solution off the ground.
Microsoft’s recommendation around this again comes down to requirements. In a nutshell, if you don’t need any of the below features, you can quickly commence a migration to Office 365 Exchange Online without hybrid connectivity:
Non hybrid deployments can leverage a number of excellent 3rd party tools to migrate to Office 365. This is not a paid advertisement!, but, such tools as Skykick or MigrationWiz among others allows for a streamlined and managed migration.
Working in the enterprise space, it’s common that Exchange Server of some flavour is used as the preferred mail solution. Migrating to Office 365 from Exchange on-premises will most commonly leverage hybrid.
I would, for the most part, go with hybrid for the length of the migration. Thereafter though it CAN be removed. You might not need to, but, the option is. Don’t stress about it for or against though. The end result in remote mailbox management is near identical.