Главная Exchange/UC, Новое Медленная работа автообнаружения Exchange Server
  • Медленная работа автообнаружения Exchange Server

    Нmicrosoft-outlook-logo-185x185едавно наткнулся на статью в которой говорилось о причине медленной работы службы Autodiscover в Exchange Server, прочитал и понял, что данный вопрос у моих студентов иногда всплывает, а поэтому стоит сделать мини пост с произвольным переводом. Все очень просто, начиная с Outlook 2007 клиентское приложение использует веб-сервис Autodiscover для автоматического конфигурирования настроек доступа клиента к Exchange. Для внутренних процедура совсем простая, запустите Outlook и нажимайте «далее», пока не получите доступ к ящик. Внешним клиентам придется вводить адрес электронной почты, пароль и возможно UPN, если он не совпадает с email. Так вот при подключении из вне клиент может столкнуться с ситуацией, когда процедура настройки затянется на несколько минут.
    Autod

    Это связано с тем, что клиент ищет файл с настройками (Autodiscover.xml)  несколькими способами, которые предопределены в продукте и неизменны.

    Процесс на примере домена contoso.com:

    1. HTTPS запрос к корню домена (https://contoso.com/Autodiscover/Autodiscover.xml)
    2. HTTPS запрос к записи Autodiscover (https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml)
    3. Локальный XML файл
    4. HTTP перенаправление (http://autodiscover.contoso.com/Autodiscover/Autodiscover.xml, ожидая перенасправление HTTPS URL)
    5. Через SRV DNS запись (поиск SRV записи _autodiscover._tcp.contoso.com)
    6. Кэшированный URL in Outlook профиле (если предыдущий процесс Autodiscover  был успешен)

    В реальной жизни все добавляют запись autodiscover.contoso.com и думают, что все будет хорошо, но иногда ожидания не оправдываются. Никто не делает доступным Autodiscover.xml по ссылке с корнем домена, хотя именно этот вариант и является приоритетным. Почему мертвый вариант клиент проверяет первым не известно, но это именно так.

    Проблема с долгим ожидание возникает, когда имя contoso.com ведет на какой то IP, который не отвечает по 443 порту, либо просто недоступен. Процедура автообнаружения Outlook замирает и ждет когда придет ответ, в конечном итоге она отваливается по таймауту и берет следующий способ. Таймаут длится несколько минут и совсем не добавляет удобства работы.

    Эта проблема уходит, если имя contoso.com будет вести на сайт или любой веб-сервер, где доступен 443 порт, в таком случае за несколько секунд Outlook выяснит, что первый вариант не подходит и пойдет дальше настроившись через запись autodiscover.

    @

    Если вы столкнулись с такой проблемой, просто создайте во внешней зоне в корне запись @, которая будет разрешаться в IP вашего сайта. Ну или в случае DNS на Windows Server нужно будет создать пустую запись в корне.

    dns

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

    MCT/MVP Илья Рудь

    Онлайн курс: Планирование и установка Exchange Server 2016

    Онлайн курс: Планирование и установка Skype for Business Server 2015

    Очные курсы в УЦ «Специалист»

    • Рубрика: Exchange/UC,Новое
    • Автор: Илья Рудь
    • Дата: Понедельник 07 Мар 2016

Комментарии

  1. Одним из решений для минимизации количества имен в SSL-сертификатах является использование записи SRV для службы автообнаружения. Во всех документациях и материалах по новому Exchange говорят о двух именах. В реальности можно обойтись одним. Ну, грубо говоря, вместо mail.contoso.com и autodiscover.contoso.com используется только mail.contoso.com и SRV-запись _autodiscover._tcp.contoso.com 443 mail.contoso.com. Хороший вариант для экономных 🙂 Но вот стоит по твоей статье посчитать количество таймаутов... И решение уже не кажется таким «хорошим» 🙂

  2. Ты знаешь во времени когда сертификаты дают по 5 имен бесплатно, уже как то можно не экономить)

  3. Ещё чуток ТЗ. В Outlook 2016 на текущий момент выпилена ручная настройка профиля, только через службу автообнаружения. И если, например, клиент подключается через VPN, а службу автообнаружения через VPN не делали доступной, то клиент не сможет настроить профиль без танцев с бубнами.

  4. Странное описане решения, что оно работало надо не только создать корневую запись, но и поднять HTTPS на сайте — нужен сертификат и настройка веб-приложений.

  5. Нужно, чтобы кто то ответил «нет», иначе таймаут.

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

  7. Сертификат вообще не проблема itband.ru/2016/02/certificate-free/

  8. #В Outlook 2016 на текущий момент выпилена ручная настройка профиля, только через службу автообнаружения.# еще один повод, аутглюк 2016 не попадет в наш корпоративный стандарт 🙂

  9. еще один повод, аутглюк 2016 не попадет в наш корпоративный стандарт 🙂

    Вас Станислав дезинформировал. Ручная настройка протоколов Active Sync, POP и IMAP сохранилась. Убрали функционал по ручной настройке подключения к Exchange.

  10. @Вас Станислав дезинформировал. Ручная настройка протоколов Active Sync, POP и IMAP сохранилась.

    Ололо. Можно ещё The Bat использовать в качестве клиента — он клёвый 😀

    А если серьёзно, то последние два поциента через Autodiscover настройки не получают. Служба автообнаружения про них вообще не знает ничего. Первого же поциента использовать в толстом клиенте Outlook будут либо тонкие ценители, либо от безысходности, когда других протоколов для доступа не опубликовано, типа как в outlook.com. Но это же не наша история?

  11. >> Ололо. Можно ещё The Bat использовать в качестве клиента — он клёвый А если серьёзно, то последние два поциента через Autodiscover настройки не получают. Служба автообнаружения про них вообще не знает ничего.

    Станислав, но, все же, ручная настройка сохранилась для исключительных случаев ;).

    И чем Вам The Bat не угодил? Приличная программа 🙂

    А так, да, в вашем примере проще временно пересадить пользователей на OWA, а в это время либо попросить сетевых инженеров внести изменения в настройках VPN, либо сделать соответствующие настройки на DNS сервере филиала, чтобы пользователи выходили на почту через интернет. То есть создать соответствующую зону, запретить обновления, и прописать соответствующие записи (Если речь шла о филиале, конечно. На клиенте, на сколько я помню, можно убрать в свойствах VPN подключения галочку «Использовать основной шлюз в удаленной сети»).

  12. >> Ололо. Можно ещё The Bat использовать в качестве клиента — он клёвый

    Станислав, реальные проблемы могут возникнуть на удаленных объектах, которые выходят в интернет через спутник. Это и большие задержки, и потери пакетов... Вот где технические специалисты намучаются 🙁

  13. Владимир, я вам скажу по секрету, что если в рамках одной организации звонить через S4B из Екатеринбурга, например, в Мехико, то звук будет мягко говоря плохой. Физика.

    Продолжим соревнование «Кто придумает самые дурацкие условия для работы»?

  14. Продолжим соревнование «Кто придумает самые дурацкие условия для работы»?

    Похоже, Станислав, Вы тут один соревнуетесь. Вам подсказали случай, вполне реальный, когда может потребоваться ручная настройка профиля и при котором 2016 офис станет головной болью для специалиста техподдержки. Зачем Вы сделали перевод на S4B? Мы беседовали о почте.

    И второй момент. Что значит «дурацкие»? Это вполне приемлимые условия. Мы так работаем, например. На Север оптику не потянешь.

  15. А вариант с использованием локального xml-файла с настройками, вместо вытягивания файла через службу автообнаружения не работает для Outlook 2016?

    На подобии того, что описано для 2007 и 2010 в этой статье: blogs.technet.microsoft.c...ge-autodiscover

Опубликовать

Я не робот.