Time for some good news…
Microsoft has just announced the general availability of the hybrid agent for Exchange. This little piece of software comes with some obvious advantages when it comes to hybrid scenarios, but also some caveats you need to be aware of.
First off, let’s see what the hybrid agent is, for those who haven’t come across it.
How does it work?
The hybrid agent is a small piece of software you install on your on-premise Exchange server, which then facilitates the hybrid connection to Exchange Online. It’s available as an additional option to the classic hybrid connection in the hybrid installation wizard, shown here:
When choosing this option, a small piece of software is installed on your Exchange server, which then proxies connections between Exhange Online and Exchange On-premise, like shown in this diagram:
And that is also one of the biggest advantages of the hybrid agent at the moment, namely removing the need for publishing Exchange directly to internet to have a working hybrid scenario. It grants users access to free/busy information cross-premise, while also being able to perform mailboxes migrations, without the need for inbound access to the Exchange environment.
But there is a flipside to it at the moment…
While it doesn’t require opening ports directly from unsecure network locations to Exchange servers, there are some things that’s unsupported and may cause you to choose the classic hybrid connection.
These are, at the time of this writing:
- Hybrid modern authentication not supported
This feature relies, at the moment, on access to the Exchange On-premise web endpoints, like AutoDiscover, EWS, MAPI and OAB. This means it will not work with the hybrid agent. - Message tracking an multi-mailbox search doesn’t work cross-premise
To perform cross-premise searches, access to AutoDiscover and EWS endpoints are needed. - Connections from Exchange Online are hard-wired to configured CAS servers
The hybrid agent registers the internal FQDN of configured CAS servers, and should these go offline, the connection will fail. - Teams Calendaring does not work with on-premise mailboxes
As Teams Calendaring requires access to AutoDiscover and EWS endpoints, this feature will not work for on-premise mailboxes - Mailbox migration can only be done using a single endpoint
Multi-endpoints or custom endpoints are not supported. - SMTP traffic does not traverse the hybrid agent connection
Where to go from here?
In my opinion, the classic hybrid wizard is the way to go at the moment, unless your use-case fits into the below categories:
- Limitations don’t apply
If your use-case is not affected by the limitations, and you do not plan on onboarding users in the future to services where this could be a problem, then go ahead. - Security is holding you back
If you have a project approved for Exchange Online, but your security stance prevents you from publishing Exchange to internet, then this will allow you to move forward
If you wanna give the hybrid agent a go, here is the download link: https://aka.ms/hybridagentinstaller
