Certificate warning - Outlook connecting to local Exchange 2016 FQDN while autodiscover points to Exchange Online


The following is the environment:

One Exchange 2013 and one 2016 server. The 2016 server is in hybrid mode. None of the the client access URLs point to the 2016 server FQDN. Autodiscover.domain.com (split DNS) points to autodiscover.outlook.com as all mailboxes (except journaling and some test mailboxes) are in Office 365.

The official cert is installed on Exchange.

Some Outlook clients get a certificate warning and it shows that they are trying to connect to the local Exchange 2016 server's FQDN - which gives the error of course because this name is not on the certificate.

Any idea how Outlook keeps connecting to this while none of the CAS URLs point to this FQDN and while autodiscover points to Exchange Online?

Jozef WooSystem EngineerAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Vasil Michev (MVP)Commented:
If you are in Hybrid, autodiscover needs to be pointing on-prem. That aside, *internal* autodiscover lookups will always hit the SCP endpoint first, regardless of where your DNS records point at.

If you still want to exclude certain lookups from the process, the best way to do it is client side, via the reg keys detailed in this article: https://support.microsoft.com/en-us/help/3211279/outlook-2016-implementation-of-autodiscover
Jozef WooSystem EngineerAuthor Commented:
Hi Vasil, thanks.

All mailboxes are in Office 365, that's why we decided to point autodiscover to cloud directly. The SCP has been set to autodiscover.domain.com as well (and in DNS this points to autodiscover.outlook.com) so even that shouldn't give clients the server FQDN.
Vasil Michev (MVP)Commented:
Regardless of where the mailboxes are, if you are in Hybrid autodiscover should be pointing on-prem. It will hit the on-prem servers first and them be redirected to O365. But if you have moved all mailboxes to O365 and dont plan to create any new ones on-prem, perhaps you should start thinking of decommissioning Hybrid.

Anyway, for the issue at hand find out which endpoint Outlook is hitting either by enabling logging or looking at the Test E-mail Autoconfiguration wizard outpit. Or directly use the ExcludeHttps* keys from the above article to "instruct" Outlook to bypass them.
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Jozef WooSystem EngineerAuthor Commented:
Hi Vasil, thanks again for your input.

Why should autodiscover point to on-prem in hybrid if no mailboxes reside on-prem?

Also, hybrid Exchange is a requirement if AD Connect is implemented so for now we have no choice but to keep hybrid. Secondly, we have journaling so we need an on-premises server because O365 does not allow journal mailbox in Exchange Online.

The test e-mail autoconfig doesn't show the server FQDN in the response. Which logging do you refer to? Outlook logging?

The root domain lookup is already excluded. However, if I use ExcludeHttpsAutoDiscoverDomain, then autodiscover will not work anymore when clients are external, no? Because this will be the main and only working autodiscover lookup.
Vasil Michev (MVP)Commented:
Because Exchange on-prem can handle the autodiscover process for both mailboxes in AD and in the cloud, while Office 365 cannot. If the request hits the on-prem server, it will either reply with the autodiscover.xml file (if the mailbox is on-prem) or redirect the user to O365 (based on the targetaddress value for migrated users). If the request hits O365, it will only "serve" cloud mailboxes, thus you will have issues with any mailboxes that remain on-prem, or features such as free/busy, mail tips, etc.

Hybrid is NOT a requirement for AAD Connect, it's the other way around. You can use AAD Connect just fine without Hybrid, and even without on-prem Exchange, although that is not supported by Microsoft.

You can configure ExcludeHttpsAutoDiscoverDomain, Outlook will simply continue to the CNAME (HttpRedirect) method (which is what is used in O365). It will work just fine externally/internally, assuming you have the CNAME record correctly setup of course.
Jozef WooSystem EngineerAuthor Commented:
In the mean time, I found a "solution"... those people that had the problem had a shared mailbox in their profile that was still on the on-premises server (even though the mailbox had been deleted already in the meantime - I guess their client couldn't find out since autodiscover was pointing to Exchange Online). So even though autodiscover does not return ANY server FQDN, maybe some caching in the profile still had this reference from before the user mailbox was migrated to Exchange Online and autodiscover was changed to autodiscover.outlook.com ? We migrated very recently (last month).
Vasil Michev (MVP)Commented:
Delegates would have been my initial guess, but you mentioned that everyone is migrated to O365 already...
Jozef WooSystem EngineerAuthor Commented:
Hi Vasil, yes that statement is still correct. Everyone is migrated. As I mentioned, the only on-premises mailboxes are journaling and some test mailboxes. Those shared mailboxes causing the problem had already been deleted from the on-premises Exchange server but I guess that the Outlook clients couldn't find out about this anymore once autodiscover was changed to point to Exchange Online. I suspect the Outlook clients still tried to connect to the local Exchange server, having cached the FQDN from when the server was first installed (also very recent). I only changed the CAS URLs of the new server to webmail.domain.com after I pointed autodiscover to Exchange Online. I hope my explanation makes sense...

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Jozef WooSystem EngineerAuthor Commented:
It was the only real solution.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.