Exchange Hybrid Namespaces

You don't need to do all this stuff
I don't know where you get this all

Exchange hybrid all needed is, onpremsie autodiscover.domain.com and mail.domain.com published on internet over TCP 443 so that hybrid wizard can contact exchange servers and setup hybrid environment

Setting up hybrid config is nothing but setup calender / free busy sharing over federated trust across onpremsie and exchange online, enable remote mailbox move
For remote mailbox move, you will setup endpoint pointing to mail.domain.,com which must be published on internet directly and it does, so mailbox move should not be an problem

Mail flow is different from setting up hybrid environment though it looks like part of hybrid setup

As per Microsoft hybrid mail flow is considered as internal as long as in between 3rd party firewalls do not alter SMTP traffic (headers etc)
If you have 3rd party firewalls in between and if they do modify header, still mail flow will work however all security checks would apply on messages transacted between hybrid exchange and exchange online
In fact let hybrid wizard create mail flow connectors and you can modify those connectors to point to in between devices such as antispam devices or any 3rd party smart hosts etc
https://docs.microsoft.com/en-us/exchange/transport-options

I believe you have asked this question at least twice \ thrice with another questions
If you need hundred % answer, you need to setup your own lab with whatever obstacles you already have because everybody have different setup and may find different issues based on what setup he has with onpremise network

So, what you're running into here is a semantic misunderstanding. For Office 365 Architecture, a "Hybrid Server" is defined as a dedicated Exchange server that is deployed for the sole purpose of acting as an intermediary for an On-prem Exchange deployment and Exchange Online. "Hybrid Servers" cannot have any active mailbox databases with active mailboxes on them to meet licensing requirements (In other words, if it's got a mailbox, you can't use the free hybrid licensing from MS and be legal). A "Hybrid Server" is Not Necessary if you are running Exchange 2010 SP3 or later for your Exchange on-prem deployment. At this point, you should probably not be running anything that could require a "Hybrid Server". The terminology here is important to remember. If you already have an HA Exchange deployment that meets the minimum requirements for a Hybrid Config, you don't need to worry about this.

That design setup seems to be common amongst companies offering O365 consultancies, i have seen hybrid.domain.com recommened by at least 3 diifferent ones

i tihnk you still need to use the SMTP names spaces so that you set the path explcitily that mail will take otherwise it won't know where to connect to on premise to route mail before it then goes outside

Hi Chris,

Yes you are right. They are a number of consultancies that suggest using "hybrid.domain.com" and that is why I put up this question here.

But there are also many bloggers that say this is overkill

What is your opinion on this?

Thanks

it depends what your end state is going to be, if you intend to run permanently in hybrid mode then there can be some value to having a seperate name space for client connections.

During the setup and migration we used an additional namespace to allow O365 connections to come down and bypass our load balancers with had SSL Acceleration while still maintaining client connections through it. If you don't need or wnat to do this then it is overkill

we have also setup seperate servers to take this connections and they would be the MRS proxy end points, mainly for service segregation i.e. reboot these and it doesn't afect the rest of the clients

Hi Chris,

According to the "book", I will need to change autodiscover to hybrid.domain.com. This sounds like a lot of disruption:-
Is this how its done?
1) Create SRV record to redirect autodiscover.xx.com to hybrid.domain.com and keep the autodiscover record or create a CNAME record for autodiscover.xx.com to hybrid.domain.com so hybrid.domain.com is an additional record
2) Any changes to the EWS record - mail.domain.com?
Thanks

unless you want to use O365 as the primay or remove the Hybrid and run native on O365 you don't need to change the autodiscover

this should explain it for you
https://blogs.technet.microsoft.com/rmilne/2016/07/14/office-365-exchange-hybrid-deployments-busting-the-autodiscover-myth/

followed by...
https://blogs.technet.microsoft.com/rmilne/2015/04/29/office-365-autodiscover-lookup-process/

