Hi, i'm Lucian and here I share my experiences, thoughts and opinions on life in the blue cloud. I'm a Cloud Solution Architect, specialising in Azure infrastructure, at Microsoft, in Sydney, Australia.

Exchange Server hybrid 'edition' myths and misunderstandings

/0051
6min read

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…

Exchange Server Hybrid

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.

BUSTED!

Source: Mythbusters

Use hybrid

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.

Can you get rid of hybrid? But, how?

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:

  • Migrate all mailboxes to Exchange Online
  • Ensure all mail flow is delegated to EXO
  • Ensure all DNS is delegated to Office 365
  • Transition public folders to EXO (if any)
  • Ensure the Set-OrganizationConfig -PublicFoldersEnabled local is run from Office 365 / EXO powershell
  • To stop clients from trying to contact Exchange Server on-premises for anything, disable the service connection point - Achieved by running Get-ClientAccessServer | Set-ClientAccessServer -AutoDiscoverServiceInternalUri $Null
  • The big one, remove the hybrid config Remove-HybridConfiguration
  • Finally, review send and receive connectors on both Exchange Online and on-premises and remove those
  • Since there won’t be any requirement for cross forest mail, deleting this connectors is recommended

For more information on the process, check out this TechNet article.

The (not so) tricky part: how do you manage remote mailboxes?

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.

Don’t use 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:

  • Secure mail routing between on-premises and EXO organizations.
  • Mail routing with a shared domain namespace. For example, both on-premises and EXO organizations use the @contoso.com SMTP domain.
  • A unified global address list (GAL), also called a “shared address book."
  • Free/busy and calendar sharing between on-premises and EXO organizations.
  • Centralized control of inbound and outbound mail flow. You can configure all inbound and outbound EXO messages to be routed through the on-premises Exchange organization.
  • A single Outlook on the web URL for both the on-premises and Exchange Online organizations.
  • The ability to move existing on-premises mailboxes to the Exchange Online organization. EXO mailboxes can also be moved back to the on-premises organization if needed.
  • Centralized mailbox management using the on-premises Exchange admin center (EAC).
    • Message tracking, MailTips, and multi-mailbox search between on-premises and Exchange Online organizations.
  • Cloud-based message archiving for on-premises Exchange mailboxes. Exchange Online Archiving can be used with a hybrid deployment. (Source: TechNet)

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.

Final words

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.