none
Autodiscover security alert after removing exchange 2010 from the new exchange server 2016 environment RRS feed

  • Question

  • Hello,

    I recently installed Exchange Server 2016 to our existing Exchange server 2010 environment.  The new exchange server has been up and running without issue for the past two weeks.  Yesterday I reconnected the old exchange server so that I could properly decommission it and cleanly remove it from the exchange environment. This was successful. However, now, when opening outlook staff are getting the autodiscover.domain.com security alert.  Once they click Yes, everything connects and functions normally. 

    I have confirmed the AutoDiscoverServiceInternalUri points to https://autodiscover.mail.domain.com/Autodiscover/Autodiscover.xml and Outlook has and continues to function normally.  The ecp, ews, activesync, oab and owa virtual directories all point to the https://mail.domain.com... 

    I do have an A record in DNS on the domain controller for autodiscover and mail with the IP of the exchange server. We also have an A record in Network solutions for mail.domain.com and a CNAME with an alias of autodiscover.domain.com that point to  mail.domain.com. This has been in place for over two weeks and everything has been working normally. 

    Note: my manager doesn’t want to use autodisocver, so the SSL that is configured for SMTP and IIS on Exchange server 2016 does not include autodiscover.domain.com as a SAN. Only mail.domain.com and www.domain.com are in the certificate. The autodiscover security alert only appeared after the exchange 2010 server was removed from the environment yesterday.

    What am I missing that is presenting this security alert and how do I correct this?

    Thanks,

    Roger


    r

    Wednesday, November 20, 2019 2:07 PM

