401 Errors on Virtual Directories Causing MAPI Connection Issues (Exchange 2013 SP1)

EDIT #2 10/21/2015
I GOT IT!!! Through blind luck, I decided to remove "Negotiate" and add "Negotiate:Kerberos" to the "Exchange Back End > mapi" folder, and I could now log onto the MAPI/HTTP test page without an error. I still could not get a profile to fully work, so I fiddled some more with the MAPI folder permissions before I figured out that "Negotiate" had to be removed from the "Default Web Site > mapi" folder altogether.

So to summarize those permissions:

Default Web Site > mapi > Authentication:
Anonymous: Disabled
ASP.NET Impersonation: Disabled
Basic Authentication: Disabled
Digest Authentication: Disabled
Forms Authentication: Disabled
Windows Authentication: Enabled
 -Providers: 
   --NTLM 

Exchange Back End > mapi > Authentication:
Anonymous: Disabled
ASP.NET Impersonation: Disabled
Basic Authentication: Disabled
Digest Authentication: Disabled
Forms Authentication: Disabled
Windows Authentication: Enabled
 -Providers: 
   --Negotiate:Kerberos
   --NTLM

Thanks for all the help figuring this out!

EDIT 10/21/2015
Added some comments regarding IIS 401 logs.

EDIT 10/20/2015
Today, I followed the for virtual directory settings/permissions. All were as they should be.

EDIT 10/19/2015

I followed the newest link you provided. In fact, I did have that very same problem, with what I called "OWA login loops". The certificate encryption was exactly the problem. I switch to MS schannel, and the looping problem went away. There are no tidbits remaining of the old certificate, but the 401 problem is still there.

From the "Articles in no particular order of importance…"

The first sounded promising, as his 401 errors were pretty much identical, but nothing in that article helped. I had already seen the MS article he was referencing, and already tried those settings. I did, however, try them again… just to see if they would help. The only thing I had not tried was to move "NTLM" above "Negotiate" in the authentication > Providers section in IIS. That didn't help, either.

I also got around to following the rest of your links.

