Автообнаружение не работает - Exchange 2016

Существует два способа настроить службу автообнаружения Exchange, предполагая домен SMTP с именем "example.com":

• Можно указать, чтобы DNS-имя "example.com" указывало на сервер (ы) Exchange, и тогда ваш URL-адрес автообнаружения будет https://example.com/autodiscover/autodiscover.xml.
• DNS-имя "autodiscover.example.com" может указывать на сервер (ы) Exchange, и тогда ваш URL-адрес автообнаружения будет https://autodiscover.example.com/autodiscover/autodiscover.xml.

В обоих случаях имя должно разрешаться на ваш сервер (ы) Exchange как из вашей внутренней сети, так и извне (обычно через обратный прокси-сервер и / или брандмауэр); если у вас более одного сервера Exchange, балансировщик нагрузки должен быть расположен перед ними, и конфигурация должна быть соответственно изменена; также сертификат, используемый для веб-служб Exchange (будь то на сервере (ах) или на балансировщике нагрузки / обратном прокси-сервере), должен содержать в качестве SAN имя, которое вы используете для службы.

Похоже, что ваша внешняя публикация службы в порядке, иначе анализатор удаленных подключений не сможет работать; а как насчет вашей внутренней сети?

Вы используете одно и то же имя ("example.com") для своего домена SMTP и домена Active Directory? В этом случае полное доменное имя домена будет автоматически указывать на ваши контроллеры домена во внутренней DNS, поэтому оно не может указывать на ваши серверы Exchange.

Если вместо этого "example.com" является доменом, отличным от вашего домена AD, то используете ли вы split-DNS (т.е. есть ли у вас внутренняя DNS-зона с тем же именем)? И в этом случае вы указали полное доменное имя домена на серверы Exchange внутри вашей сети?

TL;DR: убедитесь, что "example.com" указывает на сервер (ы) Exchange как при разрешении во внутренней сети, так и при разрешении вне ее; если это невозможно, переключитесь на определенное имя ("autodiscover.example.com") вместо использования полного доменного имени домена; и в этом случае убедитесь, что сертификат, используемый веб-службами Exchange, содержит соответствующую SAN.

Я прочитал предыдущие ответы перед публикацией, поэтому мой не является перефразированием ни одного из них, так что попробуйте.

Этот ответ основан исключительно на вашем утверждении о том, что «анализатор подключений Microsoft сообщает, что все в порядке» верно.

Очень странно, что внешнее автообнаружение работает поверх внутреннего автообнаружения просто потому, что вам не нужно ничего делать для настройки внутреннего автообнаружения. Я могу только подозревать, что вы могли сломать это как-то случайно.

На самом деле существует два метода, которые автообнаружение может использовать для получения настроек почтового ящика. Существует метод DNS (описанный вами выше), который используют инструменты RCA. Этот метод используется, когда клиент Outlook НЕ является частью Active Directory (AD). Поскольку инструмент RCA не является частью вашего AD, он использует этот метод. Это подтверждает правильность настройки. Однако если вы пытаетесь настроить Outlook с компьютера, подключенного к AD, автообнаружение использует другой процесс. Он использует так называемую точку подключения службы. Этот SCP хранится в AD в определенном месте. Проще говоря, внутренняя машина, подключенная к AD, будет искать эту запись SCP и использовать все, что там настроено, ВМЕСТО метода DNS, который вы используете выше.

Допустим, ваше автообнаружение работает на autodiscover.example.com, и вы успешно протестировали его с помощью RCA. Но предположим, что запись SCP настроена неправильно как autodiscover.yourADdomain.local. Это означает, что Outlook внутри себя будет считать, что автообнаружение находится в этом месте. Пожалуйста, проверьте свою запись SCP и (если вам удобно) сообщите нам, что там написано. Если нет, просто дайте нам знать, если это отличается от того, что вы ожидаете. Чтобы узнать местоположение SCP, прочитайте это https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/how-to-find-autodiscover-endpoints-by-using-scp . -lookup-in-exchange#locate-autodiscover-scp-objects-in-ad-ds

Опять же, если ваше утверждение о внешнем автообнаружении верно, то я могу со 100% уверенностью сказать вам, что проблема связана с этой записью SCP. Если ваша запись SCP имеет тот же URL-адрес, что и метод DNS (это должен быть полный путь https://xxx.example.com/autodiscover/autodiscover.xml из памяти), это означает, что ваш внутренний DNS не имеет записей DNS. для xxx.example.com, которые указывают на серверы Exchange.

Работает ли Outlook после ввода имени сервера (обычно это GUID Exchange для почтового ящика пользователя) и учетных данных почтового ящика? Работает ли внутренний клиент Outlook с автообнаружением?

Я полагаю, автообнаружение работает (получить ошибку 600, когда URL-адрес автообнаружения браузера) и имеет действительный сертификат для автообнаружения.

Как известно, MAPI over HTTP будет включен по умолчанию в Exchange 2016. Таким образом, запустите "Get-MapiVirtualDirectory", чтобы просмотреть URL-адрес и параметры аутентификации для него. Кроме того, проверьте настройки поставщика Outlook, Outlook Anywhere, как указано выше Finny. Убедитесь, что эти полные доменные имена действительны по разрешению DNS.

Вы настраиваете клиентов внешне или внутренне (и оба терпят неудачу)? Можете ли вы почистить и опубликовать вывод:

Get-OutlookProvider 
Get-OutlookAnywhere
Get-ClientAccessServer

Большую часть времени я вижу проблемы с этими ценностями.

AutodiscoverServiceInternalUri. InternalHostName & ExternalHostName.

Требует SSL? Метод аутентификации? Предположим, у вас установлен сертификат, созданный центром сертификации, и клиенты доверяют ему (в некоторых центрах сертификации также требуется промежуточный сертификат).