Credential pop-ups after moving mailbox from 2010 to 2016

Question

Situation:

• Exchange 2010 & 2016 coexistence. Outlook Anywhere is enabled on both with NTLM

• webmail.domain.com is configured as the CAS namespace (for all virtual directories on 2016)

• autodiscover.domain.local/autodiscover.autodiscover.xml is configured as the SCP (external autodiscover is not used)

• DNS points for both of the above URLs to Exchange 2016

When moving mailboxes from 2010 to 2016 the following happens:

For an Outlook 2010 user:

• User gets a popup saying the administrator has made a change and Outlook needs to be restarted

• User restarts Outlook (and sometimes gets the same popup again and then restarts Outlook again)

• Users gets a credential popup. If you click cancel there is another popup which appears:

"Allow this website to configure [email protected] server settings?"

autodiscover.domain.com/autodiscover/autodiscover.xml

As you can see, Outlook 2010 is looking for autodiscover.domain.com and that's probably because SCP lookup fails.

If I do an Outlook Autoconfiguration test, it fails. The SCP lookup keeps giving a 302 redirect.

This seems to be the issue described here:

https://support.microsoft.com/en-us/help/3097392/outlook-logon-fails-after-mailbox-moves-from-exchange-2010-to-exchange-2013-or-exchange-2016

I can do a recycle of those AppPools and then it does seem to work for some Outlook 2010 clients BUT almost every other Outlook 2010 client in the company (even from people who are not moved yet) will give a popup that the administrator has made a change and that Outlook needs to be restarted.

Then, for Outlook 2013 clients, recycling the AppPool doesn't work at all. They keep getting the credential popup. I can create a new profile for them and then Outlook connects but if I then restart Outlook again, there is again a popup for credentials.

Also, Test E-mail autoconfiguration works fine for them.

For those Outlook 2013 users, I tried adding the following registry key "MapiHttpDisabled" and then both their old and their new Outlook profile work without any popups! However, when I check the connection status, it still shows HTTP for the protocol, which means to me that they are still using MAPI over HTTP protocol, right?

Also, when I check the IIS Logs, I only see calls on MAPI protocol, even for those users where I added the registry key:

2017-06-08 09:27:25 10.132.33.12 POST /mapi/emsmdb/

For now we are adding the registry key for all the 2013 users as it seems to be a workaround but it doesn't feel like a good solution:

• MapiHttp is the protocol of the future so I don't want to disable it

• The registry doesn't seem to completely disable it because users still seem to be connected via MapiHttp (according to connection status and IIS logs)??? Does this key do something else as well?

• It doesn't solve the problem of having the restart the AppPools for 2010 users.

The following are things I tried already:

• Check OAB settings on the database: they are correctly configured

• In IIS change Windows Authentication providers of the Autodiscover, EWS and OAB virtual directory to only NTLM (I also simply tried moving NTLM to the top and leaving Negotiate). I tried this on both servers

• I enabled Kernel-mode authentication on Autodiscover virtual directory for Windows Authentication

• I added the Negotiate:Kerberos provider to the mapi virtual directory on Exchange 2016

• I added the autodiscover and webmail URL to the trusted sites in Internet Explorer

• There is no proxy server enabled

None of these seems to make a difference. Sometimes, changing these settings gave popups for users that didn't have problems.

Any other suggestions?

Solution

I think I solved it now. MAPI/HTTP is enabled for a few users and no popups appear anymore.

How?

I installed the Connectivity Analyzer client and it showed me that the MAPI Address Book Endpoint failed:

 Error from Connectivity Analyzer:

Testing the address book "Check Name" operation for user xxx against server xxx.
An error occurred while attempting to resolve the name.
Additional Details
Additional Details: A protocol layer error occured. HttpStatusCode: 401
FailureLID: 47372
FailureInfo:

###### REQUEST [2016-09-14T05:06:35.2485121Z] ######

POST /mapi/nspi/?mailboxId=1ad81e37-e4a2-44d9-a465-a7565716b59f@xxx HTTP/1.1
Content-Type: application/octet-stream
User-Agent: MapiHttpClient
X-RequestId: 89b62b49-2d57-4ee2-ba4c-d675bc301556:1
X-ClientInfo: 8d6dea85-a922-4fb3-b454-bc89f733b8c1:1
X-RequestType: Bind
X-ClientApplication: MapiHttpClient/15.01.0106.000
Authorization: Negotiate [truncated]
Host: xxx 
Content-Length: 45

