Комментарии 40
На Exchange 2016 ошибку подтверждаю, предложенное лечение помогло, будем ждать патча от Микрософт
Угу, тоже сломалась почта на работе :)
Боюсь даже представить, каким боком антивирус к вот этой вот ошипке в логах. itoa перехватывается антивирусом, да ещё и неудачно?
Скорее всего какой-то лог или таблица имеет ID с таким int, генерируемым преобразованием даты в число вида YYYYMMDDHHmm... Я хотел было в прошлом году так же версию Android проекта генерить, но посчитал до которого срока это будет работать, и передумал.
Вот тебе и Y2K bug...точнее Y2K22 bug
В C/C++ тип long не имеет чётко определённого размера. В данном случае это был, видимо, int32.
uint32_t = max 4294967295
uint64_t = max 18446744073709551615
В современных компиляторах unsigned long = uint64_t
https://docs.microsoft.com/en-us/cpp/cpp/data-type-ranges?view=msvc-170
В MSVC long — это int32_t.
Мало кто использует в прогах uint, ИМХО.
Кто-то пробовал переносить в Героях стеки свыше 32767 юнитов в другую ячейку?
Между тем Y2K38 все ближе и ближе
А что, проблема в том, что параметры типа "дата создания/изменения" у файла в той FS идет в старом формате "Epoch Unix Timestamp" и это никакими изсенениями в ядре не менялось?
Надеюсь, что никто не завязывался на таймстампы в zip-файлах в 202x годах. А так же в прочих контейнерах, которые завязаны на этот формат, например jar, apk, ...
Конечно. Вы никак не можете поменять формат хранения даты в стандартизированной файловой системе. Максимум, что можно сделать — это интерпретировать значение не как int32, а как uint32, тогда проблема отодвинется до 2106 года, но какие ещё при этом проблемы вылезут, никто сказать не сможет.
Будем надеяться, что к тому году уже на всех компах Винда будет не старее Десятки :)
А то на работе Семерок куча, AV последним намеком говорил про "До конца 2021 года обновите ...".
Интересный баг обнаружил я. В новой версии интерфейса Хабра в посте ошибка отображается как:
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. …
Возможно, из-за этого многие не понимают, в чём же дело.
Del
Disable-AntimalwareScanning.ps1 не помогло
Пришлось дополнительно на каждом сервере проделать
Set-MalwareFilteringServer mail-server-name -BypassFiltering $true
Дополню, что есть ещё подстава. Некоторые транспортные правила (в частности, с проверкой типа вложений) могут зависеть от этого компонента и после его отключения будут отваливаться по таймауту. Если они есть, почта будет ходить, но с задержками. При большой нагрузке могут быть проблемы.
В этом случае нужно смотреть Application log на серверах, искать ошибки с id этих правил и отключать их.
ппц админам счастье привалило на новый год
Использовать числовое значение (в данном случае int64) для хранения версии вида ГГММДДXXX это, конечно, сильно.
Такие дела. И long таки 32 бита.
Уверен, что этот код написан после 2000 года, когда программисты (и их погонщики) уже были в курсе возможности переполнения. Вот такой вот намёк, что не нужно сидеть на старых версиях. Обновляйте, покупайте новые, а то ваша Золушка вдруг превратится в тыкву.
Старых версиях чего? В моделях памяти LP32, ILP32 и LLP64 long 32 бита. А LP64 в Windows нет. У меня подозрение, что легаси дало о себе знать таки.
Одна особенность. Старая версия Exchange (2013) всё ещё поддерживается, но проблеме не подвержена. Так что не всегда покупка новой будет полезна, оказывается.
Майкрсофт сказали делать это
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.
Но еще это прислал инженер еще
Там фикс вышел :)
Пока проверить не получилось, судя по скорости обновления баз они качаются с МКС. На Реддите у кого-то завелось сразу, у кого-то потребовалась перезагрузка (?).
Интересный сюрприз ждет 10.01.2021 тех, кто не читает новости...
2019 Exchange. Переехали на него месяц назад, всё работает. Что я делаю не так? Допустим уже прилетела обновка. 12-го, посмотрю, был ли сбой, покопаю логи.
Отключить Antimalware
>& $env:ExchangeInstallPath\Scripts\Disable-AntimalwareScanning.ps1
Get-ExchangeServer | % {Set-MalwareFilteringServer -BypassFiltering $true -Identity $_.Name}
Отключить службы: Microsoft Filtering Management service. и Microsoft Exchange Transport service
Отрубить задачу updateservice.exe в диспетчер задач
Удалить папку "Microsoft" %ProgramFiles%\Microsoft\Exchange Server\V15\FIP-FS\Data\Engines\amd64\Microsoft.
Удалить содержимой папки %ProgramFiles%\Microsoft\Exchange Server\V15\FIP-FS\Data\Engines\metadata.
Запусить службы: Microsoft Filtering Management service. и Microsoft Exchange Transport service
Запуск скрипта: %ProgramFiles%\Microsoft\Exchange Server\V15\Scripts), Update-MalwareFilteringServer.ps1
Оригинал: https://www.alitajran.com/exchange-mail-flow-breaks/
Спасибо за информацию. Полторя дня страдали с этой проблемой. Перебрали на серваке все конфиги, все ошибки, сертификаты. Только в антивирус и не заглядывали, а зря... А счастье оказывается нам привалило от разработчиков. Не так мы с коллегой расчитывали провести начало нового года, мда. Жаль только, что накопившаяся очередь сообщений канула в лету. Придется ждать исправления, с отключенной защитой на почтовом сервере жить, это не дело конечно.
Exchange 2016\2019 перестал работать в новогоднюю ночь