Outlook logon prompts after upgrading to Exchange 2016 CU18

Stu C 191 Reputation points
2020-12-09T12:07:31.753+00:00

Hi all,

We run a DAG containing 9 members, 3 members being in our secondary datacenter and hold DB copies. All client access is through our primary datacenter to the other 6 nodes.

All servers are running Exchange 2016 CU15. We tried upgrading two (ServerA in primary DC, ServerB in secondary DC) to CU18 recently and since then, when we test directly against ServerA Outlook clients (v2016 across the board) they're getting prompted for logon credentials. When the user's enter their credentials, they're not accepted. What we have noticed is that if we delete their autodiscover.xml file, Outlook can connect to Exchange. However, when the .xml file re-appears in their profile they're back to getting the logon prompts. We believe autodiscover is working fine in our environment.
We noticed on ServerA, its Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\autodiscover\web.config file had this added to it after the CU18 upgrade:

<httpProtocol>
<customHeaders>
<add name="X-FEServer" value="servername" />
</customHeaders>
</httpProtocol>
<security>
<authentication>
<windowsAuthentication>
<providers>
<clear />
<add value="Negotiate" />
<add value="NTLM" />
</providers>
</windowsAuthentication>
</authentication>
</security>
ServerB had the same ' <add name="X-FEServer" value="servername" />' bit, but it didn't have the authentication settings. We removed these authentication settings from the web.config on ServerA, did an IISreset, but we still have the issues with the user logon prompts.

The release notes from CU18 mentions a known Autodiscover error (KB4532190). We tried this and we still got the Outlook logon popups.

We're currently running NTLM authentication across the environment. I'm aware this could be contributing to the issues, but we're trying to resolve a few other issues and get everything patched to CU18 before we look to switch to Kerberos.

Hope this all makes sense and has anyone else come across this issue?

Thanks in advance,

Stu

Exchange Server Management
Exchange Server Management
Exchange Server: A family of Microsoft client/server messaging and collaboration software.Management: The act or process of organizing, handling, directing or controlling something.
7,345 questions
0 comments No comments
{count} votes

Accepted answer
  1. Stu C 191 Reputation points
    2020-12-17T15:26:43.947+00:00

    Hi all,

    We think we've resolved the issue.

    Microsoft identified an issue with the authentication settings on out MAPI virtual directory - It was set to allow OAuth and NTLM and not Negotiate. We've been using NTLM authentication for a while as I mentioned in my opening post so I didn't think this would be an issue. However, once we added Negotiate and performed an IISreset, we were able to connect to the newly upgraded server without getting logon prompts in Outlook. We corrected the authentication settings on all other Exchange 2016 boxes and installed CU18 and they're all fine also. Its only early, but so far users don't seem to be getting logon prompts.

    Thank you all for your help.

    Stu

    0 comments No comments

2 additional answers

Sort by: Most helpful
  1. KyleXu-MSFT 26,206 Reputation points
    2020-12-10T05:56:22.197+00:00

    @Stu C

    First, put the DAG members in the same CU. DAG member could running with different CU, but may not works very well.

    What we have noticed is that if we delete their autodiscover.xml file,

    Do you mean delete the client computer .xml file?

    I would suggest you try to reconfigure Outlook profile again. Check whether this user could reconfigure Outlook successfully, if this user cannot reconfigure Outlook, which step this issue occur? Could you also provide a screenshot about the result of “Test Email AutoConfiguration” to us?

    46740-qa-kyle-13-49-29.png

    Do you add those information below into the web.config on your Exchange server? Please delete them or copy a original xml file from another Exchange which in the same CU.

    46764-qa-kyle-13-52-26.png
    There doesn't exist those information in my Exchange server, could you tell use why do you added those information into the config file?


    If the response is helpful, please click "Accept Answer" and upvote it.
    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    0 comments No comments

  2. Stu C 191 Reputation points
    2020-12-10T09:47:04.917+00:00

    Hi KyleC-9016 ,

    Thanks for your response.

    Because of the problem with ServerA running CU18, I don't want to upgrade all other DAG members yet as all our users (15,000) might start getting the logon prompts, which would be very bad. Especially if their logon credentials aren't accepted.

    If I point users to ServerA, they get a logon prompt when opening Outlook. Same thing happens if I close and reopen Outlook several times. I delete the Autodiscover.xml file in their profile (C:\Users\username\AppData\Local\Microsoft\Outlook) they can open Outlook fine and no logon prompts. Once the .xml is recreated and they close Outlook, the logon prompts return. I've compared an Autodiscover.xml file from a client that is connecting to a CU15 and CU18 server, and the contents appear the same - please see attached,.46951-autodiscover-edited.txt

    If I run 'Test Email AutoConfiguration' against a CU15 and CU18 server, I'm also seeing the same result:

    47173-1.png

    Regarding the snipped of code from the web.config file, I don't know where that came from. I thought the CU18 added that, though as I mentioned above when we upgraded ServerB to CU18, which is in our secondary/DR datacentre that clients don't hit for CAS services (we're using a "bound" namespace model), those lines of code don't exist in the web.config.

    We did try removing the lines of code from ServerA's web.config, as you suggested, and this made no difference - we still got the Outlook logon prompts.

    As I also mentioned, we're using NTLM authentication across our Exchange environment and not sure if this is causing us issues. We'd like to Kerberos, but we wanted to get everything upgraded to CU18 first.

    Thanks,

    Stu