Forum Discussion
EWS Autodiscover Process in Hybrid with "internal" Exchange Servers
Hi everyone,
i really need help about the EWS Autodiscover process in a specific hybrid Environment.
Customer is starting to use Exchange Online. For Full Hybrid configuration there is a seperate new Exchange SE with a valid certificate, NAT for IP Ranges from M365 and public available URLs for Autodiscover,EWS,...
There are internal Exchange Servers which are used only for internal access. Those are the servers with all mailboxes. All URLs are configured for internal use (mail.contoso.internal)
Migration is working, access to own calender is working, mailfllow is working. But there are problems to access other users calender. If a user which is migrated to Exchange Online (or via Teams) try to access another calender which is onPrem, there is no access. So i tried to use connectivity analyzer for teams integration to find out whats the problem.
Result: Autodiscover resolves, connects to Hybrid and gets EWS URL as answer. But it gets the internal EWS URL from the internal Exchange Servers, not from the public available URLs which are configured at the hybrid server. I visualised the two scenarios.
Number1: Thats how i thought it would work
- Autodiscover to autodiscover.contoso.com
- Hybrid answers with EWS URL: hybrid.contoso.com
- Connect from EXO to hybrid EWS URL
- Proxy to Internal Exchange
Number2 : Thats what really happens
- Autodiscover to autodiscover.contoso.com
- Hybrid relays request to internal Exchange (Mailbox Server)
- Server answers with internal EWS URL: mail.contoso.internal
- Connect from EXO to internal EWS URL (which is obviously not working)
So as you can see, the autodiscover process asks the internal Exchange for its EWS URLs and not as i expected the hybrid server's URLs. I always thought, the hybrid server works as a sort of proxy for every external connection from EXO. But it seems that the hybrid just relays the autodiscover request to the server which holds the mailbox. And this servers in this scenario cannot change their EWS URLs to a public resolvable FQDN.
So my question is: Is this correct? Does the process always works like this or did i do anything wrong in the configuration? I hope you understand my explanation.
Thanks in advance!!!
5 Replies
Hi Sebastian,
Have you traced the call from the middle server to the backend Server?. I'm not sure, if it is working that way. Normally you specify an "external URL" only for servers, who are reachable from the internet via that URL. This was a proper setup in the old days with exchange Servers in every location and only a central internet breakout. The central servers had an "external URL" configured but the internal Server in remote locations were not reachable. External Clients using Autodiscover would also reach the internet faced server and they calculate the AutoD Resonse based on the Mailbox Homeserver, the AD-Site, SiteLinks.
I think there is no "reverse Proxy Function" for AutoDiscover in that case. Only for MAPI/HTTP, ActiveSync, EWS etc.
Can you use https://testconnectivity.microsoft.com/tests/Ola/input and enter your OnPrem data to check the response. ? You should see the X-FrontendServer and X-Backendserver, doing the work. You can also simulate a EXO request using https://testconnectivity.microsoft.com/tests/FreeBusy/input
But Anyaway. If you want to control the entry Service, for a backend Server, then specify the externalURL on the Backend server to point to the frontend.
Ex2007/2010 is old but the docs are still working
InternalURL and ExternalURL settings for a non-Internet-facing Client Access server
https://learn.microsoft.com/en-us/previous-versions/office/exchange-server-2010/bb310763(v=exchg.141)?redirectedfrom=MSDN#internalurl-and-externalurl-settings-for-a-non-internet-facing-client-access-serverCould you really see "Autodiscover-Request" on the Backend Server with the mailbox from the Frontend Server? The frontend knows his own urls and can see, that the mailboxserver hat no externalURL and will us his own URL for that.
The behavior you are seeing is expected in a hybrid Exchange configuration. Autodiscover does not return the hybrid server URL when the mailbox is located on-premises. Instead, Autodiscover always routes the request to the server that hosts the mailbox, which is why the response includes the internal EWS URL.
The Hybrid server doesn’t act as a proxy that rewrites or replaces Autodiscover responses. It simply redirects the request to the mailbox server, and the mailbox server publishes only its internal URLs because it was never configured with external EWS endpoints.
This explains why the connectivity analyzer and Teams integration try to resolve mail.contoso.internal. Clients outside the internal network cannot use this endpoint, so the connection fails.
To resolve the issue, the internal Exchange servers must have valid external EWS URLs defined in their virtual directory configuration, even if they are intended to serve internal users only. In a hybrid environment, workloads such as Teams rely on externally reachable EWS endpoints to open shared calendars or free/busy.
If the internal servers cannot be modified to publish an external FQDN, the hybrid coexistence will continue to fail for cross-premises scenarios because Autodiscover will always return the mailbox server details, not the hybrid server’s external URL.
Hello! SebastianGrigg
The current phenomenon is not due to a misconfiguration, but rather the normal Autodiscover behavior of Exchange Hybrid.
- SebastianGriggCopper Contributor
Hey! Thanks for clarification. I really thought there was something wrong with my config.
But, is there anything i can do except editing the external EWS URLs at the internal Exchange?
Hello! SebastianGrigg
There is no other way.