After doing quite a few Exchange Online hybrid deployments, I decided that it was time to do what I do best – build a design template so I don’t have to continue to reinvent the wheel for each project. I’ve done this for Exchange, Active Directory and SCCM audit documentation, but those are stories for another day…
In a typical scenario we’re taking an existing, highly available Exchange 2010 environment that is protected behind their own spam filtering devices (so this could change and be a services, no problems) and adding a secondary Exchange hybrid server dedicated for this purpose – be it Exchange 2013 or even Exchange 2016. I’ve deployed a few of these already and they work great, think Exchange 2013 SP2 but with better results. More of that in a moment.
But you ask “why not just run Hybrid on the existing Exchange servers? The biggest one is that the Hybrid wizard on Exchange 2010 hasn’t gotten any better since SP3. Sure the Cumulative Updates have fixed some bugs but with Exchange Online running on the Exchange 2016 build, the gap is getting wider in regards to the success rate of being able to run thru the Hybrid Wizard the first 5-6 times without having to go back and fix issues (or create new ones).
Or, let’s say that eventually you’ll be migrated to Exchange Online, you’ll have your MX records flipped, most likely using Exchange Online Protection (and the rest of the stack), but may still have that need to run some mailboxes on-premises, or you want a nice GUI to provision your users / groups (yes, you CAN run without a Hybrid server but we’re talking a LOT of Powershell), or you have a LOT of SMTP endpoints and switching them all to the Cloud for relay just doesn’t make sense. Having a newer version of Exchange in the environment that’s NOT on extended support.makes the most sense.
There are some “gotchas” however: as of Exchange 2013 CU8 Microsoft has introduced their new hybrid wizard – and let me tell you this thing it’s amazing. Of course now with Exchange 2016 its built in.
Once of the previous “gotchas” with Exchange 2013 hybrid was the requirement to flip all of the CAS traffic over on day one to make things work/ Now, with Exchange 2016, this is no longer a requirement. More on that over at the Technet blog. The only thing you have to remember is that if you keep your existing Exchange 2010 environment, and still have Autodiscover pointed there, you’re going to run into a few issues: free/busy will be broken, migration batches will be broken, however mail flow will still work, and the only way to move a mailbox is thru New-MoveRequest.
This is because when you create the organization relationship, even in Exchange 2016, it does NOT use the organization FQDN you’ve specified but instead populates with the typical autodiscover URL.
To fix this, you need to run:
Get-OrganizationRelationship | Set-OrganizationRelationship -TargetAutodiscoverEpr "https://hybrid.domain.com/autodiscover/autodiscover.svc/WSSecurity"
There are a few instances that have been documented as well where you also need to run:
Get-OrganizationRelationship | Set-OrganizationRelationship -TargetSharingEpr "https://hybrid.domain.com/ews/exchange.asmx"
There’s also a great blog post that goes into troubleshooting Authentication on the Exchange 2010 side as well, where Negotiate authentication (which is there by default but against best practice) can cause Cloud -> On-Premises authentication issues.
So you’ve seen some pretty compelling reasons to deploy Exchange 2016 for your hybrid environment. Whether it be in a Federated or Synchronized identity model, and with in conjunction with AD Connect for directory synchronization, you can get setup with hybrid easer than ever.
Also Microsoft has recently updated the Exchange Hybrid Product Key Distribution wizards so you can finally deploy Exchange 2016 in an Exchange 2010 environment as your Hybrid server and be covered under Microdot proper licensing and support. You can grab your key at:
So without further adieu, here is version 2 of my EO Hybrid architecture.