For the test scripts section, I tried them all… to include the MAPI test (which I've done a million times). They all succeeded.

[PS] D:\Exchange2013\scripts>Test-OutlookConnectivity -RunFromServerId EXCH1 -ProbeIdentity OutlookMapiHttpSelfTestProbe

MonitorIdentity                          StartTime       EndTime         Result               Error                Exception
---------------                          ---------       -------         ------               -----                ----
OutlookMapiHttp.Protocol\OutlookMapiH... 10/19/2015 1... 10/19/2015 1... Succeeded

[PS] D:\Exchange2013\scripts>Test-OutlookConnectivity -ProbeIdentity "OutlookRpcSelfTestProbe"

MonitorIdentity                          StartTime       EndTime         Result               Error                Exception
---------------                          ---------       -------         ------               -----                ----
Outlook.Protocol\OutlookRpcSelfTestProbe 10/19/2015 1... 10/19/2015 1... Succeeded


[PS] D:\Exchange2013\scripts>Test-OutlookConnectivity "OutlookRpcDeepTestProbe\cabuzzi_2015" -RunFromServerId EXCH1 -Mai
lboxId chris@cabuzzi.com

MonitorIdentity                          StartTime       EndTime         Result               Error                Exception
---------------                          ---------       -------         ------               -----                ----
Outlook.Protocol\OutlookRpcDeepTestPr... 10/19/2015 1... 10/19/2015 1... Succeeded


[PS] D:\Exchange2013\scripts>$TestCredentials = Get-Credential

cmdlet Get-Credential at command pipeline position 1
Supply values for the following parameters:
Credential
[PS] D:\Exchange2013\scripts>Test-OutlookConnectivity -ProbeIdentity OutlookRpcCtpProbe -MailboxId chris@cabuzzi.com -Cr
edential $TestCredentials

MonitorIdentity                          StartTime       EndTime         Result               Error                Exception
---------------                          ---------       -------         ------               -----                ----
Outlook\OutlookRpcCtpProbe               10/19/2015 1... 10/19/2015 1... Succeeded


[PS] D:\Exchange2013\scripts>Test-OutlookConnectivity -ProbeIdentity "OutlookRpcCTPProbe" -MailboxID chris@cabuzzi.com

MonitorIdentity                          StartTime       EndTime         Result               Error                Exception
---------------                          ---------       -------         ------               -----                ----
Outlook\OutlookRpcCtpProbe               10/19/2015 1... 10/19/2015 1... Succeeded

I also re-ran all the tests on the Exchange Connectivity Analyzer. All passed. Here are the XML results from the "Outlook Connectivity" test, which is the most relevant:

(I had to remove the XML, because the main post was too long. Long story short, it passed with flying colors)

You also posted an MS link regarding authentication issues when running 2007/2010 in a Windows 2008 environment. I am only running Exchange 2013 SP1 in a Windows 2012 environment. I did, a year or so back, have an Exchange 2010 server. Not sure if there is anything left over from that… but if so, it is not showing up in ADSI Edit.

Finally, I AM using the MapiHttpDisabled registry key. I set it at "0" to enable MAPI while testing for a fix, and set it back to "1" when I actually need to open Outlook and do work.

The only other thing I have to look at is the Virtual Directory page. I will go over that tonight.

Thanks again for all the help.

EDIT
So just for the heck of it, I changed the autodiscover and mail A records to the ARR, just to see if it would change anything. There was no change, instead, some of the IIS error logs show up on the ARR now.

I will check out all the links you posted tomorrow!

Here is a sample of some of the logs from each server:

.97 is the ARR
.220 and .228 are clients/workstations
.104 is EXCH1

From the ARR server:

2015-10-18 22:59:05 192.168.1.97 POST /ews/Exchange.asmx X-ARR-LOG-ID=9510ed1a-a8f8-4d91-b4ef-a43ec4b37dce 443 - 192.168.1.228 Microsoft+Office/15.0+(Windows+NT+6.2;+Microsoft+Outlook+15.0.4667;+Pro) - 401 0 0 0
2015-10-18 22:59:05 192.168.1.97 POST /ews/Exchange.asmx X-ARR-LOG-ID=efdd0650-3308-4c0a-93b6-11b119ae69ad 443 - 192.168.1.228 Microsoft+Office/15.0+(Windows+NT+6.2;+Microsoft+Outlook+15.0.4667;+Pro) - 200 0 0 140
2015-10-18 23:04:14 192.168.1.97 POST /mapi/nspi/ MailboxId=245d5ddf-bafd-412f-8ada-c94ec4f59c6f@cabuzzi.com&X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=cc6b81b4-f843-482a-9503-50bad60ae152 443 - 192.168.1.220 Microsoft+Office/16.0+(Windows+NT+10.0;+Microsoft+Outlook+16.0.4266;+Pro) - 401 0 0 46

From EXCH1

2015-10-18 23:08:48 ::1 GET /ecp/ReportingWebService/ &CorrelationID=<empty>;&cafeReqId=b90a694e-2059-4c17-9748-4658134c00ca; 443 - ::1 AMProbe/Local/ClientAccess - 302 0 0 0
2015-10-18 23:08:51 ::1 RPC_IN_DATA /rpc/rpcproxy.dll 913fd51c-b6d6-4470-b859-31e775a35351@cabuzzi.com:6001&CorrelationID=<empty>;&RequestId=aa3fbeba-1e95-41bd-9097-155bfed9ef03&cafeReqId=aa3fbeba-1e95-41bd-9097-155bfed9ef03; 443 - ::1 MSRPC - 401 1 2148074254 0
2015-10-18 23:08:51 ::1 RPC_IN_DATA /rpc/rpcproxy.dll 913fd51c-b6d6-4470-b859-31e775a35351@cabuzzi.com:6001&CorrelationID=<empty>;&RequestId=f5b1b4a3-36a3-4794-8ec0-841d6b2f795f&cafeReqId=f5b1b4a3-36a3-4794-8ec0-841d6b2f795f; 443 CABUZZI\SM_4a59733b1538499da ::1 MSRPC - 200 0 0 62
2015-10-18 23:08:51 192.168.1.104 RPC_IN_DATA /rpc/rpcproxy.dll 913fd51c-b6d6-4470-b859-31e775a35351@cabuzzi.com:6001&CorrelationID=<empty>;&RequestId=1cb5dfb8-1e2b-4beb-982c-e96262f0cd4c&cafeReqId=1cb5dfb8-1e2b-4beb-982c-e96262f0cd4c; 443 - 192.168.1.104 MSRPC - 401 1 2148074254 0

First post, so please be easy on me.

I'm running a two-server Exchange 2013 SP1 setup in my domain. I use ARR for a reverse proxy, and the same internal/external domain names across the board. I do not have an internal loadbalancer, so I use DNS round robin.

Everything works fine when using RPC/HTTP, but when I try switching the organization to MAPI, I get never-ending login prompts. I've double, triple, and quadruple checked my SSL certificate, virtual directory auth methods, internal/external URIs, etc. Also, every MSRCA test works perfectly, to include both Outlook tests. That lead me to dig down into the IIS logs, where I found that it may not be MAPI with the problems (especially since the MAPI test probe passes successfully).

I've narrowed down the problem to a 401 on several folders, most notably, autodiscover and mapi. The crazy thing is, when I use the direct host name of one of the exchange servers, I have no issues. A test page to a mapi or autodiscover url in IE works just like it should. I've set the autodiscover and mail A records to my first exchange server during troubleshooting, but that didn't seem to help, either.

So if I enter https://mail.cabuzzi.com/mapi/emsmdb in IE, I get a looping password prompt, and a 401 in my IIS logs (verified using Fiddler, as well). If I enter https://exch1.cabuzzi.com/mapi/emsmdb, I get a certificate error… but I return a positive result, even though mail.cabuzzi.com and exch1.cabuzzi.com both resolve to the same IP. Autodiscover resolves to the EXCH1 IP as well, and has an appropriate SAN entry in the Exchange SSL cert (from GoDaddy).

I should also point out that the 401 errors don't really go away when I force MapiHttpDisabled on a client PC, they just don't seem to affect Outlook building a new profile, or opening up email on an existing profile. Once I clear the MapiHttpDisabled setting, I get the password prompt for an existing profile and a failure to even create a new profile.

Any ideas? I'm really stumped here, and my head is starting to swim after two weeks (on and off) of troubleshooting.