none
Часто виснет Outlook RRS feed

  • Вопрос

  • Добрый день.

    Недавно выполнял миграцию между серверами exchange 2013. Было 3 CAS, 2 MBX, стало 4 сервера с ролями CAS+MBX в DAG.

    После этого у пользователей периодически стал виснуть Outlook. Просто в любое время дня может перестать отвечать на 4-5 минут. В трее на иконке outlook висит сообщение "Приложение Outlook запрашивает данные с сервера". Если зайти в состояние подключения и нажать повторное подключение, то половина подключений сразу переходит в состояние "установлено", а половина в "отключается" и остается в нем на несколько минут. Когда все работает нормально, переподключение происходит почти мгновенно.

    Жалуются пользователи со всех серверов, размеры ящиков от 200МБ до 10ГБ. Проблемы и у тех, у кого включен режим кэширования и у тех, у кого он отключен. По ресурсам вроде все в порядке, все серверы на постоянном мониторинге и дефицита ресурсов не наблюдается. OWA при этом вроде открывается нормально.

    Уже голову сломал. Не знаю в чем может быть проблема.

    14 января 2019 г. 7:11

Ответы

Все ответы

  • Добрый день,

    как балансируете CAS серверы?

    Куда клиенты подключаются аутлуками?


    14 января 2019 г. 7:39
  • Все подключаются к общему имени mail.pharm.com, балансировка через DNS. Базы и юзеры примерно равномерно заделены между 4 новыми серверами.

    От старых остались 1 выключенный CAS и 2 выключенных MBX. На всех через ECP отключал receive connectors. MBX удалил из DAG. Но это вроде не должно влиять на подключения.


    14 января 2019 г. 7:53
  • Пока еще не пробовал отключать у проблемных клиентов IPv6 и подключение пока происходит через RPC, а не MAPI over HTTPS. Но до перехода на новые серверы пользователи подключались так же, но такой проблемы не было.
    14 января 2019 г. 7:58
  • В DNS не осталось записей от старых CAS серверов?

    mail.pharm.com смотрит только на IP адреса новых CASов?

    14 января 2019 г. 8:00
  • Да, все старые записи удалены.

    Если в состоянии подключения смотреть имена серверов, то они не меняются во время зависания и когда все работает корректно. Не знаю как можно сопоставить эти номера реальным именам серверов (это вроде и не GUID и не RunspaceId).

    14 января 2019 г. 8:14
  • Посмотрите ещё в сторону антивируса (антиспам).
    14 января 2019 г. 8:16
  • А у всех сразу виснет аутлук на 4-5 минут?


    14 января 2019 г. 8:22
  • Нет, у разных юзеров в разное время. С этим сталкивался лично я, мой начальник и еще несколько человек. Мы с начальником на одном сервере, в одной базе. Когда у него возникала такая проблема, у меня все было ок и наоборот. Подозреваю что проблемных пользователей намного больше т.к. проблема возникает каждый день по нескольку раз и хотелось бы её устранить до того момента, когда жалоб будет реально много.
    14 января 2019 г. 8:26
  • В данный момент антивирус установлен, но не запущен. 
    14 января 2019 г. 8:30
  • Как у вас настроена служба autodiscover?

    Используется ли общее имя для записи автообнаружения или по-умолчанию: записи по имени сервера?

    Дело в том, что доменные ПК внутри сети используют SCP для поиска сервера автообнаружения.

    И подключаются они к самой старой записи. А этот сервер отключен.

    Рекомендую к чтению:

    http://www.alexxhost.ru/2013/12/autodiscover-service-connection-point.html

    • Предложено в качестве ответа Evgeny Vovney 14 января 2019 г. 8:39
    14 января 2019 г. 8:34
  • Все настроены на общее имя и тот сервер. 

    Но разве такой поиск сервера работает не только когда подключение происходит первый раз? Я думал что после удачного подключения Outlook кэширует у себя сервер и затем все время подключается к нему, а если он недоступен, то ищет другой. Тем более нет смысла менять CAS сервер, если ящик пользователя находится на нём же.

    Если я захожу в проверку автонастройки почты, выбираю автоопределение и нажимаю проверка, то поиск завершается через 10-15 секунд после того, как находится https://mail.pharm.com/autodiscover/autodiscover.xml. Получается он даже не смотрит SCP.

    14 января 2019 г. 8:49
  • В SCP аутлук смотрит всегда. Это его алгоритм работы.

    Здесь подробнее:

    https://support.microsoft.com/en-us/help/3211279/outlook-2016-implementation-of-autodiscover

    Аутлук достаточно часто обращается к службе автообнаружения, сам.

    Если в SCP есть запись с именем выключенного сервера, рано или поздно аутлук будет пробовать к нему подключаться и "виснуть", пока не сессия не отвалится по таймауту.

    14 января 2019 г. 9:01
  • У старого выключенного CAS01 попробуйте обнулить URI.

    AutoDiscoverServiceInternalUri

    14 января 2019 г. 9:13
  • Можно или обнулить URL или назначить на общую запись.

    Set-ClientAccessServer -Identity "old-cas" -AutoDiscoverServiceInternalUri "https://mail.pharm.com/autodiscover/autodiscover.xml"

    Если он даст это сделать на выключенном сервере..

    Не помню, применим ли ключ ConfigurationOnly

    14 января 2019 г. 9:22
  • Общая запись уже была. Сейчас поставил пустую, сервер включать не пришлось.
    14 января 2019 г. 10:00
  • Если у него в URI уже была общая запись, то дело скорее всего не в этом.

    Прям хоть Fiddler можно брать (включить decrypt https), воспроизводить проблему и смотреть куда он стучится.

    14 января 2019 г. 10:36
  • Поставил мониторинг. Пока из странных вещей появлялось только это

    Во время лага никаких желтых и красных событий, связанных с почтой, не было. Вообще событий с mail.pharm.com было только одно с кодом 200:

    HTTP/1.1 200 OK
    Cache-Control: no-cache, no-store
    Pragma: no-cache
    Content-Type: application/json; charset=utf-8
    Content-Encoding: gzip
    Expires: -1
    Vary: Accept-Encoding
    Server: Microsoft-IIS/8.5
    request-id: 2f93f2d3-dfce-4eb6-8c2c-47f48608b4bd
    X-CalculatedBETarget: mbox2.pharm.com
    X-Content-Type-Options: nosniff
    X-UA-Compatible: IE=10
    X-AspNet-Version: 4.0.30319
    Set-Cookie: X-BackEndCookie=S-1-5-21-1112449896-297553042-964272827-42061=u56Lnp2ejJqBmZnGyMvPz8/Sxp3MntLLmczL0sbOy5zSysjOmZ3Iy52cnszKgYHNz87G0s/N0s7Mq87Oxc3LxcrK&S-1-5-21-1112449896-297553042-964272827-42060=u56Lnp2ejJqBx8icyc7PnM/SyMbIydLLyc7M0sfGx8fSnZ6cz5zNx8/PzZvHgYHNz87G0s/O0s7Jq8/IxczIxczN; expires=Wed, 13-Feb-2019 11:24:55 GMT; path=/ecp; secure; HttpOnly
    X-Powered-By: ASP.NET
    X-FEServer: MBOX6
    Date: Mon, 14 Jan 2019 11:24:55 GMT
    Content-Length: 322

             `I %&/m {J J  t  `$ؐ@      iG#) *  eVe]f@ 흼  {   {   ; N'   ?\fdl  J ɞ!   ?~|?"~ G    ~ ߿ ^ =  ;M |ZLۢZf

    *** FIDDLER: RawDisplay truncated at 128 characters. Right-click to disable truncation. ***

    Но такие сообщения появляются и когда почта работает нормально.

    14 января 2019 г. 11:31
  • Не появилось новых примеров в наблюдении за трафиком? 

    А если включить обратно выключенные серверы exchange, проблема исчезает?

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

    15 января 2019 г. 4:30
  • В логах Fiddler сообщения те же. Старые отключенные серверы CAS и MBX в логах не фигурируют.

    Серверы пока обратно не включал. Так как проблема не постоянная и специально её воспроизвести не получается, нужно чтобы сервер авторизации был включен целый день. А я хотел неделю-две подержать его в выключенном состоянии перед удалением, а то мало ли что может всплыть. Но если других идей не будет, то придется включить обратно и посмотреть как outlook будет работать с ним.

    15 января 2019 г. 7:20
  • А как у вас реализован DAG из 4х серверов?

    Все серверы на одной площадке или разнесены географически.

    Сеть, виртульные машины или физические, конфигурация серверов


    15 января 2019 г. 8:24
  • Все на одной площадке, виртуальные. 4 сокета по 4 ядра, 48ГБ оперативной памяти, диски SSD. Не думаю что проблема может быть в ресурсах т.к. раньше были такие же мощности, но два сервера.

    Сейчас периодически поглядываю в outlook, зависания клиента все так же продолжаются, но длятся меньше. При этом если нажимать на повторное подключение в состоянии подключения, оно проходит почти сразу же. Возможно повлияло удаление autodiscover uri в отключенном CAS сервере. 

    Сегодня еще послежу за ситуацией, спрошу у коллег заметили ли они разницу.

    15 января 2019 г. 8:47