Dla wielu osób Nowy Rok to chwila wytchnienia w gronie rodziny lub przyjaciół. To również czas składania noworocznych postanowień. Dla administratorów odpowiedzialnych za Exchange Server to jednak zupełnie inna historia. Nowy Rok przywitał ich błędem, w którym oprogramowanie nie mogło prawidłowo przejść na nową datę i w ramach tego — również przetwarzać wiadomości e-mail.
Wielu naszych Czytelników zapewne pamięta panikę pod koniec 1999 roku związaną ze zmianą daty na 2000 rok. "Problem roku 2000", "pluskwa milenijna" czy "Y2K bug" to najbardziej znane nazwy tego zjawiska. Ostatecznie nic specjalnego się nie stało i większość systemów nie odmówiła posłuszeństwa. Nic nie wskazywało na to, aby data 22 lata później miała być bardziej wyjątkowa. A taka niestety okazała się dla serwerowych wersji Microsoft Exchange.
Problem spowodowany był błędem w sprawdzaniu daty przez silnik antywirusowy Exchange Server, który nie mógł przełączyć się na 2022 rok. W efekcie maile pozostawały w stanie zawieszenia (kolejkowania przy przenoszeniu). Techniczna analiza wskazuje na powód w postaci użytej przez Microsoft zmiennej int32 dla określenia daty z nową wartością "2.201.010.001", która przekracza maksymalną wartość "long" int wynoszącą "2.147.483.647".
Problemem tym objęte zostały wersje Exchange Server 2013, 2016 i 2019. Na szczęście oficjalna poprawka już nadeszła. Administratorzy muszą zmienić zasadę wykonywania skryptów PowerShell, uruchamiając "Set-ExecutionPolicy -ExecutionPolicy RemoteSigned", a następnie użyć skryptu dostępnego do pobrania z serwera Microsoftu. Skrypt ten resetuje wersję silnika skanowania, co ostatecznie rozwiązuje problem z datą.
341f31d.png)