Пользователи сообщают о невозможности получения или отправления писем через 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)


  1. CheshirCa
    01.01.2022 16:09
    +6

    На Exchange 2016 ошибку подтверждаю, предложенное лечение помогло, будем ждать патча от Микрософт


  1. QtRoS
    01.01.2022 16:12
    +1

    Угу, тоже сломалась почта на работе :)


  1. unsignedchar
    01.01.2022 16:16

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


    1. n0isy
      01.01.2022 16:25
      +6

      Скорее всего какой-то лог или таблица имеет ID с таким int, генерируемым преобразованием даты в число вида YYYYMMDDHHmm... Я хотел было в прошлом году так же версию Android проекта генерить, но посчитал до которого срока это будет работать, и передумал.

      Вот тебе и Y2K bug...точнее Y2K22 bug


      1. sden77
        01.01.2022 17:00

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


        1. DistortNeo
          01.01.2022 20:16
          +1

          В C/C++ тип long не имеет чётко определённого размера. В данном случае это был, видимо, int32.


        1. z0ic
          01.01.2022 23:54

          uint32_t = max 4294967295

          uint64_t = max 18446744073709551615

          В современных компиляторах unsigned long = uint64_t


          1. staticmain
            02.01.2022 02:01

            У майкрософта своё видение по поводу размера unsigned long, из-за чего по всему mingw пришлось расставлять костыли.



          1. Victor_koly
            02.01.2022 14:32

            Мало кто использует в прогах uint, ИМХО.

            Кто-то пробовал переносить в Героях стеки свыше 32767 юнитов в другую ячейку?


      1. tbl
        01.01.2022 17:18

        Между тем Y2K38 все ближе и ближе


        1. JerleShannara
          01.01.2022 21:21

          Пользователи ext2 напряглись.


          1. Victor_koly
            02.01.2022 14:35

            А что, проблема в том, что параметры типа "дата создания/изменения" у файла в той FS идет в старом формате "Epoch Unix Timestamp" и это никакими изсенениями в ядре не менялось?


            1. JerleShannara
              02.01.2022 15:10

              В том, что даже если поменять — сломается совместимость. Но с другой стороны — использовать ext2 в новых разработках в 202х годах это заявка на победу.


              1. tbl
                02.01.2022 23:33

                Надеюсь, что никто не завязывался на таймстампы в zip-файлах в 202x годах. А так же в прочих контейнерах, которые завязаны на этот формат, например jar, apk, ...


                1. tbl
                  02.01.2022 23:50

                  Еще у MySQL были проблемы с принятием патчей, фиксящих проблемы с 2K38. Предыдущие попытки в 2017 были отвергнуты с комментариями "слишком сложно" и "ломают локализацию". Не знаю, какое актуальное состояние проблемы там.


            1. DistortNeo
              02.01.2022 15:25

              Конечно. Вы никак не можете поменять формат хранения даты в стандартизированной файловой системе. Максимум, что можно сделать — это интерпретировать значение не как int32, а как uint32, тогда проблема отодвинется до 2106 года, но какие ещё при этом проблемы вылезут, никто сказать не сможет.


        1. Victor_koly
          02.01.2022 22:35

          Будем надеяться, что к тому году уже на всех компах Винда будет не старее Десятки :)

          А то на работе Семерок куча, AV последним намеком говорил про "До конца 2021 года обновите ...".


      1. 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. …

        Возможно, из-за этого многие не понимают, в чём же дело.


  1. V-core
    01.01.2022 16:41

    Del


  1. Nem427
    01.01.2022 18:15
    +2

    Disable-AntimalwareScanning.ps1 не помогло


    Пришлось дополнительно на каждом сервере проделать
    Set-MalwareFilteringServer mail-server-name -BypassFiltering $true


    1. AlxDr
      02.01.2022 02:02

      Дополню, что есть ещё подстава. Некоторые транспортные правила (в частности, с проверкой типа вложений) могут зависеть от этого компонента и после его отключения будут отваливаться по таймауту. Если они есть, почта будет ходить, но с задержками. При большой нагрузке могут быть проблемы.

      В этом случае нужно смотреть Application log на серверах, искать ошибки с id этих правил и отключать их.


  1. LAG_LAGbI4
    01.01.2022 18:55
    +9

    ппц админам счастье привалило на новый год


  1. Alexsey
    01.01.2022 19:49
    +2

    Использовать числовое значение (в данном случае int64) для хранения версии вида ГГММДДXXX это, конечно, сильно.


    1. dth_apostle
      02.01.2022 11:17

      ---- del ----


  1. fougasse
    02.01.2022 10:48
    +1

    Такие дела. И long таки 32 бита.


    1. unsignedchar
      02.01.2022 12:02

      Уверен, что этот код написан после 2000 года, когда программисты (и их погонщики) уже были в курсе возможности переполнения. Вот такой вот намёк, что не нужно сидеть на старых версиях. Обновляйте, покупайте новые, а то ваша Золушка вдруг превратится в тыкву.


      1. fougasse
        02.01.2022 12:26

        Старых версиях чего? В моделях памяти LP32, ILP32 и LLP64 long 32 бита. А LP64 в Windows нет. У меня подозрение, что легаси дало о себе знать таки.


        1. unsignedchar
          02.01.2022 14:08

          Legacy из 80-х годов разве что.В 90-х уже начали догадываться, что переполнения бывают. А после 2000 закапывать такое должно быть.. некрасиво, что ли.


      1. DaemonGloom
        02.01.2022 21:41
        +1

        Одна особенность. Старая версия Exchange (2013) всё ещё поддерживается, но проблеме не подвержена. Так что не всегда покупка новой будет полезна, оказывается.


      1. VitalKoshalew
        02.01.2022 21:57
        +1

        Этот код — интеграция с MS антивирусом, которой до прихода Satya Nadella в Exchange не было. Так что это под его чутким руководством. Это не единичный случай, а массовое явление во всём ПО Microsoft последних лет. У меня сложилось полное впечатление, что при Ballmer-е задача стояла «сделать качественно», а что при Gates-е, что при Nadella — «сделать как-нибудь», со всеми вытекающими последствиями.


  1. 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.

    Но еще это прислал инженер еще


  1. AlxDr
    02.01.2022 14:07
    +1

    Там фикс вышел :)

    https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-transport-queues/ba-p/3049447

    Пока проверить не получилось, судя по скорости обновления баз они качаются с МКС. На Реддите у кого-то завелось сразу, у кого-то потребовалась перезагрузка (?).


  1. evros
    02.01.2022 15:06

    Интересный сюрприз ждет 10.01.2021 тех, кто не читает новости...


  1. Mnemonic0
    02.01.2022 20:16

    2019 Exchange. Переехали на него месяц назад, всё работает. Что я делаю не так? Допустим уже прилетела обновка. 12-го, посмотрю, был ли сбой, покопаю логи.