All replies

  • Hello,

    your autodiscover must be on your certificat. if not, you will have a security prompt.

    If you want to avoid this, use SRV record pointing to mail.domain.com as autodiscover service fir internal client.

    exemple:

    https://markgossa.blogspot.com/2015/11/exchange-2013-2016-autodiscover-srv-record.html

    Olivier.

    Wednesday, November 20, 2019 2:13 PM
  • Hi Olivier,

    Thank you. I followed the steps in the blog by deleting the A record on the domain controller and adding the srv record. (I didn't remove from Network solutions yet).

    When I open Outlook I still get the autodiscover security alert.  What am I missing?

    Thanks,

    Roger


    r

    Wednesday, November 20, 2019 2:55 PM
  • could you change your autodiscovery URL to mail.domaine.com  too ?

    SRV is ok, but not in first place when you are in LAN, only if you are external. my appologies.

    Olivier.

    Wednesday, November 20, 2019 3:10 PM
  • Yes, the autodiscover URL was already set to mail.domain.com.  The new problem I had after deleting the A record on the domain controller and adding the autodiscover srv record following the steps in the blog, resulted in communications with the outlook client being disconnected from exchange.  It also still shows the autodiscover security alert on some clients when launching outlook.

    After I deleted the autodiscover srv record and readded the autodiscover a record, connectivity between the outlook client and exchange was connected once again.

    I think something else is missing but I am unsure as to what.

    Again the autodiscover security alert only happened after removing exchange 2010 from the environment (after it was disconnected for two weeks) while we have only been on Exchange 2016. 

    The autosdiscover srv record I have in Network Solutions works when I configure an outlook profile while outside of the LAN and this worked for the past two weeks as well. However, the issue is the autodiscover security alert that now appears.

    Roger


    r


    • Edited by Vallee18 Wednesday, November 20, 2019 3:38 PM
    Wednesday, November 20, 2019 3:27 PM
  • Could you confirm that your

    https://mail.domain.com/Autodiscover/Autodiscover.xml

    Is correctly writed ?did you have acces to it with IE ? (basic auth, and error 600)

    What name do you see on autodiscover error ? Always autodiscover.domain.com ?

    could you check your outlook when connected ?

    And check the log (you will se the way to discover autodiscover)

    Olivier




    Wednesday, November 20, 2019 4:47 PM
  • I understand that the https://mail.domain.com/Autodiscover/Autodiscover.xml should result in an invalid request when accessed on the LAN

    The autodiscover test completes successfully


    r

    Wednesday, November 20, 2019 6:15 PM
  • are you sure that SCP is correct ?

    autodiscover.mail.contoso.com and cover by certificat ? as you see, the first scp is failing.

    the second autodiscover.contoso.com is working.

    could you change the SCP (set-clientaccessservice -> autodiscoverinternaluri) to autodiscover.contoso.com ?

    the error 600 is ok, its juste because you dont use an outlook

    Olivier


    Wednesday, November 20, 2019 6:48 PM
  • Yes, the SCP is correct

    r

    Wednesday, November 20, 2019 7:04 PM
  • In you picture (test email autoconfiguration) you see that SCP failing (0x8004005)

    and you see your autodiscover url working.

    then mail.contoso.com work, not autodiscover.mail.contoso.com

    could you change that SCP value to autodiscover.contoso.com ?

    Olivier


    Wednesday, November 20, 2019 7:23 PM
  • Hi Vallee18,

    Any updates about your issue?

    Find the following case for your reference:

    certificate error for autodiscover.domain.com

    Also a related KB here: https://support.microsoft.com/en-us/help/2772058/the-name-on-the-security-certificate-is-invalid-or-does-not-match-the

    Regards,

    Joyce Shen


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Thursday, November 21, 2019 6:32 AM
  • Hi Joyce,

    Thank you.  The first link is similar to my situation but not exactly as it primarily describing an  issue where they are in the process of upgrading a server.  I tested by

    • setting the AutoDiscoverServiceInternalUri to $Null but this had no effect as the security alert still appears when opening outlook.
    •  I then Set-ClientAccessService -Identity MyServerName –AutoDiscoverServiceInternalUri  https://mail.MyDomainName.com/Autodiscover/Autodiscover.xml  - this results in no security alert but shows a disconnected status in Outlook

    Using the second link, I didn’t previously have an internal srv record but created one based on the instructions. Autodiscover works (as it did before any srv record was created) but when setting up a profile but I still get the security alert. I have not removed it from our public DNS.  Note: I have an SRV record _autodiscover._tcp.MyDomainName.com in Public DNS and a CNAME for autodiscover.MyDomainName.com (These have been in place for weeks without issue).

    What am I missing?

    Thanks,

    Roger


    r

    Thursday, November 21, 2019 1:44 PM
  • Hello,

    did you tested with Set-ClientAccessService -Identity MyServerName –AutoDiscoverServiceInternalUri  https://autodiscover.MyDomainName.com/Autodiscover/Autodiscover.xml

    As your picture is succeded with this url, normally, this one will work.

    autodiscover and mail are pointing correctly to the 2016 server ? your IE test was succeeded

    Olivier.



    Thursday, November 21, 2019 1:51 PM
  • Thank you for your reply.

    My issue appears to be resolved based on the following.

    Initially there was a delay and Outlook appeared as “Disconnected” and clicking send/receive had no effect.  However, after a few minutes of waiting it appeared once again connected. Sent several tests to myself and to external mail provider and from the external mail provider and they were received quickly and successfully.

    • Tested autodiscover by creating a new outlook profile and this was successful. The profile setup completed quickly and Outlook opened without a security alert.

    Based on the above, my issue should be considered resolved.

    Thanks,

    Roger


    r

    Thursday, November 21, 2019 2:56 PM
  • Nice,

    You can close this thread by mark the answer, and vote for helpfull message.

    Olivier.

    Thursday, November 21, 2019 3:00 PM
  • I may have spoken prematurely.  Although the steps I mentioned above do work,  and the autodiscover security alert no longer appears, I noticed if the PC has been rebooted there is about a six minute delay after opening Outlook before it displays as "All folders up to date and Connected with exchange."  Otherwise once the PC is rebooted and Outlook is opened it shows as disconnected from exchange until the 6 minutes have passed.  This of course is not normal and I would like to correct this.

    Does anyone know why this would be happening?

    I also noticed if I use a laptop that is not on the LAN, connect to the internet and then proceed to open Outlook, the autodiscover security alert does appear.  It also appears if I connect to our VPN and then open outlook.  We have several staff that work remotely and I would like to correct this so they are not prompted with the security alert.

    Does anyone have any advice on what needs to change to correct this?

    Thanks,

    Roger


    r

    Thursday, November 21, 2019 9:54 PM
  • Hello,

    I just wanted to follow up on my last comment regarding the autodiscover security alert appearing for a remotely based staff member after they log onto the VPN and open Outlook.  Is there another change that I can make to correct this, taking into account the changes I noted in my Thursday, November 21, 2019 2:56 PM post?

    Thank you,

    Roger


    r

    Tuesday, November 26, 2019 3:50 PM
  • Hi Vallee18,

    Usually the connection between outlook client and Exchange server will have 1-2 minutes delay, have you checked the connection status in Outlook?

    The 6 minutes delay may caused by network issue also. 

    What's the result if you test outlook connectivity and autodiscover in ExRCA now?

    https://testconnectivity.microsoft.com/

    Regards,

    Joyce Shen


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Thursday, November 28, 2019 8:58 AM
  • Hello


    What Cu for your exchange 2016 

    The CU14 correct a bug with autodiscover and bad build url (API) 

    https://support.microsoft.com/en-us/help/4515274/autodiscoverv2-request-returns-rest-api-endpoint-not-autodiscoverv1-en

    the CU : CU14 Microsoft download

    Olivier

    Thursday, November 28, 2019 10:10 AM
  • Hello Olivier,

    I used CU14 for the installation as this was required on Windows Server 2016.

    Thanks.


    r

    Friday, November 29, 2019 12:14 PM
  • Hi Joyce,

    Overall the autodiscover test succeeds with the exception of the exception of references to autodiscover, which I understand should be related to autodiscover not being in our SSL.

    The outlook connectivity test fails with references again to the missing autodiscover in the SSL.

    I copied the results of the failed portion of autodiscover test below.

    Attempting to test potential Autodiscover URL https://MyDomainName.com:443/Autodiscover/Autodiscover.xml

     

    Testing of this potential Autodiscover URL failed.

     Additional Details

    Elapsed Time: 268 ms.

    Test Steps

     

    Attempting to resolve the host name MyDomainName.com in DNS.

     

    The host name resolved successfully.

    Additional Details

     

    IP addresses returned: IP address

    Elapsed Time: 89 ms.

    Testing TCP port 443 on host MyDomainName.com to ensure it's listening and open.

     

    The port was opened successfully.

    Additional Details

     

    Elapsed Time: 59 ms.

    Testing the SSL certificate to make sure it's valid.

     

    The SSL certificate failed one or more certificate validation checks.

    Additional Details

     Elapsed Time: 119 ms.

    Test Steps

    The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server MyDomainName.com on port 443.

    The Microsoft Connectivity Analyzer wasn't able to obtain the remote SSL certificate.

    Additional Details

     

    The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.

    Attempting to test potential Autodiscover URL https://autodiscover.MyDomainName.com:443/Autodiscover/Autodiscover.xml

    Testing of this potential Autodiscover URL failed.

     Additional Details

     Elapsed Time: 780 ms.

    Test Steps

     Attempting to resolve the host name autodiscover.MyDomainName.com in DNS.

     The host name resolved successfully.

     Additional Details

     

    IP addresses returned: IP address

    Elapsed Time: 92 ms.

    Testing TCP port 443 on host autodiscover.MyDomainName.com to ensure it's listening and open.

     

    The port was opened successfully.

    Additional Details

     Elapsed Time: 60 ms.

    Testing the SSL certificate to make sure it's valid.

     The SSL certificate failed one or more certificate validation checks.

     Additional Details

     Elapsed Time: 628 ms.  

    Test Steps

    The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server autodiscover.MyDomainName.com on port 443.

     The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.

    Additional Details

     Remote Certificate Subject: CN=mail.MyDomainName.com, OU=nsProtect Secure Xpress, OU=Domain Control Validated, Issuer: CN=Network Solutions DV Server CA 2, O=Network Solutions L.L.C., L=Herndon, S=VA, C=US.

    Validating the certificate name.

     Certificate name validation failed.

      Tell me more about this issue and how to resolve it

    Additional Details

     Host name autodiscover.MyDomainName.com doesn't match any name found on the server certificate CN=mail.MyDomainName.com, OU=nsProtect Secure Xpress, OU=Domain Control Validated.

    Attempting to contact the Autodiscover service using the HTTP redirect method.

     The attempt to contact Autodiscover using the HTTP Redirect method failed.

     Additional Details

     Elapsed Time: 21033 ms.

    Test Steps

     Attempting to resolve the host name autodiscover.MyDomainName.com in DNS.

     The host name resolved successfully.

    Additional Details

     IP addresses returned: IP address

    Elapsed Time: 0 ms.

    Testing TCP port 80 on host autodiscover.MyDomainName.com to ensure it's listening and open.

     The specified port is either blocked, not listening, or not producing the expected response.

      Tell me more about this issue and how to resolve it

     Additional Details

     A network error occurred while communicating with the remote host.

    Elapsed Time: 21033 ms.


    r

    12/3/19  After additional research and testing  I added the registry entries noted in

    https://kb.intermedia.net/article/2445

    This worked successfully if Outlook 2013 was installed on one machine but not another. After upgrading to Office 2016, the registry changes in the article were successful.


    • Edited by Vallee18 Tuesday, December 3, 2019 5:08 PM new information
    Friday, November 29, 2019 12:50 PM
  • Hi Vallee18,

    According to the configuration of your certificate, the result of ExRCA returned is normal.

    The outlook delay may also caused by steps try to connect to the autodiscover url until find the SRV record.

    The following is an article about Fix Microsoft Outlook Slow Loading Issue, check whether there is any related reason caused this as well

    Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

    Regards,

    Joyce Shen


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Wednesday, December 4, 2019 8:51 AM