Продолжение выяснения почему у меня вдруг перестали получать настройки почты клиенты с Microsoft Office 2016 от моего почтового сервера Exchange 2010 + Rollup 32. См. заметку: "Outlook 2026 не получает настройки через Autodiscover"
Я долго не мог понять, что случилось вдруг на тот момент как я думал ни с того ни с сего.
На заметку: настройки Autodiscover есть на Exchange 2010 в них ничего не вносилось.
На заметку: Видел на различных заметках, что нужно в DNS на домен контроллере создать SRV-запись:
on srv-dc01
запускаю оснастку DNS: srv-dc01 - Forward Lookup Zones — через правый клик на polygon.local выбираю "Other New Records…"
Select a resource record type: выбираю "Service Location (SRV)"
и нажимаю "Create Record…"
Domain: polygon.localService: _autodiscoverProtocol: _tcpPriority: 0Weight: 0Port number: 443Host offering this service: srv-mail01-cas.polygon.local
и нажимаю "OK", "Done".
C:\Windows\system32>nslookup -q=srv _autodiscover._tcp.polygon.local.
Server: srv-dc01.polygon.local
Address: 10.90.90.3
_autodiscover._tcp.polygon.local SRV service location:
priority = 0
weight = 5
port = 443
svr hostname = srv-mail01-cas.polygon.local
srv-mail01-cas.polygon.local internet address = 10.90.90.5
На заметку: в команде выше с Nslookup не забываем поставить точку после local
Это на моем почтовом сервере Exchange 2010 нет надобности делать.
Шаг №1: Сперва я нашел описание алгоритма, как клиент Outlook ищет настройки:
Алгоритм поиска сервиса Autodiscover клиентом Outlook
Начнем с того, что с Autdiscover’ом могут работать клиенты, начиная с Outlook 2007 и более новые. Логика поиска службы следующая:
1. Service Connection Point (SCP) lookup — Outlook пытается найти точку подключения к Autodiscover в Active Directory (для своего АД сайта). Если данная попытка не удачна, то он переходит к «не доменной» логике:
2. HTTPS запрос к SMTP домену — Outlook формирует адрес для подключения из доменной части SMTP адреса пользователя, например, https://srv-mail01-cas.polygon.local/autodiscover/autodiscover.xml
3. HTTPS запрос к домену Autodiscover — Outlook формирует URL добавляя имя autodiscover к SMTP домену, например: https://autodiscover.polygon.local/autodiscover/autodiscover.xml
4. Выполняется поиск локального XML файла с конфигурацией
5. Используется метод HTTP redirect
6. Выполняется поиск по SRV записи
7. Outlook 2013 может использовать закэшированный ранее в профиле URL
Шаг №2: Начал смотреть логи взаимодействия на srv-mail01-cas (Exchange 2010 + Roolup 32):
C:\inetpub\logs\LogFiles\W3SVC1\u_ex250930.log
и вот тут увидел что часть обращений идет от почтового сервера к узлу 10.90.90.6
2025-09-30 07:34:15 10.90.90.5 GET /owa/ - 443 - 10.90.90.6 HttpProxy.ClientAccessServer2010Ping 401 2 5 0
2025-09-30 07:34:37 10.90.90.5 RPC_IN_DATA /rpc/rpcproxy.dll - 443 - 10.90.90.6 HttpProxy.ClientAccessServer2010Ping 401 2 5 0
2025-09-30 07:31:36 10.90.90.5 HEAD /ecp/ - 443 - 10.90.90.6 HttpProxy.ClientAccessServer2010Ping 404 4 2 0
2025-09-30 07:31:44 10.90.90.5 HEAD /OAB - 443 - 10.90.90.6 HttpProxy.ClientAccessServer2010Ping 401 2 5 0
2025-09-30 04:42:31 10.90.90.5 HEAD /OAB - 443 - 10.90.90.6 HttpProxy.ClientAccessServer2010Ping 401 2 5 1
2025-09-30 04:42:34 10.90.90.5 HEAD /EWS - 443 - 10.90.90.6 HttpProxy.ClientAccessServer2010Ping 401 0 0 1
На заметку:
10.90.90.5 - srv-mail01-cas.polygon.local
Тут не сказать сразу, что у меня в голове щелкнулу в чем причина, пришлось проанализировать настройки через Exchange Management Shell в лице PowerShell команд, тут все кстати норм было.
Но потом придя домой, вспомнил что адрес 10.90.90.6 — это новый почтовый сервер srv-mail02 на котором у меня развернут Exchange 2016, но вот переход до конца не сделан. Все процессе, возникли трудности которые прорабатываю на тестовом среде.
Шаг №3: И из такой связки вытекает следующая работа Autodiscover:
Почтовый ящик лежит на Exchange 2010
А Exchange 2016 еще не до конца настроен и поэтому запрос приходящий на srv-mail01-cas проксируется на srv-mail02, а он еще не в полной мере работает.
URL on srv-mail02: https://srv-mail02.polygon.local/autodiscover/autodiscover.xmlURL on srv-mail01-cas: https://srv-mail01-cas.polygon.local/autodiscover/autodiscover.xml
В алгоритме поиска настройке клиентом Outlook ищется точка подключения Service Connection Point (SCP) lookup. Этот параметр создается для каждого CAS сервера в организации. Он прописывается в Active Directory.
on srv-dc01
Win + X - Control Panel - View by: Small icons - Administrative Tools - ADSI Edit
Name: ConfigurationPath: LDAP://srv-dc01.polygon.local/ConfigurationConnect Point: выбрано "Select a well known Naming Context: Configuration"Computer: выбрано "Default (Domain or server that you logged in to)"
и нажимаю "ОК".
разворачиваю "Configuration [srv-dc01.polygon.local] - "CN=Configuration,DC=polygon,DC=local" - "CN=Services" - "CN=Microsoft Exchange" - "CN=Amigo" - "CN=Administrative Groups" - "CN=Exchange Availability Group" - "CN=Servers" - "CN=SRV-MAIL01-CAS" - "CN=Protocols" - "CN=Autodiscover" - "CN=SRV-MAIL01-CAS"
и по аналогии в "CN=Servers" уже есть и для srv-mail02
ну так вот
у меня получается клиент обращается на SCP своего сайта, т.е. сперва на srv-mail01-cas, а уже его после редиректер на srv-mail02, т.е. чтобы клиенту найти SCP он делает запрос в AD ему прилетает ответ какие записи есть, клиент обрабатывает их на основе полей:
keywords - сайт, к которому принадлежит эта точка подключения (AutoDiscoverSiteScope)serviceBindingInformation - URL службыWhenCreated - дата создания объекта
далее идет сортировка записей по дате создания
после идет попытка подключения к самому старому (определяет по ключу WhenCreated) почтовому серверу. Если именно этот почтовый сервер не доступен, то к следующему и так пока список в "CN=Servers" не закончится.
Шаг №4: В моем случае решение следующее:
Я открыл свойства CN=SRV-MAIL02 и изменил свойство параметра serviceBindingInformation с https://srv-mail02.polygon.local/autodiscover/autodiscover.xml на https://srv-mail01-cas.polygon.local/autodiscover/autodiscover.xml и проверив что клиент (в лице Microsoft Outlook) без ручного указания autodiscover.xml самостоятельно находит настройки почтового ящика — все успешно.
К тому же при обращении любый клиентом в домене через браузер IE на URL: https://srv-mail01-cas.polygon.local/autodiscover/autodiscover.xml сразу же открывается окно авторизации и после авторизации возвращается ответ вида:
<?xml version="1.0" encoding="UTF-8"?>
-<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
-<Response>
-<Error Id="373488966" Time="11:15:37.6190762">
<ErrorCode>600</ErrorCode>
<Message>Invalid Request</Message>
<DebugData/>
</Error>
</Response>
</Autodiscover>
что собственно нормально.
Уже после того как поменял путь до autodiscover.xml, вспомнил что эту настройку можно было сделать и через комадну Get-ClientAccessServer, сейчас настройки:
[PS] C:\Windows\system32>Get-ClientAccessServer -Identity "SRV-MAIL01-CAS" | fl AutoDiscoverServiceInternalUri
AutoDiscoverServiceInternalUri : https://srv-mail01-cas.polygon.local/Autodiscover/Autodiscover.xml
[PS] C:\Windows\system32>Get-ClientAccessServer -Identity "SRV-MAIL02" | fl AutoDiscoverServiceInternalUri
AutoDiscoverServiceInternalUri : https://srv-mail01-cas.polygon.local/autodiscover/autodiscover.xml
На заметку: Содержимое autodiscover.xml в Exchange 2010
<%@ServiceHost Service="Microsoft.Exchange.Autodiscover.WCF.LegacyAutodiscoverService" %>
Это сейчас все просто, но когда я столкнулся с возможностью подключения клиента, а это было у главного бухгалтера, то это было фиаско, ладно там у обычного пользователя они как правило понимаю если есть какие-либо проблемы, а руководители обычно нет. Но мне достается общение с руководителями и правильному объяснению почему в данный момент что-то нельзя сделать и нужно разобрать и поправить.
Вот так на пустом месте я создал себе проблему, но проблема всплыла когда гл. бухгалтеру менялось и перенастраивалось рабочее место.
Заметка завершена, я узнал еще чуть более чем до нее, на этом пока все, с уважением автор блога Олло Александр aka ekzorchik.