Настройка autodiscover dns exchange

Обновлено: 16.07.2024

Механизм Autodiscover достаточно прост и призван обеспечивать беспрепятственное получение настроек автоконфигурации клиентами Exchange Server . Тем не менее, встречаются некоторые моменты, которые вводят в заблуждение системных администраторов.

В этой статье я сделаю акцент на наиболее частых вопросах и проблемах, которые мне встретились на форумах Technet.

Виртуальный каталог Autodiscover

Примечание: помните, что логин AD (UPN) должен совпадать с основным адресом электронной почты. В противном случае пару логин/пароль возможно придется указывать отдельно, а также вписывать сервер для подключения.

Клиент обращается к серверу, чтобы получить следующие данные 1 :

Тем не менее, вопросы чаще всего возникают в том, каким образом клиент понимает к какому серверу подключаться 2 . Множество настроек, часть из которых тянутся с предыдущих версий Exchange, не способствуют лучшему пониманию.

Виртуальный каталог Autodiscover по умолчанию имеет название Autodiscover ‎(Default Web Site). Через EAC нам доступен минимум параметров, которые для него можно поменять. Во многих случаях это и не требуется. Однако есть мнение, что для него нужно устанавливать InternalUrl и ExternalUrl, но на самом деле это не так. Ниже разберемся почему.

Клиент НЕ присоединен к домену

В качестве клиента будет рассматриваться всем знакомый Outlook. Допустим вы уже ввели свой email-адрес и пароль. На основе домена, взятого из почтового адреса, клиент генерирует список возможных точек подключения.

Примечание: для усложнений сценария предположим, что клиент запускается впервые и он ничего не знал о вашем ящике до этого момента. Следовательно, он не мог иметь у себя закэшированных настроек.

Если ни одна из них не ответит, клиент сделает последние попытки использовать другие методы:

Поскольку допустимые варианты URL жестко зашиты в логику работы клиента, мы приходим к одному важному выводу. А именно: URL-адреса, которые вы вписываете в параметры InternalUrl и ExternalUrl виртуального каталога автообнаружения не нужны, потому что не используются. Видимо именно поэтому их убрали из доступных настроек в ECP:

Виртуальный каталог Autodiscover 02

В то время как у других виртуальных каталогов они доступны для изменения. На устаревший функционал этих настроек Autodiscover также прямо намекает справочная страница командлета Set-AutodiscoverVirtualDirectory 4 :

This parameter is available or functional only in Exchange Server 2010.

С вашей стороны нужно позаботиться о том, чтобы как минимум на одной точке подключения клиент мог получить данные автоконфигурации. Также рекомендуемым сценарием является настройка Split DNS (подробнее читайте в статье Exchange Server и Split DNS), чтобы клиенты внутри и снаружи сети подключались по одним и тем же именам.

Для клиентов, которые не введены в домен, порядок подключения одинаков как при нахождении в локальной сети предприятия, так и снаружи. Для доменных клиентов ситуация обстоит намного интереснее.

Служба автообнаружения минимизирует действия по настройке и развертыванию пользователей, предоставляя клиентам доступ к функциям Exchange. Для клиентов веб-служб Exchange (EWS) автообнаружение обычно используется, чтобы найти URL-адрес конечной точки EWS. Однако служба автообнаружения также может предоставлять сведения для настройки клиентов, использующих другие протоколы. Автообнаружение работает как с защищенными, так и не защищенными брандмауэром клиентскими приложениями, подходит для сценариев с лесом ресурсов и несколькими лесами.

Exchange 2016 г. были внесены изменения в службы, которые ранее обрабатывались несколькими серверами. Теперь сервер почтовых ящиков предоставляет службы клиентского доступа, поэтому вы не сможете настроить отдельный сервер клиентского доступа, как в предыдущих версиях Exchange. Служба автооткрытия Exchange 2016 и Exchange 2019 г., поскольку:

Exchange создает виртуальный каталог, названный под веб-сайтом по умолчанию autodiscover в службы IIS (IIS).

Active Directory сохраняет и предоставляет авторитетные URL-адреса для компьютеров с доменом.

Службы клиентского доступа на серверах почтовых ящиков предоставляют проверку подлинности и прокси-службы для внутренних и внешних клиентских подключений.

Outlook настраивает службы только с иным и паролем.

Справочные сведения для пользователей, касающиеся подключения клиента Outlook к серверу Exchange Server, см. в статье о настройке электронной почты Outlook.

