Start Free Trial

asked on

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.

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

Open in new window

What values do you get for authentication?

And

Get-OutlookProvider

Open in new window

what certprincipalname values do you get for EXPR and EXCH??

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.

ServerName : VM-xxxxxxxx
SSLOffloading : True
ExternalHostname : mail.xxxx.com
InternalHostname : mail.xxxx.com
ExternalClientAuthenticationMethod : Ntlm
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods : {Basic, Ntlm, Negotiate}
XropUrl :
ExternalClientsRequireSsl : True
InternalClientsRequireSsl : True

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.

Here is get-mapivirtualdirectory:
RunspaceId : 075e40b8-de0a-4269-b934-37e9594f7cfb
IISAuthenticationMethods : {Ntlm, OAuth, Negotiate}
MetabasePath : IIS://VM-xxxxxxxx.xxxxxxx.biz/W3SVC/1/ROOT/mapi
Path : C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\mapi
ExtendedProtectionTokenChecking : None
ExtendedProtectionFlags : {}
ExtendedProtectionSPNList : {}
AdminDisplayVersion : Version 15.0 (Build 1044.25)
Server : VM-xxxxx
InternalUrl : https://mail.xxxx.com/mapi
InternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}
ExternalUrl : https://mail.xxxx.com/mapi
ExternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}

ASKER

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

Try removing the server names from the Outlook provider.

Set-OutlookProvider EXCH -Server $null
Set-OutlookProvider EXPR -Server $null

Open in new window

These normally tell outlook anywhere clients what mailbox server to try and connect to, as they don't exist anyway this would be useful.

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

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.

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.

One other thing to try is to set outlookanywhere to

ExternalClientAuthenticationMethod : Negotiate
InternalClientAuthenticationMethod : Negotiate
IISAuthenticationMethods : {Ntlm, Negotiate}

and mapi VD

IISAuthenticationMethods : {Ntlm, Negotiate}

ASKER

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?

We currently have OutlookAnywhere set to:

ExternalClientAuthenticationMethod : ntlm
InternalClientAuthenticationMethod : ntlm
IISAuthenticationMethods : {basic, Ntlm, Negotiate}

I changed MAPI VD to ntlm,negotiate.

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.

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.

That could possibly be it, yes.

ASKER

Ok, I will make this change and report back my findings. Thanks!

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....

ASKER

I am not sure how to do that since the window is not copy and pastable.

Use the XML tab...

ASKER

