- 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)
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 firstname.lastname@example.org server settings?"
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:
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?