Службы автообнаружения и Active Directory

Exchange в Active Directory сохраняет конфигурацию Exchange серверов в организации, а также сведения о почтовых ящиках пользователей. Перед установкой Exchange Server необходимо подготовить лес Active Directory и его домены. Если вы не знакомы с Exchange или доменами, см. в шаге 3. Подготовкадоменов Active Directory.

Exchange автоматически создает при установке виртуальный каталог в IIS, веб-сайте frontend client Access services, к который подключаются autodiscover клиенты. Это позволяет Outlook обнаруживать параметры почтовых ящиков Exchange, чтобы пользователям не приходилось вручную настраивать дополнительные параметры.

Функциональный процесс автооткрытия.

Одновременно с виртуальным каталогом службы автообнаружения в Active Directory создается объект точки подключения службы (SCP). Он хранит и предоставляет заслуживающие доверия URL-адреса службы автообнаружения для компьютеров, присоединенных к домену.

Вам нужно обновить объект SCP, чтобы он указывал на сервер Exchange. Это требуется потому, что серверы Exchange предоставляют клиентам дополнительные сведения автообнаружения для улучшения процесса обнаружения. Дополнительные сведения см. в статье Set-ClientAccessService.

Для запуска командлета Set-ClientAccessService требуются специальные разрешения. Сведения о необходимых разрешениях для запуска командлетов и использования параметров в организации см. в статье Find the permissions required to run any Exchange cmdlet.

Автообнаружение упрощает получение информации, необходимой для подключения к почтовым ящикам на серверах Exchange Server. Объекты SCP находят подходящие серверы или конечные точки автообнаружения для пользователей, для которых вы получаете параметры. Объекты SCP в AD DS упрощают поиск серверов автообнаружения для присоединенных к домену клиентов.

Exchange публикует два типа объектов SCP для службы автообнаружения:

Указатели SCP. Содержит сведения, указыватели на определенные серверы LDAP, которые должны использоваться для обнаружения объектов SCP автооткрытки для домена пользователя. GUID указателей SCP: 67661d7F-8FC4-4fa7-BFAC-E1D7794C1F68.

URL-адреса SCP. Содержит URL-адреса для конечных точек автооткрытия. URL-адреса SCP штампуются с помощью следующего GUID: 77378F46-2C66-4aa9-A6A6-3E7A48B19596

Объект SCP содержит заслуживающий доверия список URL-адресов службы автообнаружения для леса. Дополнительные сведения о поиске конечных точек службы автообнаружения см. в статье Как создать список конечных точек службы автообнаружения.

В зависимости от настройки службы автооткрытия на отдельном сайте URL-адрес службы автооткрытия будет одним из следующих значений, где находится основной //<SMTP-address-domain> домен SMTP:

Конечная точка Создана на основе
https://longview.contoso.com/autodiscover/autodiscover.xml Результаты SCP
https://email.contoso.com/autodiscover/autodiscover.xml Результаты SCP
https://newark.contoso.com/autodiscover/autodiscover.xml Результаты SCP
https://contoso.com/autodiscover/autodiscover.exc Электронный адрес
https://autodiscover.contoso.com/autodiscover/autodiscover Электронный адрес

Дополнительные сведения о объектах SCP см. в публикации с точками подключения к службе.

Автообнаружение в DNS

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

Основное пространство имен IP центра обработки данных.

Дополнительное пространство имен IP центра обработки данных.

Основное Outlook Web App пространство имен с отбойным сбойом

Дополнительное Outlook Web App пространство имен с отбойным сбойом

Пространство имен транспорта (для SMTP)

Основное пространство имен для клиентского доступа через RPC, которое нужно центру обработки данных.

Дополнительное пространство имен для клиентского доступа через RPC, которое нужно центру обработки данных.

Улучшены сценарии устойчивости серверов, что сокращает пять пространств имен до двух. Причина состоит в том, что Exchange больше не нужны пространства имен для клиентского доступа через RPC, а службы клиентского доступа перенаправляют запросы на сервер почтовых ящиков, на котором размещается активная база данных почтовых ящиков. Сервер почтовых ящиков на одном сайте Active Directory может перенаправлять сеанс на сервер почтовых ящиков другого сайта Active Directory.

Типичная запись CNAME выглядит указанным ниже образом.

Срок жизни: 3600 с.

Тип записи ресурса: CNAME.