Gotcha! Here it is with personal info swapped out.

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<User>
<DisplayName>MY NAME</DisplayName>
<LegacyDN>/O=DOMAIN CO/OU=MIL/cn=Recipients/cn=MYNAME</LegacyDN>
<AutoDiscoverSMTPAddress>MYNAME@EXAMPLE.COM</AutoDiscoverSMTPAddress>
<DeploymentId>615d33e5-ce09-4ee4-b950-0652db135467</DeploymentId>
</User>
<Account>
<AccountType>email</AccountType>
<Action>settings</Action>
<MicrosoftOnline>False</MicrosoftOnline>
<Protocol Type="mapiHttp" Version="1">
<MailStore>
<InternalUrl>https://mail.EXAMPLE.COM/mapi/emsmdb/?MailboxId=292aeb52-335e-4f8f-952a-683f3cc98ec0@EXAMPLE.COM</InternalUrl>
<ExternalUrl>https://mail.EXAMPLE.COM/mapi/emsmdb/?MailboxId=292aeb52-335e-4f8f-952a-683f3cc98ec0@EXAMPLE.COM</ExternalUrl>
</MailStore>
<AddressBook>
<InternalUrl>https://mail.EXAMPLE.COM/mapi/nspi/?MailboxId=292aeb52-335e-4f8f-952a-683f3cc98ec0@EXAMPLE.COM</InternalUrl>
<ExternalUrl>https://mail.EXAMPLE.COM/mapi/nspi/?MailboxId=292aeb52-335e-4f8f-952a-683f3cc98ec0@EXAMPLE.COM</ExternalUrl>
</AddressBook>
</Protocol>
<Protocol>
<Type>WEB</Type>
<Internal>
<OWAUrl AuthenticationMethod="Basic, Fba">https://mail.EXAMPLE.COM/owa/</OWAUrl>
<Protocol>
<Type>EXCH</Type>
<ASUrl>https://mail.EXAMPLE.COM/EWS/Exchange.asmx</ASUrl>
</Protocol>
</Internal>
<External>
<OWAUrl AuthenticationMethod="Fba">https://mail.EXAMPLE.COM/owa/</OWAUrl>
<Protocol>
<Type>EXPR</Type>
<ASUrl>https://mail.EXAMPLE.COM/EWS/Exchange.asmx</ASUrl>
</Protocol>
</External>
</Protocol>
<Protocol>
<Type>EXHTTP</Type>
<Server>mail.EXAMPLE.COM</Server>
<SSL>On</SSL>
<AuthPackage>Ntlm</AuthPackage>
<ASUrl>https://mail.EXAMPLE.COM/EWS/Exchange.asmx</ASUrl>
<EwsUrl>https://mail.EXAMPLE.COM/EWS/Exchange.asmx</EwsUrl>
<EmwsUrl>https://mail.EXAMPLE.COM/EWS/Exchange.asmx</EmwsUrl>
<SharingUrl>https://mail.EXAMPLE.COM/EWS/Exchange.asmx</SharingUrl>
<EcpUrl>https://mail.EXAMPLE.COM/ecp/</EcpUrl>
<EcpUrl-um>?rfr=olk&p=customize/voicemail.aspx&exsvurl=1&realm=OURDOMAIN.LOCAL</EcpUrl-um>
<EcpUrl-aggr>?rfr=olk&p=personalsettings/EmailSubscriptions.slab&exsvurl=1&realm=OURDOMAIN.LOCAL</EcpUrl-aggr>
<EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?rfr=olk&exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx>&realm=OURDOMAIN.LOCAL</EcpUrl-mt>
<EcpUrl-ret>?rfr=olk&p=organize/retentionpolicytags.slab&exsvurl=1&realm=OURDOMAIN.LOCAL</EcpUrl-ret>
<EcpUrl-sms>?rfr=olk&p=sms/textmessaging.slab&exsvurl=1&realm=OURDOMAIN.LOCAL</EcpUrl-sms>
<EcpUrl-photo>PersonalSettings/EditAccount.aspx?rfr=olk&chgPhoto=1&exsvurl=1&realm=OURDOMAIN.LOCAL</EcpUrl-photo>
<EcpUrl-tm>?rfr=olk&ftr=TeamMailbox&exsvurl=1&realm=OURDOMAIN.LOCAL</EcpUrl-tm>
<EcpUrl-tmCreating>?rfr=olk&ftr=TeamMailboxCreating&SPUrl=<SPUrl>&Title=<Title>&SPTMAppUrl=<SPTMAppUrl>&exsvurl=1&realm=OURDOMAIN.LOCAL</EcpUrl-tmCreating>
<EcpUrl-tmEditing>?rfr=olk&ftr=TeamMailboxEditing&Id=<Id>&exsvurl=1&realm=OURDOMAIN.LOCAL</EcpUrl-tmEditing>
<EcpUrl-extinstall>Extension/InstalledExtensions.slab?rfr=olk&exsvurl=1&realm=OURDOMAIN.LOCAL</EcpUrl-extinstall>
<OOFUrl>https://mail.EXAMPLE.COM/EWS/Exchange.asmx</OOFUrl>
<UMUrl>https://mail.EXAMPLE.COM/EWS/UM2007Legacy.asmx</UMUrl>
<OABUrl>https://mail.EXAMPLE.COM/oab/a1e63f24-25a0-41e9-a248-f4e42872d3f7/</OABUrl>
<ServerExclusiveConnect>On</ServerExclusiveConnect>
</Protocol>
<Protocol>
<Type>EXHTTP</Type>
<Server>mail.EXAMPLE.COM</Server>
<SSL>On</SSL>
<AuthPackage>Ntlm</AuthPackage>
<ASUrl>https://mail.EXAMPLE.COM/EWS/Exchange.asmx</ASUrl>
<EwsUrl>https://mail.EXAMPLE.COM/EWS/Exchange.asmx</EwsUrl>
<EmwsUrl>https://mail.EXAMPLE.COM/EWS/Exchange.asmx</EmwsUrl>
<SharingUrl>https://mail.EXAMPLE.COM/EWS/Exchange.asmx</SharingUrl>
<EcpUrl>https://mail.EXAMPLE.COM/ecp/</EcpUrl>
<EcpUrl-um>?rfr=olk&p=customize/voicemail.aspx&exsvurl=1&realm=OURDOMAIN.LOCAL</EcpUrl-um>
<EcpUrl-aggr>?rfr=olk&p=personalsettings/EmailSubscriptions.slab&exsvurl=1&realm=OURDOMAIN.LOCAL</EcpUrl-aggr>
<EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?rfr=olk&exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx>&realm=OURDOMAIN.LOCAL</EcpUrl-mt>
<EcpUrl-ret>?rfr=olk&p=organize/retentionpolicytags.slab&exsvurl=1&realm=OURDOMAIN.LOCAL</EcpUrl-ret>
<EcpUrl-sms>?rfr=olk&p=sms/textmessaging.slab&exsvurl=1&realm=OURDOMAIN.LOCAL</EcpUrl-sms>
<EcpUrl-photo>PersonalSettings/EditAccount.aspx?rfr=olk&chgPhoto=1&exsvurl=1&realm=OURDOMAIN.LOCAL</EcpUrl-photo>
<EcpUrl-tm>?rfr=olk&ftr=TeamMailbox&exsvurl=1&realm=OURDOMAIN.LOCAL</EcpUrl-tm>
<EcpUrl-tmCreating>?rfr=olk&ftr=TeamMailboxCreating&SPUrl=<SPUrl>&Title=<Title>&SPTMAppUrl=<SPTMAppUrl>&exsvurl=1&realm=OURDOMAIN.LOCAL</EcpUrl-tmCreating>
<EcpUrl-tmEditing>?rfr=olk&ftr=TeamMailboxEditing&Id=<Id>&exsvurl=1&realm=OURDOMAIN.LOCAL</EcpUrl-tmEditing>
<EcpUrl-extinstall>Extension/InstalledExtensions.slab?rfr=olk&exsvurl=1&realm=OURDOMAIN.LOCAL</EcpUrl-extinstall>
<OOFUrl>https://mail.EXAMPLE.COM/EWS/Exchange.asmx</OOFUrl>
<UMUrl>https://mail.EXAMPLE.COM/EWS/UM2007Legacy.asmx</UMUrl>
<OABUrl>https://mail.EXAMPLE.COM/oab/a1e63f24-25a0-41e9-a248-f4e42872d3f7/</OABUrl>
<ServerExclusiveConnect>On</ServerExclusiveConnect>
</Protocol>
<PublicFolderInformation>
<SmtpAddress>PFHierarchy@EXAMPLE.COM</SmtpAddress>
</PublicFolderInformation>
</Account>
</Response>
</Autodiscover>

Hi NBF,

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....

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.

Well, sorry I couldn't help out any further...

ASKER

I will circle back and post the solution when I have one. It may be a few weeks.

Excellent, I'll keep pulling my hair out for an idea... I'm invested now...

ASKER CERTIFIED SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ASKER

Solution provided by m icrosoft.

Can you please share the solution to this?

ASKER

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