0

I was about to roll out our new Exchange 2019 setup...everything seemed good. After installing our new certificate, I was confirming all was well, and autodiscover is showing odd behavior when run from internal hosts. Our internal domain is exch.corp.com and external is corp.com. I have internal DNS records for autodiscover.corp.com, mail.corp.com, and corp.com that all point to the IP address of our loadbalancer (I have tried bypassing the LB, that doesn't seem to be the issue). All resolve correctly. I ran the appropriate PowerShell command to set the SCP correctly. Yet, when I try to setup a new Outlook profile, autodiscover is somehow finding a record on the internet from our email host and thinks I have an IMAP account, and then shows the login info for our mail provider's email service. I have no idea where this is coming from -- I've tried sniffing traffic, looking at DNS logs, etc. but I can't see an external query. But if I remove the DNS server from the client and make static entries for the relevant names, it works fine (sort of, see below), and if I remove all of the forwarders from the DNS server, it works fine (again, sort of). So where is this autodiscover info coming from? What is it checking before the entries I already have?

When I said it works fine, it does still pop up a dialog asking me to select an account type, which I don't think should be happening. But after I select Exchange it works, although I do need to explicitly enter user@exch.corp.com as the account, it isn't autopopulated.

Any suggestions?

scottmlew
  • 85
  • 2
  • 10

2 Answers2

0

Did you assign the original services(Just like SMTP, POP, IMAP, IIS etc.) to the new certificate and restart IIS? You could run the command "Get-ExchangeCertificate | fl Issuer, Services" to check the current assigned services.

Did you set the internal/external URLs and hostnames of the services correctly(Outlook Anywhere, MAPI over Http, OAB, EWS etc.)? You could run the following commands to check that:

  1. Get-OutlookAnywhere | Select Server,InternalHostName,ExternalHostName

  2. Get-MAPIVirtualDirectory | Select Server,InternalURL,ExternalURL

  3. Get-OABVirtualDirectory | Select Server,InternalURL,ExternalURL

  4. Get-WebServicesVirtualDirectory | Select Server,InternalURL,ExternalURL

If the above settings aren't problematic, you could visit the Microsoft Remote Connectivity Analyzer to check whether there are some errors about Autodiscover in the test result:

enter image description here

Ivan_Wang
  • 1,333
  • 1
  • 4
  • 4
  • All of the services show mail.corp.com as the internal and external names/URLs, The certs cmd shows my new cert for IMAP, POP, IIS, SMTP. IIS is also still assigned to the default self-signed cert, but this seems to be normal. The MRCA won't tell me much since my problem is from inside. – scottmlew Apr 17 '20 at 03:05
  • Did you restart IIS after renewing the certificate and setting the SCP? – Ivan_Wang Apr 17 '20 at 08:22
  • I did...full reboot, just to be sure – scottmlew Apr 17 '20 at 12:03
0

I looked at a packet capture of a client setting up a new Outlook account this morning with fresh eyes, and still didn't see any DNS requests related to my domain. Although it seemed crazy, it was almost as if one of the several servers that Outlook was communicating with were somehow providing autodiscover info to Outlook outside of DNS. So I figured I'd start blocking access to those domains one at a time. Sure enough, the very first one I blocked caused the IMAP to go away, and autodiscover now immediately asks me for an account type (which I still don't think should be happening). The domain I blocked was live.com, and Outlook was trying to resolve odc.officeapps.live.com. It seems that this site is telling Outlook where my domain email is hosted? That doesn't even seem to make sense, but it's the best I can make of it at the moment. Since I won't be able to block this for external users (I guess I could use local host entries, but that's pretty hacky), it will cause complications when my users are on the road. Thoughts?

scottmlew
  • 85
  • 2
  • 10
  • For domain joined clients they should be using the SCP, not DNS, for autodiscover... with the additional step of checking Office 365 first... which is probably the behavior you're seeing. You can disable the Office 365 check with Group Policy or Registry settings. See this article regarding autodiscover - https://support.microsoft.com/en-us/help/3211279/outlook-2016-implementation-of-autodiscover – joeqwerty Apr 17 '20 at 12:13
  • This client is not domain joined, so SCP shouldn't be in play (but I wanted to make sure it was correct just in case, and to accommodate future domain-joined clients). I had seen that article, but I don't see the queries referenced in step 4. – scottmlew Apr 17 '20 at 12:19
  • I added the DWORD ExcludeExplicitO365Endpoint with value of 1 to HKCU\Software\Policies\Microsoft\Office\16.0\Outlook\Autodiscover and that didn't change the behavior. – scottmlew Apr 17 '20 at 12:38