The infamous Y2K scare that rattled tech workers at the turn of the millennium is a story of the past but a new variant of it, Y2K22 has become a cause of concern. Fortunately, Microsoft has come up with a fix for it.
Microsoft rolls out fix for Exchange Y2K22 Bug
The Exchange Y2K22 bug relates mainly to a date check failure in Microsoft’s email service and is not security-related. The bug shut down on-premises mail delivery and stops users from accessing their inboxes. The good news is Microsoft has responded with a fix both, automated both and manual.
We have addressed the issue causing messages to be stuck in transport queues of on-premises Exchange Server 2016 and Exchange Server 2019. The problem relates to a date check failure with the change of the new year and it not a failure of the AV engine itself. This is not an issue with malware scanning or the malware engine, and it is not a security-related issue. The version checking performed against the signature file is causing the malware engine to crash, resulting in messages being stuck in transport queues, mentioned a Microsoft Blog post.
So, although Microsoft has created a solution for it, customer action is required to implement it. The company recommends downloading the script from this link.
Then, before running the script, change the execution policy for PowerShell scripts by running Set-ExecutionPolicy – ExecutionPolicy RemoteSigned.
Now, run the script on each Exchange mailbox server that downloads antimalware updates in your organization. Note – You should use elevated Exchange Management Shell.
Edge Transport servers are currently unaffected by this issue. However, you can run this script on multiple servers in parallel. After the script has been completed, you will see an output as shown in the image below!
Apart from the above automated solution, you can choose to resolve this issue manually and restore the service. Do the following on each Exchange mailbox server in your organization that downloads antimalware updates.
Run Get-EngineUpdateInformation and check the UpdateVersion information. If it starts with “22…” then proceed with the solution. On the other hand, if the installed version starts with “21…” you do not need to take any action.
Next, stop the Microsoft Filtering Management service. Also, when prompted to stop the Microsoft Exchange Transport service, hit the Yes button.
Ensure that updateservice.exe is not running. Check the Task Manager to confirm it.
Now, delete the following folder:
%ProgramFiles%\Microsoft\Exchange Server\V15\FIP-FS\Data\Engines\amd64\Microsoft.
When done, remove all files from the following folder:
%ProgramFiles%\Microsoft\Exchange Server\V15\FIP-FS\Data\Engines\metadata.
Now, update to the latest engine. Start the Microsoft Filtering Management service and the Microsoft Exchange Transport service.
Open the Exchange Management Shell, navigate to the Scripts folder (%ProgramFiles%\Microsoft\Exchange Server\V15\Scripts), and run Update-MalwareFilteringServer.ps1 <server FQDN>.
In the Exchange Management Shell, run Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell.
Run Get-EngineUpdateInformation and verify the UpdateVersion information is 2112330001 (or higher)
In the end, verify that mail flow is working and that FIPFS error events are not present in the Application event log.
