After Enabling MAPI over HTTP on Exchange 2013 SP1, Outlook 2013 SP1 clients prompt for logon credentials during profile creation
We have an Exchange 2013 Sp1 CU7 server that houses all roles. we configured the mapi virtual directory so that it is using the same name space externally and internally and that namespace is on a trusted certificate installed in Exchange.
We enabled MAPI over HTTP in the org config.
Outlook 2010 SP3 clients are able to create a profile automatically via autodiscover and connect with MAPI over HTTP verified by Outlook connection manager.
Outlook 2013 SP1 clients now prompt for credentials when creating a profile and every time afterwards when opening Outlook.
Both outlook 2013 SP1 and outlook 2010 SP3 clients used to just automatically create a profile based on autodiscover. It seems something is not quite right with authentication on the MAPI virtual directory but I don't understand why outlook 2010 works but 2013 does not. We have NTLM auth method configured on the MAPI virtual directory.
Exchange
Last Comment
NBF
8/22/2022 - Mon
Guy Lidbetter
Do you have any legacy estate still in place? Or is this a fresh 2013 install?
If you type
Get-OutlookAnywhere | FT Identity,*auth* -AutoSize
what certprincipalname values do you get for EXPR and EXCH??
NBF
ASKER
We have no legacy 2010 in place. Just the single 2013 SP1 exchange server.
Outlook anywhere has been working great since deployment.(RPC over HTTP) User profiles create automatically internally and externally and all tests come up good. Only MAPI over HTTP is causing issues.
IIS Auth methods for outlook anywhere are basic, ntlm, negotiate. internal and external client auth methods for outlook anywhere are ntlm.
get-outlookprovider is interesting. It points to an old server name. I didn't think these were used any longer. VM-EXCH-1 does not exist.
Name Server CertPrincipalName TTL
---- ------ ----------------- ---
EXCH vm-exch-1 1
EXPR 1
WEB vm-exch-1 1
This issue occurs when we set the mapi virtual directory and enabled mapi over http the new protocol.
Set-MapiVirtualDirectory –Identity “VM-xxxxxxxx\mapi (Default Web Site)” -InternalUrl https://mail.xxxxx.com/mapi –ExternalUrl https://mail.xxxxx.com/mapi -IISAuthenticationMethods Ntlm, OAuth, Negotiate
Then we ran: Set-OrganizationConfig -MapiHttpEnabled $true
Outlook 2013 Sp1 clients prompt for logon when creating a new profile.
Outlook 2010 works perfectly and connects over MAPI without logon prompt.
After further troubleshooting it appears that we are only getting the logon prompt one time with outlook 2013 SP1 clients. either the first time they create a profile during profile creation or when the client sees that MAPI over HTTP is a supported protocol and tries to switch over then a windows logon prompt is presented. If they auth then it appears to work fine going forward between reboots, etc. I would still like to eliminate this windows logon prompt when Outlook 2013 SP1 is creating a profile or switching from RPC/HTTP to MAPI/HTTP.
Outlook 2010 is working fine creating profiles and switching from RPC/HTTP to MAPI/HTTP
These normally tell outlook anywhere clients what mailbox server to try and connect to, as they don't exist anyway this would be useful.
NBF
ASKER
Everything I read says that is for windows xp or old versions but I have done what you suggested and corrected them so they point to the correct server name. The behavior is the same. Outlook 2013 Sp1 clients prompt for logon credentials when creating an outlook profile or when switching for RPC/HTTP to MAPI/HTTP protocol. Once credentials are supplied it continues to work fine without prompting for credentials. I would like to be able to fix this so that no logon prompt appears.
Name Server CertPrincipalName TTL
---- ------ ----------------- ---
EXCH VM-xxxx msstd:mail.xxxx.com 1
EXPR VM-xxxx msstd:mail.xxxx.com 1
WEB VM-xxxx 1
Guy Lidbetter
Is there a reason OAuth is configured on IISAuthenticationMethods in your Mapi Virtual Directory?
The Server field actually tells the client what server to conenct to for RPC\HTTP, it's more than likely not an issue, however I have seen some odd behavior when these are set incorrectly. EXCH is used for internal connections and EXPR for external.
NBF
ASKER
No. The behavior does not change with it removed. I just added it for testing. I have removed it so it is just NTLM and NEGOTIATE now. I retested and everything is behaving the same.
Guy Lidbetter
One other thing to try is to set outlookanywhere to
It makes me nervous to make changes to Outlook anywhere since that is working. I would hate for users to get popups all of a sudden. Do you really think this issue could be caused me settings on outlook anywhere rather than the mapi VD?
If you're not comfortable don't do it... The only other place this could be is in IIS, select the MAPI VD, Open authentication, click Windows Authentication and on the right hand side action pane select providers.
It should be NTLM then Negotiate.
Bare in mind you should restart iis after making changes with IISRESET /NOFORCE.
NBF
ASKER
Mapi VD windows auth is enabled but negotiate is first and NTLM is second. Should I swap them? Think that could be it?
I probably have to wait until tonight to perform IISRESET I don't want to cause problems for connected users midday.
Ok, I will make this change and report back my findings. Thanks!
NBF
ASKER
It doesn't matter what provider is listed first. I tried it both ways and as long as negotiate is configured on the mapi virtual directory auth it always connects with negotiate. I tried setting it to NTLM only and it was even worse causing a logon prompt on every open of Outlook except just at profile creation when it is set to ntlm,negotiate.
It seems the provider order isn't at play here. I have no idea why this is not working and only not working with Outlook 2013 clients but works fine with Outlook 2010 clients.
Outlook 2013 uses a completely different mechanism for connecting and authenticating.
Exchange 2013 has some new providers and Autodiscover behavior.
It no longer directly uses EXPR/EXCH Outlook Providers, it has two different dynamically generated EXHTTP providers. Users with mailboxes on 2013 will get one set of EXHTTP settings for internal usage and one set of EXHTTP settings for external usage. It will then use these in the order received.
Could you provide the "Test Email Autoconfiguration" output from an Outlook 2013 client, maybe we can figure out whats happening from there....
NBF
ASKER
I am not sure how to do that since the window is not copy and pastable.
As far as I can tell, this all looks great... I'm kinda stumped why you would be getting these prompts.
One last thing I feel is worth checking, as you still had some legacy servers in the provider list and this is happening when auto completing the profile, is check that the legacy SCP records aren't still in your config partition.
Are the old servers shut down and decommed completely?
Otherwise its wireshark time....
NBF
ASKER
I agree. We are opening a case with microsoft. This appears to be some sort of bug. Our setup looks correct by everyone who has reviewed it.
Our only solution to this was to change everyone's UPN to match their primary SMTP email address and train users to log in with username@xxx.com instead of domainname\username
If you type
Open in new window
What values do you get for authentication?And
Open in new window
what certprincipalname values do you get for EXPR and EXCH??