Пользователи сообщают о невозможности получения или отправления писем через on-premise Exchange 2016 и 2019. Всему виной автоматически устанавливаемое обновление встроенного антивируса.
В журнале регистрируется сообщение FIPFS 5300
The FIP-FS "Microsoft" Scan Engine failed to load. PID: 24608, Error Code: 0x80004005. Error Description: Can't convert "2201010004" to long.
На данный момент Microsoft предлагает официальное временное решение. С ним можно ознакомиться по ссылке https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-exchange-on-premises-transport-queues/ba-p/3049447
Важный момент: если перед применением официального скрипта Вы отключали antimalware scanning, то его нужно будет включить вручную после применения официального решения.
& $env:ExchangeInstallPath\Scripts\Enable-AntimalwareScanning.ps1
Restart-Service MSExchangeTransport
UPD: Конкретно в моем случае рестарт MSExchangeTransport не привел к очистке очередей. Но после перезапуска всех служб Exchange почта заработала.
Via Reddit
Комментарии (35)
unsignedchar
01.01.2022 16:16Боюсь даже представить, каким боком антивирус к вот этой вот ошипке в логах. itoa перехватывается антивирусом, да ещё и неудачно?
n0isy
01.01.2022 16:25+6Скорее всего какой-то лог или таблица имеет ID с таким int, генерируемым преобразованием даты в число вида YYYYMMDDHHmm... Я хотел было в прошлом году так же версию Android проекта генерить, но посчитал до которого срока это будет работать, и передумал.
Вот тебе и Y2K bug...точнее Y2K22 bug
sden77
01.01.2022 17:00Тогда вопрос, что там подразумевается под типом long. По идее, его должно хватить с огромным запасом
DistortNeo
01.01.2022 20:16+1В C/C++ тип long не имеет чётко определённого размера. В данном случае это был, видимо, int32.
z0ic
01.01.2022 23:54uint32_t = max 4294967295
uint64_t = max 18446744073709551615
В современных компиляторах unsigned long = uint64_t
staticmain
02.01.2022 02:01У майкрософта своё видение по поводу размера unsigned long, из-за чего по всему mingw пришлось расставлять костыли.
DistortNeo
02.01.2022 02:01+2https://docs.microsoft.com/en-us/cpp/cpp/data-type-ranges?view=msvc-170
В MSVC long — это int32_t.
Victor_koly
02.01.2022 14:32Мало кто использует в прогах uint, ИМХО.
Кто-то пробовал переносить в Героях стеки свыше 32767 юнитов в другую ячейку?
tbl
01.01.2022 17:18Между тем Y2K38 все ближе и ближе
JerleShannara
01.01.2022 21:21Пользователи ext2 напряглись.
Victor_koly
02.01.2022 14:35А что, проблема в том, что параметры типа "дата создания/изменения" у файла в той FS идет в старом формате "Epoch Unix Timestamp" и это никакими изсенениями в ядре не менялось?
JerleShannara
02.01.2022 15:10В том, что даже если поменять — сломается совместимость. Но с другой стороны — использовать ext2 в новых разработках в 202х годах это заявка на победу.
tbl
02.01.2022 23:33Надеюсь, что никто не завязывался на таймстампы в zip-файлах в 202x годах. А так же в прочих контейнерах, которые завязаны на этот формат, например jar, apk, ...
tbl
02.01.2022 23:50Еще у MySQL были проблемы с принятием патчей, фиксящих проблемы с 2K38. Предыдущие попытки в 2017 были отвергнуты с комментариями "слишком сложно" и "ломают локализацию". Не знаю, какое актуальное состояние проблемы там.
DistortNeo
02.01.2022 15:25Конечно. Вы никак не можете поменять формат хранения даты в стандартизированной файловой системе. Максимум, что можно сделать — это интерпретировать значение не как int32, а как uint32, тогда проблема отодвинется до 2106 года, но какие ещё при этом проблемы вылезут, никто сказать не сможет.
Victor_koly
02.01.2022 22:35Будем надеяться, что к тому году уже на всех компах Винда будет не старее Десятки :)
А то на работе Семерок куча, AV последним намеком говорил про "До конца 2021 года обновите ...".
DistortNeo
02.01.2022 02:07+4Интересный баг обнаружил я. В новой версии интерфейса Хабра в посте ошибка отображается как:
The FIP-FS "Microsoft" Scan Engine failed to load. PID: 24608, Error Code: 0x80004005. Error Description: Can't convert "2201010004" to long.
В старой же версии:
The FIP-FS "Microsoft" Scan Engine failed to load. PID: 24608, Error Code: 0x80004005. …
Возможно, из-за этого многие не понимают, в чём же дело.
Nem427
01.01.2022 18:15+2Disable-AntimalwareScanning.ps1 не помогло
Пришлось дополнительно на каждом сервере проделать
Set-MalwareFilteringServer mail-server-name -BypassFiltering $trueAlxDr
02.01.2022 02:02Дополню, что есть ещё подстава. Некоторые транспортные правила (в частности, с проверкой типа вложений) могут зависеть от этого компонента и после его отключения будут отваливаться по таймауту. Если они есть, почта будет ходить, но с задержками. При большой нагрузке могут быть проблемы.
В этом случае нужно смотреть Application log на серверах, искать ошибки с id этих правил и отключать их.
Alexsey
01.01.2022 19:49+2Использовать числовое значение (в данном случае int64) для хранения версии вида ГГММДДXXX это, конечно, сильно.
fougasse
02.01.2022 10:48+1Такие дела. И long таки 32 бита.
unsignedchar
02.01.2022 12:02Уверен, что этот код написан после 2000 года, когда программисты (и их погонщики) уже были в курсе возможности переполнения. Вот такой вот намёк, что не нужно сидеть на старых версиях. Обновляйте, покупайте новые, а то ваша Золушка вдруг превратится в тыкву.
fougasse
02.01.2022 12:26Старых версиях чего? В моделях памяти LP32, ILP32 и LLP64 long 32 бита. А LP64 в Windows нет. У меня подозрение, что легаси дало о себе знать таки.
unsignedchar
02.01.2022 14:08Legacy из 80-х годов разве что.В 90-х уже начали догадываться, что переполнения бывают. А после 2000 закапывать такое должно быть.. некрасиво, что ли.
DaemonGloom
02.01.2022 21:41+1Одна особенность. Старая версия Exchange (2013) всё ещё поддерживается, но проблеме не подвержена. Так что не всегда покупка новой будет полезна, оказывается.
VitalKoshalew
02.01.2022 21:57+1Этот код — интеграция с MS антивирусом, которой до прихода Satya Nadella в Exchange не было. Так что это под его чутким руководством. Это не единичный случай, а массовое явление во всём ПО Microsoft последних лет. У меня сложилось полное впечатление, что при Ballmer-е задача стояла «сделать качественно», а что при Gates-е, что при Nadella — «сделать как-нибудь», со всеми вытекающими последствиями.
MishaShevlyakov
02.01.2022 13:44+1Майкрсофт сказали делать это
Start Exchange Management Shell and run the following cmdlets:
Disable-TransportAgent "Malware Agent" -Confirm:$false
Restart-Service MSExchangeFrontEndTransport
Restart-Service MSExchangeSubmission
Restart-Service MsexchangeTransport
Мне хватило после отмены Malware Agent только ристарт на exhange trasnsport service.
Но еще это прислал инженер еще
AlxDr
02.01.2022 14:07+1Там фикс вышел :)
Пока проверить не получилось, судя по скорости обновления баз они качаются с МКС. На Реддите у кого-то завелось сразу, у кого-то потребовалась перезагрузка (?).
Mnemonic0
02.01.2022 20:162019 Exchange. Переехали на него месяц назад, всё работает. Что я делаю не так? Допустим уже прилетела обновка. 12-го, посмотрю, был ли сбой, покопаю логи.
CheshirCa
На Exchange 2016 ошибку подтверждаю, предложенное лечение помогло, будем ждать патча от Микрософт