Ситуация:
Сосуществование Exchange 2010 и 2016. Outlook Anywhere включен на обоих устройствах с NTLM
webmail.domain.com настроен как пространство имен CAS (для всех виртуальных каталогов в 2016 г.)
autodiscover.domain.local / autodiscover.autodiscover.xml настроен как SCP (внешнее автообнаружение не используется)
Точки DNS для обоих вышеуказанных URL-адресов для Exchange 2016
При переносе почтовых ящиков с 2010 на 2016 происходит следующее:
Для пользователя Outlook 2010:
Пользователь получает всплывающее окно с сообщением, что администратор внес изменения и необходимо перезапустить Outlook.
Пользователь перезапускает Outlook (иногда снова появляется то же всплывающее окно, а затем снова перезапускает Outlook)
Пользователи получают всплывающее окно с учетными данными. Если вы нажмете «Отмена», появится другое всплывающее окно:
"Разрешить этому веб-сайту настраивать параметры сервера test2010@domain.com?"
autodiscover.domain.com/autodiscover/autodiscover.xml
Как видите, Outlook 2010 ищет autodiscover.domain.com, и это, вероятно, связано с ошибкой поиска SCP.
Если я провожу тест автоконфигурации Outlook, он не работает. Поиск SCP продолжает давать редирект 302.
Кажется, это проблема, описанная здесь:
Я могу повторно использовать эти пулы приложений, и тогда, похоже, это работает для некоторых клиентов Outlook 2010, НО почти каждый другой клиент Outlook 2010 в компании (даже от людей, которые еще не переехали) выдает всплывающее окно, которое администратор сделал изменить и что Outlook необходимо перезапустить.
Затем для клиентов Outlook 2013 утилизация AppPool вообще не работает. Они продолжают получать всплывающее окно с учетными данными. Я могу создать для них новый профиль, а затем Outlook подключится, но если я снова перезапущу Outlook, снова появится всплывающее окно для учетных данных.
Также для них отлично работает автоконфигурация тестовой электронной почты.
Для этих пользователей Outlook 2013 я попытался добавить следующий раздел реестра «MapiHttpDisabled», и тогда их старый и новый профиль Outlook работали без каких-либо всплывающих окон! Однако, когда я проверяю статус подключения, он по-прежнему показывает HTTP для протокола, что для меня означает, что они все еще используют протокол MAPI поверх HTTP, верно?
Кроме того, когда я проверяю журналы IIS, я вижу только вызовы протокола MAPI, даже для тех пользователей, которым я добавил ключ реестра:
2017-06-08 09:27:25 10.132.33.12 POST / mapi / emsmdb /
На данный момент мы добавляем раздел реестра для всех пользователей 2013 года, поскольку это кажется временным решением, но не похоже на хорошее решение:
MapiHttp - это протокол будущего, поэтому я не хочу его отключать
Реестр, похоже, не отключает его полностью, потому что пользователи все еще, похоже, подключены через MapiHttp (в соответствии со статусом подключения и журналами IIS) ??? Этот ключ делает что-то еще?
Это не решает проблему перезапуска пулов приложений для пользователей 2010 года.
Вот что я уже пробовал:
Проверьте настройки автономной адресной книги в базе данных: они правильно настроены
В IIS измените поставщиков проверки подлинности Windows для виртуального каталога Autodiscover, EWS и OAB только на NTLM (я также просто попытался переместить NTLM наверх и оставить Negotiate). Я пробовал это на обоих серверах
Я включил проверку подлинности в режиме ядра в виртуальном каталоге автообнаружения для проверки подлинности Windows
Я добавил поставщика Negotiate: Kerberos в виртуальный каталог mapi на Exchange 2016
Я добавил URL-адрес автообнаружения и веб-почты на надежные сайты в Internet Explorer
Не включен прокси-сервер
Кажется, что все это не имеет значения. Иногда изменение этих настроек приводило к появлению всплывающих окон для пользователей, у которых не было проблем.
Есть другие предложения?
Думаю, я решил это сейчас. MAPI / HTTP включен для некоторых пользователей, и всплывающие окна больше не появляются.
Как?
Я установил клиент Connectivity Analyzer, и он показал мне, что конечная точка адресной книги MAPI не работает:
Error from Connectivity Analyzer:
Testing the address book "Check Name" operation for user xxx against server xxx.
An error occurred while attempting to resolve the name.
Additional Details
Additional Details: A protocol layer error occured. HttpStatusCode: 401
FailureLID: 47372
FailureInfo:
###### REQUEST [2016-09-14T05:06:35.2485121Z] ######
POST /mapi/nspi/?mailboxId=1ad81e37-e4a2-44d9-a465-a7565716b59f@xxx HTTP/1.1
Content-Type: application/octet-stream
User-Agent: MapiHttpClient
X-RequestId: 89b62b49-2d57-4ee2-ba4c-d675bc301556:1
X-ClientInfo: 8d6dea85-a922-4fb3-b454-bc89f733b8c1:1
X-RequestType: Bind
X-ClientApplication: MapiHttpClient/15.01.0106.000
Authorization: Negotiate [truncated]
Host: xxx
Content-Length: 45
--- REQUEST BODY [+0.003] ---
..[BODY SIZE: 45]
--- REQUEST SENT [+0.003] ---
###### RESPONSE [+0.014] ######
HTTP/1.1 401 Unauthorized
request-id: 1d47e4b9-9933-45c5-96bf-2e4d660a9fd3
X-FailureContext: FrontEnd;401;VW5hdXRob3JpemVk;;;;
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate [truncated]
X-Powered-By: ASP.NET
X-FEServer: MELP-EXCH01
Date: Wed, 14 Sep 2016 05:06:35 GMT
Content-Length: 0
--- RESPONSE BODY [+0.014] ---
--- RESPONSE DONE [+0.014] ---
###### EXCEPTION THROWN [+0.014] ######
HTTP Response Headers:
request-id: 1d47e4b9-9933-45c5-96bf-2e4d660a9fd3
X-FailureContext: FrontEnd;401;VW5hdXRob3JpemVk;;;;
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate
oXgwdqADCgEBom8EbWBrBgkqhkiG9xIBAgIDAH5cMFqgAwIBBaEDAgEepBEYDzIwMTYwOTE0MDUwNjM1WqUEAgIWjKYDAgEpqRUbE0dSSUZGSVRISEFDSy5DT00uQVWqGTAXoAMCAQGhEDAOGwxtZWxwLWV4Y2gwMSQ=,NTLM
X-Powered-By: ASP.NET
X-FEServer: MELP-EXCH01
Date: Wed, 14 Sep 2016 05:06:35 GMT
Content-Length: 0
HttpStatusCode: 401 Unauthorized
Elapsed Milliseconds: 15
Я пробовал много разных исправлений и теперь не уверен, какое из них было решением. Вот что я сделал (все в IIS):
Поместите NTLM поверх (вместо согласования) для проверки подлинности Windows на «Exchange Back End \ mapi \ emssmdb» и «Exchange Back End \ mapi \ nspi»
Удалено «Требовать SSL» для «Exchange Back End \ mapi \ nspi».
Предоставил учетной записи компьютера Exchange и СЕТЕВОЙ СЛУЖБЕ полный доступ к "D: \ Program Files \ Microsoft \ Exchange Server \ V15 \ ClientAccess"
Удалено согласование из поставщиков проверки подлинности Windows для грязного каталога MAPI (первый веб-сайт по умолчанию)
IISReset
Теперь анализатор подключения подключается с помощью NTLM и больше не выдает ошибок. Я не знаю, почему это так, потому что я думаю, что настройки по умолчанию должны работать или, по крайней мере, клиенты должны использовать NTLM только в том случае, если я указываю NTLM только с помощью команды "Set-MapiVirtualdirectory -IISAuthenticationmethods NTLM".
К вышеуказанным проблемам с Outlook 2013:
Убедитесь, что метод аутентификации виртуального каталога MAPI - NTLM. Вы можете проверить это, запустив Get-MAPIVirtualDirectory или измените его, запустив Set-MAPIVirtualDirectory на сервере Exchange 2016.
Исходя из моего опыта, если UPN пользователя и PrimarySMTPAddress не совпадают, Outlook 2013/2016 запросит учетные данные при инициировании соединения через MAPI \ HTTP. Вы можете проверить это, запустив Get-Mailbox userA | fl UserPrincipalName, PrimarySMTPAddress. Или измените его, запустив Set-Mailbox UserA -UserPrincipalName xxx.
Кроме того, Exchange 2016 поддерживает только MAPI \ HTTP и RPC \ HTTP, а MAPI \ HTTP является методом подключения по умолчанию. После того, как вы отключили MAPI \ HTTP, Outlook будет подключаться к Exchange через RPC \ HTTP, поэтому вы все равно будете видеть HTTP в статусе подключения Outlook.