--- REQUEST BODY [+0.003] ---
..[BODY SIZE: 45]

--- REQUEST SENT [+0.003] ---

###### RESPONSE [+0.014] ######

HTTP/1.1 401 Unauthorized
request-id: 1d47e4b9-9933-45c5-96bf-2e4d660a9fd3
X-FailureContext: FrontEnd;401;VW5hdXRob3JpemVk;;;;
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate [truncated]
X-Powered-By: ASP.NET
X-FEServer: MELP-EXCH01
Date: Wed, 14 Sep 2016 05:06:35 GMT
Content-Length: 0

--- RESPONSE BODY [+0.014] ---

--- RESPONSE DONE [+0.014] ---

###### EXCEPTION THROWN [+0.014] ######


HTTP Response Headers:
request-id: 1d47e4b9-9933-45c5-96bf-2e4d660a9fd3
X-FailureContext: FrontEnd;401;VW5hdXRob3JpemVk;;;;
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate 

oXgwdqADCgEBom8EbWBrBgkqhkiG9xIBAgIDAH5cMFqgAwIBBaEDAgEepBEYDzIwMTYwOTE0MDUwNjM1WqUEAgIWjKYDAgEpqRUbE0dSSUZGSVRISEFDSy5DT00uQVWqGTAXoAMCAQGhEDAOGwxtZWxwLWV4Y2gwMSQ=,NTLM
X-Powered-By: ASP.NET
X-FEServer: MELP-EXCH01
Date: Wed, 14 Sep 2016 05:06:35 GMT
Content-Length: 0
HttpStatusCode: 401 Unauthorized
Elapsed Milliseconds: 15

I have been trying many different fixes and now I'm not sure which one was the solution. These are the things I did (all in IIS):

• Put NTLM on top (instead of Negotiate) for Windows Authentication on "Exchange Back End\mapi\emssmdb" and "Exchange Back End\mapi\nspi"

• Removed "Require SSL" for "Exchange Back End\mapi\nspi"

• Gave Exchange computer account and NETWORK SERVICE full access on "D:\Program Files\Microsoft\Exchange Server\V15\ClientAccess"

• Removed Negotiate from the providers of Windows Authentication of MAPI dirtual directory (Default First Website)

• IISReset

Now the Connectivity Analyzer connects using NTLM and it doesn't throw any errors anymore. I don't know why it's like this because I think that default settings should work or at least the clients should use NTLM only if I specify NTLM only via the "Set-MapiVirtualdirectory -IISAuthenticationmethods NTLM" command.

Comments

[BastianW]

You might try to re-validate your setup with the howto "Migrate from Exchange 2010 to Exchange 2016". Additional you can start troubleshooting your issue as explained here "Troubleshooting connection issues from users migrated from Exchange 2010 to Exchange 2013/2016"

[Jozef Woo]

Hi, thanks for your help 1) It is set to NTLM 2) It's not a change that we have foreseen but I will try this with a user and check. About MAPI/HTTP vs Outlook Anywhere, I think the former should simply show as HTTP in the protocol column and the latter will show as RPC/HTTP. So in this case, I add the registry key and Outlook still connects via MAPI/HTTP which is not the behaviour you expect.

[Sue.J]

Yes, the Protocol column will show as RPC/HTTP. So you disabled MAPI/HTTP on the Outlook 2013 client, then Outlook 2013 is able to connect to Exchange server without any problems, and it is connecting with MAPI/HTTP(even you disabled it) instead or RPC/MAPI. Is my understanding correct? It sounds interesting!

[Jozef Woo]

Hi Sue, yes, that's what I saw. Seems to be some caching going on or something. With some users I see RPC/HTTP for their own mailbox but Outlook is still making MapiHttp connections to other mailboxes/users (even when there is no shared mailbox mapped!). I guess the registry key doesn't work for a 100%? If I disable MapiHttp on the server side for the user, then this behaviour does not happen. Also creating a new profile for the user seems to help.

[Sue.J]

Disabling MapiHttp in the organization level is somewhat radical way, because it's from server side. I agree with you that there could be some caching in the profile, as creating a new profile helps. Does the Outlook still ask for credential after creating a new profile? If yes, have you tried to change the affected user's UPN to check the result?