W korporacyjnym świecie wraz ze zmianą daty na 2022 rok w niektórych organizacjach przestały docierać maile do użytkowników. Wszystkiemu winien był błąd w sprawdzaniu sygnatur plików przez silnik anty-malware wbudowany w Exchange. Na szczęście błąd ten został szybko naprawiony przez Microsoft przez poprawkę wydaną w ubiegły weekend.
Microsoft wyjaśnił wszystko na swoim blogu. Czytamy tam między innymi, że problem dotyczy tylko środowisk on-premise w wersji 2016 lub 2019, w których aktywny jest moduł AV. Microsoft zapewnia również, że nie jest to żadna dziura czy bug związany z bezpieczeństwem i nie mamy czego się obawiać. To tylko sprawdzanie wersji sygnatury plików powoduje awarię i crash silnika AV, a to z kolei skutkuje blokowaniem wiadomości w kolejkach transportowych na serwerze.
Problem odbił się dużym echem w Internecie, co możemy zobaczyć poniżej:
Zaczął też zwracać uwagę administratorów, gdy rozpoczął się rok 2022, powodując, że serwery nie dostarczały wiadomości e-mail, a jednocześnie wyświetlały następujący komunikat: „The FIP-FS ‘Microsoft’ Scan Engine failed to load. PID: 23092, Error Code: 0x80004005. Error Description: Can’t convert ‘2201010001’ to long.”
W logu aplikacyjnym można było za to znaleźć następujące wpisy:
Naprawa problemu
Microsoft zagregował szybko prezentując rozwiązanie naprawiające problematyczny moduł. Poprawkę można wdrożyć na dwa sposoby: – automatyczny – wykonując dostarczony przez MS skrypt – ręczny – usuwając pliki z silnika AV i instalując nowe
Metoda Automatyczna
- Pobierz skrypt tutaj: https://aka.ms/ResetScanEngineVersion
- Przed uruchomieniem skryptu zmień zasady wykonywania skryptów PowerShell, uruchamiając Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
- Uruchom skrypt na każdym serwerze Exchange z rolą mailbox, który pobiera aktualizacje chroniące przed złośliwym oprogramowaniem w Twojej organizacji
Skrypt ten można uruchomić równolegle na wielu serwerach. Po zakończeniu skryptu powinniśmy zobaczyć dane wyjściowe podobne do poniższych:
Metoda Manualna
Zamiast używać skryptu, klienci mogą również ręcznie wykonać kroki w celu rozwiązania problemu i przywrócenia usługi. Aby ręcznie rozwiązać ten problem, należy wykonać następujące kroki również na każdym z serwerów Exchange z rolą „Mailbox”. Problem ten nie dotyczy serwerów z rolą „Transport Edge”.
1. Sprawdź, czy wersja, której dotyczy problem, jest zainstalowana:
– Uruchom Get-EngineUpdateInformation i sprawdź informacje UpdateVersion. Jeśli zaczyna się od „22…”, kontynuuj. Jeśli zainstalowana wersja zaczyna się od „21…”, nie musisz podejmować żadnych działań.
2. Usuń istniejący silnik i metadane:
– Zatrzymaj usługę Microsoft Filtering Management. Po wyświetleniu monitu o zatrzymanie usługi Microsoft Exchange Transport kliknij przycisk Tak.
– Użyj Menedżera zadań, aby upewnić się, że updateservice.exe nie jest uruchomiony.
– Usuń następujący folder: %ProgramFiles%\Microsoft\Exchange Server\V15\FIP FS\Data\Engines\amd64\Microsoft.
– Usuń wszystkie pliki z następującego folderu: %ProgramFiles%\Microsoft\Exchange Server\V15\FIP-FS\Data\Engines\metadata.
3. Aktualizacja do najnowszego silnika:
– Uruchom usługę Microsoft Filtering Management i usługę Microsoft Exchange Transport.
– Otwórz powłokę Exchange Management Shell, przejdź do folderu Scripts (%ProgramFiles%\Microsoft\Exchange Server\V15\Scripts) i uruchom Update-MalwareFilteringServer.ps1
4. Sprawdź informacje o aktualizacji silnika:
– W powłoce zarządzania Exchange uruchom Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell.
– Uruchom Get-EngineUpdateInformation i sprawdź, czy informacja UpdateVersion to 2112330001 (lub nowsza)
Po zaktualizowaniu Microsoft zaleca oczywiście sprawdzenie czy przepływ poczty działa i czy zdarzenia błędów FIPFS nie są obecne w dzienniku zdarzeń w logu aplikacyjnym.