Рекомендуем создать записи CNAME автообнаружения для всех доменов учетной записи, в том числе псевдонимов доменов и обслуживаемых доменов. Запись SRV или CNAME необходимо создать там, где размещается ваш домен. Только после этого вы можете синхронизировать свою офлайн-адресную книгу, показать сведения о свободном или загруженном доступе и включить функцию Out of office в Outlook.

Записи SRV позволяют указать расположение серверов для определенной службы, протокола и домена DNS. Например, если в вашем домене два веб-сервера, вы можете создать записи SRV, указывающие, какие узлы выполняют функции веб-серверов. Сопоставители затем могут извлечь все записи SRV для веб-серверов.

Типичная запись SRV выглядит указанным ниже образом.

Номер порта: 443.

Дополнительные данные о записях CNAME и SRV в блоге Exchange, планирование пространства имен в Exchange 2016 г..

Службы автообнаружения в Outlook

Клиент Outlook может выполнять аутентификацию в Active Directory и искать объекты SCP автообнаружения, используя только учетные данные пользователя. После получения и перечисления экземпляров службы автообнаружения клиент подключается к службам клиентского доступа (интерфейсным) на первом сервере почтовых ящиков в перечисленном списке. Затем клиент собирает данные профиля в формате XML, необходимые для подключения к почтовому ящику пользователя и доступным компонентам Exchange.

Для доменного имени нужно настроить специальную запись DNS, которая указывает на сервер, предоставляющий службы автообнаружения, чтобы учетные записи Exchange корректно работали в Outlook. В случае внешнего доступа или при использовании DNS клиент находит службу автообнаружения в Интернете по основному адресу домена SMTP, входящему в электронный адрес пользователя.

Служба автообнаружения использует один из этих четырех методов для настройки почтового клиента. Первые два подходят для небольших организаций с одним пространством имен SMTP. Последние два предназначены для организаций с несколькими пространствами имен SMTP.

Поиск записи SRV DNS.

Одни имена узлов и URL-адреса можно настроить с помощью Центра администрирования Exchange (EAC) и командной консоли Exchange, а другие необходимо настраивать в PowerShell. Дополнительные сведения см. в статье Настройка потока обработки почты и клиентского доступа.

С помощью службы автообнаружения Outlook находит новую точку подключения на базе почтового ящика пользователя. То есть идентификатор автообнаружения состоит из GUID, символа @ и доменного имени из основного SMTP-адреса пользователя. Служба автообнаружения возвращает клиенту следующую информацию:

отображаемое имя пользователя;

индивидуальные параметры каждого внутреннего или внешнего подключения;

сведения о расположении почтового ящика пользователя (сервере почтовых ящиков, который содержит активную копию почтового ящика);

параметры сервера Мобильный Outlook.

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

Когда информация пользователя в Exchange изменяется, Outlook автоматически обновляет профиль пользователя с помощью службы автообнаружения. Например, если почтовый ящик пользователя перемещен или клиент не может подключиться к почтовому ящику пользователя или доступным компонентам Exchange, Outlook связывается со службой автообнаружения и автоматически добавляет в профиль пользователя сведения, необходимые для подключения к почтовому ящику и компонентам Exchange.

Другие клиенты

Выбирайте службу автообнаружения для поиска всех служб в Skype для бизнеса Server 2015. При успешном подключении она возвращает URL-адреса всех веб-служб в домашнем пуле пользователя, в том числе службы Mobility Service, или Mcx (так называется виртуальный каталог, создаваемый для службы в IIS), Lync Web App и веб-планировщика. Однако и внутренний, и внешний URL-адреса службы Mobility Service связаны с внешним полным доменным именем веб-служб. Поэтому мобильное устройство всегда подключается к службе Mobility Service извне, используя обратный прокси-сервер, независимо от того, является ли оно внешним по отношению к сети. Служба автообнаружения также возвращает ссылки на Internal/UCWA, External/UCWA и UCWA. UCWA — это веб-компонент Unified Communications Web API.

Настройка служб автообнаружения

Автообнаружение работает как с защищенными, так и не защищенными брандмауэром клиентскими приложениями, подходит для сценариев с лесом ресурсов и несколькими лесами. В случае клиентов EWS служба автообнаружения обычно используется для поиска URL-адреса конечной точки EWS, но она также может предоставлять информацию для настройки клиентов, использующих другие протоколы.

При установке Exchange Server на сервере автоматически устанавливается самозаверяется сертификат, созданный и подписанный Exchange сервером. Однако вы также можете создать дополнительные самозаверяющие сертификаты для других служб.

