Почему не запускается служба IMAP4 на Exchange 2019 после установки обновления?

Question

[shupike]

Добрый день, коллеги! Такая проблема - установил позавчера апдейты на MS Exchange 2019 (Version 15.2 ‎(Build 1118.21), Enterprise), один из сотрудников, который был подключен через IMAP, забил тревогу - мол, авторизация не работает. Хотя логин и пароль те же, ничего не менялось, я проверил через OWA. Служба Microsoft Exchange IMAP4 остановлена и не запускается. При этом Microsoft Exchange IMAP4 Backend работает. Пробую вручную запустить Microsoft Exchange IMAP4 - ни в какую. Выдает ошибку 1036 "Failed to open one or more bindings. The service will be stopped.". В прошлый раз, когда черт дернул поставить апдейты на Exchange, возникала проблема с индексацией - заметили через неделю, что служба не запущена, в итоге по всем ящикам за этот период письма не попадали в результаты поиска - долго и нудно потом исправляли. Теперь вот новые приколы. Как это пофиксить? Заранее спасибо за помощь.



Дополнено: возникает в том числе еще и ошибка 1019: Failed to start listening (Error: 10048). Binding: 0.0.0.0:993.

Comments

[Роман Безруков]

MS Exchange 2019 (Version 15.2 ‎(Build 1118.21)

это билд до или после установки обновлений? порядок установки CU соблюден? ставили вручную?

1019: Failed to start listening (Error: 10048). Binding: 0.0.0.0:993

что говорит netstat -ano про порты 143/993?

[Роман Безруков]

еще можно запустить Exchange Server Health Checker script и внимательно посмотреть отчет

[shupike]

Роман Безруков, это после, ставил вручную. Три обновления было (на скрине добавил). Попутно - проверил при помощи system file check - ошибки есть:

[shupike]

Роман Безруков, проверку сделал, смущают несколько моментов:


Похоже, первым делом придется перезагрузить сервер, а потом снова смотреть.

[shupike]

Роман Безруков,
>что говорит netstat -ano про порты 143/993?

[Роман Безруков]

shupike,

это после, ставил вручную

вы только системные обновы ставили, а сам Exchange не трогали?
поменяйте Power Plan на сервере на High Performance, настройте Pagefile как указано и просто удалите указанный ключ реестра - после этого перегружайте сервер...
по netstat - что за процесс с PID 7748 ?

[shupike]

Роман Безруков,
>что за процесс с PID 7748 ?
Вот сам не пойму - именно на это ругается IMAP при попытке запуска вручную.

[shupike]

Роман Безруков,
>вы только системные обновы ставили, а сам Exchange не трогали?
Выходит так. Более того, только через сутки заметили проблему с IMAP - вот вообще не ожидал. Первым делом проверил же OWA, транспорт. Базы посмотрел - все на месте, смонтированы.

[Роман Безруков]

shupike, в Task Manager в Details или Services видно должно быть

[MVV]

просто удалите указанный ключ реестра - после этого перегружайте сервер...

Роман Безруков, какой ключ? Если PendingFileRenameOperation, то его лучше просто так не трогать: там в значениях указаны файлы, которые надо переименовать при перезагрузке в существующие, занятые сейчас каким-то процессом. А то автор вопроса получит несовместимые версии файлов и будет ловить глюки.

[Роман Безруков]

MVV, мне раза 3 за все время попадалось в этом ключе что-то действительно рабочее, в остальные разы - там просто "мусор" какой-то...

[shupike]

Роман Безруков, 7748 - Microsoft Exchange Frontend Transport (Running) - посмотрел щас.

[MaxKozlov]

ну так там может как раз "старая версия" запущена, которая после ребута подменится на новую?

[shupike]

Нашел изначальные настройки IMAP на этом сервере (с 2022 никто не менял ничего):

"Привет! Настроил свой ящик на новом Exchange - IMAP (SSL/TLS - порт 993, SMTP-STARTTLS, порт 587, SMTP-авторизация должна быть включена)" - из тогдашней переписки.

[shupike]

Перезагрузка не помогла. Может быть, имеет смысл удалить три последних обновления Windows?

[shupike]

Отследил хронологию по журналу (касетельно IMAP4):
- The service is trying to start. PID 15836
- The IMAP4 server has started successfully (Event 1000);
- Failed to start listening (Error: 10048). Binding: 0.0.0.0:993 (Event 1019);
- The address is already in use. Binding: 0.0.0.0:993 (Event 1018);
- Failed to open one or more bindings. The service will be stopped (Event 1036);
- The service is trying to stop. PID 15836 (Event 1002);
- The IMAP4 server has stopped successfully (Event 1001);
- The existing worker process HasExisted value before calling CloseProcess is True (Event 1040);
- Worker process with process ID 19432 has exited (Event 1020);
The service has stopped. PID 15836 (Event 1003).
Получается, что нечто резервирует под себя порт IMAP (993,SSL/TLS) и больше не отдает. Погуглил - попадаются треды прямо на learn.microsoft.com, только версия Exchnge 2016 и было это 3 года назад, там у кого-то такая же проблема с портом 2525. Ответа внятного так и не было в той ветке. разве что совет выполнить Get-ReceiveConnector | ft Identity,Enabled,TransportRole,Bindings
Похоже, кривые обновления - что можно придумать?
Вот вывод команды [PS] C:\Windows\system32>Get-ReceiveConnector | ft Identity,Enabled,TransportRole,Bindings

Identity Enabled TransportRole Bindings
-------- ------- ------------- --------
MAIL\Default MAIL True HubTransport {0.0.0.0:2525}
MAIL\Client Proxy MAIL True HubTransport {0.0.0.0:465}
MAIL\Default Frontend MAIL True FrontendTransport {0.0.0.0:25}
MAIL\Outbound Proxy Frontend MAIL True FrontendTransport {0.0.0.0:717}
MAIL\Client Frontend MAIL True FrontendTransport {0.0.0.0:587}
MAIL\OTRS a2p In True FrontendTransport {0.0.0.0:993, 0.0.0.0:587}
MAIL\Kyocera SMTP True FrontendTransport {0.0.0.0:25}
MAIL\HP LJ M282 True FrontendTransport {0.0.0.0:25}
MAIL\HP LJ M479 True FrontendTransport {0.0.0.0:25}
MAIL\UniFi controller True FrontendTransport {0.0.0.0:25}
MAIL\Kyocera_426 True FrontendTransport {0.0.0.0:25}
MAIL\Kaspersky True FrontendTransport {0.0.0.0:25}

[Роман Безруков]

shupike,

MAIL\OTRS a2p In True FrontendTransport {0.0.0.0:993, 0.0.0.0:587}

ну-ка, ну-ка - а откуда тут привязка к 993? Не должно такого быть...

[MVV]

7748 - Microsoft Exchange Frontend Transport (Running) - посмотрел щас.

shupike, Microsoft Exchange Frontend Transport этот порт слушать не должен. Вы точно между вызовом netstat и тем, как посмотреть, не перезапускали Exchange и не перезагружались?
Можете попробовать ещё раз: сделайте netstat а потом сразу посмотрите, что за просесс слушает порт - командой tasklist /FI "PID EQ что-там-в-netstat". Возможно, команду придется делать из командной строки в режиме администратора.

Если это frontend transport таки слушает - надо разбираться с его настройками.

PS Меня опередили.

[shupike]

Господа, вы будете смеяться :-) Утром на свежую голову залез через ECP, нашел этот странный receive connector - OTRS a2p In. Выключил его. Тут же удалось поднять службу IMAP, все заработало, для проверки настроил в аутлуке рандомный ящик именно через IMAP - все в норме.

Попутно проверил Get-NetTCPConnection:

Здесь все равно 2 "слушателя", видимо, один из них - приостановленный receive connector OTRS a2p In? Потому что по остальным портам только один "слушатель":


В общем, пообщался с коллегами, выяснилось, что один из сотрудников (он давно не работает) где-то когда-то добавил этот коннектор и каким-то странным образом никто не жаловался до вторника этой недели, когда я установил обновления и перезагрузил сервер. Там в свойствах коннектора целые гроздья интервалов IP-адресов, видимо, кто-то пытался разрешить подключение (???) именно с этих айпишников. Вроде бы есть какой-то удаленный клиент, а у нас Exchange спрятан внутри периметра, все подключаются через VPN. И для какого-то товарища будто бы пытались сделать исключение таким странным образом. Ну я высказался аккуратно, что так делать не стоит, там только коннекторы по 25 порту имеют смысл - для режима relay от офисных МФУ. В общем, все затихли пока.