As I mentioned, hybrid.domain.com is technically required if you're using actual hybrid servers (or should be. Consultancies aren't always the best source, since they regularly pull from TechNet, which is notoriously bad at explaining terminology differences). The reason for this recommendation in this case is that you have to have separate endpoints for the regular Exchange deployment and the Hybrid servers, due to the fact that a "hybrid server" in this case would be deployed to allow Hybrid capabilities with an on-prem Exchange 2003/2007 environment. Hybrid servers are simply Exchange 2010sp3/2013/2016 servers deployed to act as intermediary between O365 and incompatible On-prem Exchange deployments. The reasoning here is that none of the "hybrid" exchange versions can properly redirect client access to Exchange 2007 and earlier using the same namespace (which is different than doing 2013/2016 to 2010, which proxies through the hybrid server), so you have to have a separate endpoint for the hybrid servers for client access and hybrid to function at the same time. The recommendation to redirect Autodiscover to the hybrid servers is because hybrid servers in the above deployment are the only ones capable of redirecting clients to O365 when they do a mailbox location lookup on a cloud-based mailbox (If you have autodiscover.contoso.com pointing to Ex2007 in a hybrid deployment and the user's mailbox is in the cloud, the lookup will fail and they won't be able to access their mailbox). Exchange 2003/2007 can't do this, so hybrid doesn't work if autodiscover is pointing to the 2003/2007 servers (only 2010SP3+, 2013, and 2016 can redirect clients to the cloud in any way).

That is the deep-dive explanation behind the *history* of this recommendation (look at the dates the recommendations were posted, you'll probably see they are from 2015 or earlier in many cases, and in the other cases, they continue recommending this because their consultants never fully understood the reasons for the original recommendation and kept recommending it when it wasn't necessary, but still worked). You don't need and, frankly, shouldn't use hybrid servers when deploying hybrid configs for 2010SP3 and later versions of Exchange. Those versions interact with O365 natively, and you should use that native capability, if it exists for you, for many very good reasons. If you have something before 2010SP3, you *have* to have hybrid servers to have a hybrid deployment.

edit to add:  The issue of SSL offloading talking to Exchange over port 80 can be resolved with proper rule configuration in the load balancer (create a separate rule for the ews/mrsproxy.svc URL and require that to direct clients through port 443 instead of port 80). Using multiple namespaces or hybrid servers to solve a problem like this is probably not the best solution.

The issue with SSL configuration was because we were trying to maintain 443 end to end as we don't use insecure protocols and there was additional layers of protection, this was a specific scenario with specific requirements

So What is the solution?

1) deploy new exchange 2016 since it cant be an existing mailbox server
2) enable hybrid licence on this server
3) run HCW - choose this as optimal
Server
4) publish mrs endpoint to public DNS
5 no change to autodiscover or Ews so no new namespace

This is a purely exchange 2016 environment with 3rd party gateway, spam filter, AV and on-prem DLP and I have to pick Centralised transport.

Any advice

that sounds like a logical list of steps to me.

Pre-requisites to plan out
Ensure EWS endpoints are a clear path through, any additional authentication will cause issues.

Connectivitty to and from the new servers - depnding on how challenging your security team are this could  be a hard conversation..its basically 443 from a very large chunck of IP's or from some very broad namespaces.

Autodiscover.domain.com and mail.domain.com should point to new hybrid server as well for hybrid configuration to work
No new name space is required
Also if same hybrid server is used for hybrid mailflow, ensure that your SPF also include that servers

How do we make sure that the Autodiscover and EWS points to Hybrid servers? Is this through HCW? Any change to public DNS? Add new records?

I need to make sure the Existing clients still point to the other Exchange mailbox servers for normal SMTP delivery.

Internal autodiscover is the same as external autodiscover in terms of IP address. No change here.

So I guess mail flow from EOL goes through the Hybrid servers only? Any need for HA?

Where did your current Autodiscover and mail records are pointing

What exchange versions you have currently?

If exchange contains 2010 or above exchange versions, you actually don't need to change any records as long as they are published on internet
If exchange having 2007 & older version you need to point autodiscover and mail records to newer exchange 2016 servers internally and externally

Typically hybrid servers handle mailflow to/from O365
However but you can use different servers if wanted to and if you already have

Note that hybrid server is not any special server, it's standard exchange server without mailboxes and used to run hybrid configuration cmdlets those actual autodiscover functions and mailflow can be handled by other servers

I prefer to/from O365 email traffic through hybrid servers directly to avoid hybrid malflow issues