Problem roku 2022 – użytkownicy Microsoft Exchange zgłaszają problemy działaniem poczty. Winna wartość: 2147483647…

Mogłoby się wydawać, że błędy w systemach informatycznych związane ze zmianą roku to domena przeszłości (np. znany problem roku 2000). Tymczasem nie do końca, bo użytkownicy Microsoft Exchange, czyli rozwiązania pocztowego stosowanego głównie w firmach, zgłaszają dziś takie błędy:

The FIP-FS „Microsoft” Scan Engine failed to load. PID: ХХХХХ, Error Code: 0x80004005. Error Description: Can’t convert „2201010001” to long.

(…)

Since the service is interconnected with the transport service, mail stops coming in and out, respectively.

FIP-FS to skaner antywirusowy dołączony po raz pierwszy do Exchange w wersji 2013. Zapewnia przynajmniej podstawową ochronę skrzynek, skanując zawartość poczty w poszukiwaniu różnego malware. Z powodu cytowanego wyżej błędu niemożliwe jest jego załadowanie do pamięci, tym samym blokuje on działanie poczty elektronicznej w środowiskach wykorzystujących Exchange. O ile w okresie świątecznym w wielu przypadkach nie jest to poważny problem, to w pewnych branżach produkcja musi działać praktycznie bez przerwy. Z drugiej strony kluczowe usługi powinny mieć zapewnione HA, jednak utrzymanie poczty jest generalnie skompilowanym zagadnieniem.

Jak zauważono w tym tweecie, maksymalna wartość typu long wynosi 2147483647, co niekoniecznie sprawdza się jako typ zmiennej przechowującej czas, szczególnie w formacie zastosowanym w Exchange. Data 1 stycznia 2022 roku „wyskoczyła” poza ten zakres, powodując dość poważny błąd (jego wystąpienie spowodowało „wysypanie” całości).

Nie istnieje jeszcze oficjalne rozwiązanie problemu, natomiast skutecznym obejściem według wielu użytkowników jest po prostu chwilowe wyłączenie skanera skryptem Disable-AntiMalwareScanning.ps1 i restart usługi MSExchangeTransport (teoretycznie samo użycie skryptu powinno wymusić restart).

Twórcy podobnych rozwiązań powinni zwracać uwagę na takie przypadki. W tej sytuacji należałoby rozważyć użycie zmiennej innego typu, ale warto testować różne scenariusze (w tym reakcje programu na zmianę roku), ponieważ dzięki temu można wykryć również inne, pewnie bardziej skomplikowane błędy. Sam Exchange zawierał już poważną podatność o nazwie ProxyLogon umożliwiającą RCE.

Testowanie różnych scenariuszy w odseparowanych środowiskach jest też ważnym zadaniem administratorów. Nie powinno się na pewno polegać na jednym dostawcy, raczej starać się używać różnych komponentów. W przypadku poczty można też rozważyć utrzymywanie jej na zewnątrz, zamiast we własnej infrastrukturze, co potrafi zaoszczędzić wiele czasu i często jest również opłacalne. Dobrym rozwiązaniem jest zastosowanie HA, czyli zapewnienie ciągłości działania (SLA) systemu, kiedy jeden z jego elementów nie działa. Nie oznacza to awarii danego komponentu środowiska, ale również standardowe prace administracyjne, które w idealnej sytuacji nie powinny mieć wpływu na działanie systemu. Zdecydowanie nie powinno być SPOF, pojedynczych punktów awarii, tj. elementu, którego niedostępność powoduje przerwanie działania całości.

–Michał Giza