Создание запроса на сертификат является первым шагом в установке нового сертификата на сервере Exchange, чтобы настроить шифрование безопасности транспортного слоя (TLS) для одной или нескольких Exchange служб. Такой запрос позволяет получить сертификат из центра сертификации (ЦС). Дополнительную информацию см. в следующих статьях:

Вы можете проверить службу автообнаружения с помощью средства Microsoft Remote Connectivity Analyzer. Протестировав подключение, также выберите параметр "Outlook Connectivity" (Подключение Outlook), чтобы выполнить соответствующую проверку. Если она не будет пройдена, возможно, вам потребуется настроить внешние URL-адреса в Exchange. Из результатов Microsoft Remote Connectivity Analyzer должно быть понятно, почему не удалось установить подключение. Как правило, ошибка подключения означает, что для виртуальных каталогов служб Outlook не настроены правильные внешние URL-адреса.

Управление службами автообнаружения

Вы можете выполнить Exchange ActiveSync и Outlook в анализаторе удаленного подключения Майкрософт. Если пользователь использует локализованную беспроводную сеть для подключения к Exchange, он должен выполнить оба теста, чтобы убедиться, что локализованная сеть позволяет подключаться к конечным точкам ActiveSync.

Вы можете получить помощь по планированию и развертыванию служб автооткрытия в рамках развертывания Exchange планирования и развертывания для Exchange Server.

Вы попали на блог, целиком и полностью посвященный продуктам компании Microsoft. В основном речь будет идти про системы корпоративных коммуникаций на базе Exchange Server.

вторник, 31 мая 2011 г.

Служба AutoDiscover появилась в релизе сервера Microsoft Exchange 2007 и на неё была возложена задача автоматического конфигурирования клиентских приложений. Вместе с тем, перед администраторами встала задача предоставления клиентам доступа к данной службе. Именно об этом далее и пойдет речь.

Внимание! Рассматривать вариант с сертификатом, выданным локально, т.е. доменной службой сертификации мы не будем!

1. Клиент находится внутри сети и включен в домен;

2. Клиент не доменный.

Примечание: XML-файл публикуется на виртуальном каталоге IIS на сервере клиентского доступа (CAS). Физически данный XML-файл находится в каталоге установки, обычно C:\Program Files\Microsoft\Exchange Server\V14'\Client Access\Autodiscover\

Autodiscover для внутренних доменных клиентов

Клиенты, которые подключены к домену, и которые могут успешно выполнять запросы к базе данных Active Directory, получают информацию об автоматической настройке следующим образом:

1. Клиенты MS Outlook 2007 и старше отправляют LDAP запрос к базе данных Active Directory в поиске всех доступных объектов SCP (Service Connection Point). Фактически, клиентам нужно прочитать два атрибута:

Примечание: Объекты SCP создаются автоматически в базе AD для всех серверов Exchange с установленной ролью Client Access (CAS) (см.рис.1).

clip_image002

Рис.1: Атрибуты SCP, считываемые доменными клиентами при запросе.

3. Клиент пытается скачать XML-файл с настройками, по очереди открывая все URL`ы, полученные из SCP;

4. В случае неудачи, клиент активирует другой алгоритм поиска службы Autodiscover.

Autodiscover для внешних клиентов

Если обратиться к службе Active Directory не удалось, то поиск службы AutoDiscover продолжается, пока не будет получен первый ответ. Алгоритм следующий:

1. Клиент пытается разрешить в DNS стандартные URL`ы службы AutoDiscover:

где <smtp-domain> - это все то, что после @

Вот таким вот не хитрым образом клиенты Outlook 2007/2010 пытаются автосконфигурироваться для работы с сервером Exchange. Уяснив эти моменты можно подумать на тему того, как обойтись без лишнего имени в сертификате для службы AutoDiscover.

