Ошибки 401 в виртуальных каталогах, вызывающие проблемы с подключением MAPI (Exchange 2013 SP1)

РЕДАКТИРОВАТЬ # 2 21.10.2015 ПОЛУЧИЛ !!! Благодаря слепой удаче я решил удалить «Negotiate» и добавить «Negotiate: Kerberos» в папку «Exchange Back End> mapi», и теперь я мог войти на тестовую страницу MAPI / HTTP без ошибок. Я все еще не мог заставить профиль полностью работать, поэтому я еще немного поигрался с разрешениями папки MAPI, прежде чем понял, что «Negotiate» нужно полностью удалить из папки «Default Web Site> mapi».

Итак, чтобы резюмировать эти разрешения:

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

Спасибо за помощь в выяснении этого вопроса!

РЕДАКТИРОВАТЬ 21.10.2015 Добавлены комментарии относительно журналов IIS 401.

РЕДАКТИРОВАТЬ 20.10.2015 Сегодня я следил за настройками / разрешениями виртуального каталога. Все было так, как должно быть.

РЕДАКТИРОВАТЬ 19.10.2015

Я перешел по последней предоставленной вами ссылке. Фактически, у меня была та же самая проблема с тем, что я назвал «циклами входа в систему OWA». Шифрование сертификата было именно проблемой. Я переключаюсь на MS schannel, и проблема зацикливания исчезла. От старого сертификата не осталось лакомых кусочков, но проблема 401 все еще существует.

Из «Статьи в произвольном порядке важности ...»

Первое звучало многообещающе, поскольку его ошибка 401 была практически идентична, но в этой статье ничего не помогло. Я уже видел статью MS, на которую он ссылался, и уже пробовал эти настройки. Однако я все же попробовал их снова ... просто чтобы посмотреть, помогут ли они. Единственное, чего я не пробовал, так это переместить «NTLM» выше «Negotiate» в разделе «Проверка подлинности> Провайдеры» в IIS. Это тоже не помогло.

Я также перешел по остальным вашим ссылкам.

В разделе тестовых сценариев я пробовал их все ... включая тест MAPI (который я проделывал миллион раз). Все им удалось.

[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

Я также повторно провел все тесты в анализаторе подключения к Exchange. Все прошло. Вот наиболее актуальные XML-результаты теста "Outlook Connectivity":

(Мне пришлось удалить XML, потому что основной пост был слишком длинным. Короче говоря, он прошел с честью)

Вы также разместили ссылку MS относительно проблем аутентификации при запуске 2007/2010 в среде Windows 2008. Я использую только Exchange 2013 SP1 в среде Windows 2012. Примерно год назад у меня был сервер Exchange 2010. Не уверен, что от этого что-то осталось ... но если да, то это не отображается в ADSI Edit.

Наконец, я использую раздел реестра MapiHttpDisabled. Я установил его на «0», чтобы включить MAPI во время тестирования исправления, и снова установил его на «1», когда мне действительно нужно открыть Outlook и продолжить работу.

Единственное, на что мне нужно обратить внимание, - это страница виртуального каталога. Я займусь этим сегодня вечером.

Еще раз спасибо всем за помощь.

РЕДАКТИРОВАТЬ Так что, черт возьми, я изменил автообнаружение и отправил записи A в ARR, просто чтобы посмотреть, изменит ли это что-нибудь. Никаких изменений не было, вместо этого некоторые журналы ошибок IIS теперь отображаются в ARR.

Я проверю все ссылки, которые вы разместили завтра!

Вот пример некоторых журналов с каждого сервера:

.97 - это ARR. .220 и .228 - это клиенты / рабочие станции .104 - это EXCH1.

С сервера ARR:

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

С 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

Первый пост, пожалуйста, не беспокойтесь.

Я использую двухсерверную установку Exchange 2013 SP1 в своем домене. Я использую ARR для обратного прокси и одинаковые внутренние / внешние доменные имена по всем направлениям. У меня нет внутреннего балансировщика нагрузки, поэтому я использую циклический перебор DNS.

При использовании RPC / HTTP все работает нормально, но когда я пытаюсь переключить организацию на MAPI, я получаю бесконечные запросы входа в систему. Я дважды, трижды и четыре раза проверил свой сертификат SSL, методы аутентификации виртуального каталога, внутренние / внешние URI и т. Д. Кроме того, каждый тест MSRCA работает отлично, включая оба теста Outlook. Это заставило меня покопаться в журналах IIS, где я обнаружил, что это может быть не MAPI с проблемами (тем более, что тестовый зонд MAPI проходит успешно).

Я сузил проблему до 401 в нескольких папках, в первую очередь в autodiscover и mapi. Самое безумное, когда я использую прямое имя хоста одного из серверов обмена, у меня нет проблем. Тестовая страница для mapi или URL-адреса автообнаружения в IE работает так же, как и должна. Я установил автообнаружение и отправил записи A на свой первый сервер обмена во время устранения неполадок, но это тоже не помогло.

Итак, если я войду https://mail.cabuzzi.com/mapi/emsmdb в IE я получаю циклический запрос пароля и 401 в моих журналах IIS (также проверенных с помощью Fiddler). Если я войду https://exch1.cabuzzi.com/mapi/emsmdb, Я получаю ошибку сертификата ... но я возвращаю положительный результат, хотя mail.cabuzzi.com и exch1.cabuzzi.com разрешают один и тот же IP-адрес. Автообнаружение также преобразуется в IP-адрес EXCH1 и имеет соответствующую запись SAN в сертификате Exchange SSL (от GoDaddy).

Я также должен отметить, что ошибка 401 на самом деле не исчезает, когда я принудительно использую MapiHttpDisabled на клиентском ПК, они просто не влияют на создание нового профиля в Outlook или открытие электронной почты в существующем профиле. Как только я очищаю параметр MapiHttpDisabled, я получаю запрос пароля для существующего профиля и не могу даже создать новый профиль.

Любые идеи? Я действительно в тупике, и моя голова начинает плавать после двух недель (время от времени) устранения неполадок.