Варианты публикации Autodiscover`a

Резюмируем варианты публикации службы Autodiscover с точки зрения использования сертификатов. Итак, сервер можно опубликовать:

1. Используя один сертификат с несколькими именами хостов (с полем SAN):

Это рекомендуемый вариант с точки зрения Microsoft Best Practice, но он требует поддержки поля SAN со стороны клиентского приложения.

2. Используя один сертификат без поля SAN:

Здесь мы воспользуемся возможностью поиска службы AutoDiscover через SRV-запись.

Очень удачный и недорогой вариант, в том случае, когда есть возможность использовать SRV-записи. Требует обновления MS Outlook 2007 и внесения изменений в SCP.

3. Используя два разных сертификата без поля SAN:

Применяется, если какие-то из клиентов не могут читать поле SAN. По цене получается почти аналогично первому. Требует наличия дополнительного внешнего IP адреса.

Аналогично 3-му пункту требуется дополнительный внешний IP адрес.

Заключение

На этом моменте немного прервемся и в следующей части продолжим разговор уже непосредственно о том, как озвученные выше варианты воплотить в жизнь.

Установка CAS роли не отличается чем-то особенным от установки Mailbox. Вся соль в последующей настройке. В планах - установка 2 серверов CAS с первоначальной балансировкой по DNS RoundRobin с последующим переключением на Citrix NetScaler.

Для начала, на настроенные сервера установим необходимые Prerequisites (забыл, как по-русски ):


CAS1.jpg

Непосредственная установка (нужно смонтировать установочный образ):

Setup.exe / mode:install / role:ClientAccess / IAcceptExchangeServerLicenseTerms

CAS2.jpg

Данные действия необходимо повторить на втором сервере.

Запрос сертификата будем осуществлять с помощью командной строки:

Set-Content -path "\\mbx01\c$ \T emp\Certs\Exchange_Request.req" -Value $Data

CAS3.jpg

Открываем файл запроса в блокноте, проходим на страничку центра сертификации и выписываем сертификат шаблона Web Server:

При выполнении назначения сертификата, возникла ошибка, о том, что сертификат не может быть принят для сервисов, так как он неверного формата. Так как запрос сертификата делался с сервера MBX, то в веб консоли я закрыл запрос сертификатом. Данный сертификат нужно экспортировать в pfx и провести импорт на все CAS сервера.

CAS4.jpg

Экспорт:

CAS5.jpg

В окне экспорта нужно указать UNC путь к файлу и пароль. Указать локальный путь на сервере нельзя.

CAS6.jpg

Импорт:

CAS7.jpg

Окно импорта и пароля:

CAS8.jpg

В окне сертификатов выбрать сервера, на которые необходимо импортировать сертификат:

CAS10.jpg

Окно импорта:

CAS11.jpg

Данные сертификата можно просмотреть, кликнув дважды на сертификат.

CAS12.jpg

В окне данных о сертификате, также, есть в наличии 2 вкладки с данными и сервисами, которые настроены на использование данного сертификата. Устанавливаем галочки напротив необходимых сервисов: SMTP и IIS:

CAS13.jpg

Сохраняем, на что система предупреждает, что сервисы уже привязаны к другому сертификату:

CAS14.jpg

Данное действие необходимо повторить на обеих CAS серверах. Результат - сервисы привязаны:

Настройка:

CAS9.jpg

Перейти на вкладку Servers:

CAS15.jpg

Нажать на ключик "Configure external access domain". Добавить оба сервера CAS и вписать внешнее имя:

CAS16.jpg

Сохраняем конфигурацию.

. и. ошибка! Что-то типа "Error: The version of Internet Information Services (IIS) that is running on server 'CAS01.nsvpx.com' can't be determined". Странно. начал читать.. на форуме пишут, что необходимо открыть порты 137-139 и 445.

CAS18.jpg

Включить правило разрешения 445 порта:

CAS19.jpg

Создать правило разрешения 137-139 портов:

CAS20.jpg

Пробуем снова:

Готово!
Я не могу сказать, что помогли оба варианта или какой-то из них, но в сумме - сработало. Думаю, сначала необходимо создать записи DNS и в случае ошибки - колдовать с фаерволом.

CAS21.jpg

Настраиваем виртуальные директории:

CAS22.jpg

Все директории, кроме AutoDiscover, настраиваются на использование URL внутри и снаружи организации.
Меняем внутренние URL для ECP:

CAS23.jpg

EWS:

CAS24.jpg

ActiveSync:

CAS25.jpg

Offline Address Book:

CAS26.jpg

OWA:

CAS27.jpg

PowerShell:

CAS34.jpg

Настройка AutoDiscover:
Для начала, создадим необходимые DNS записи (пока, всё тот же RoundRobin):

CAS28.jpg

Настроить AutoDiscover из веб морды нельзя:


CAS29.jpg


CAS30.jpg


CAS31.jpg

Установим необходимые нам значения:


CAS32.jpg

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

Для проверки работы сервиса, необходимо:

У меня все тесты успешно пройдены.

Для построения тестовой и написания данной статьи, использовался материал Installing Exchange Server 2013 Part II

Читайте также: