Microsoft released a fix for the Exchange Y2K22 bug
- A lot of users woke up on the first day of the year and couldn't believe it.
- Work emails were empty because of a major Microsoft Exchange problem.
- The Redmond tech giant has now issued a fix patch for this nasty issue.
- The solution can be applied manually or automatically by using PowerShell.
A lot of users woke up on January 1st, 2022, and found that your their work email’s inbox was unusually empty. This massive date processing failure issue exceeded what the Servers are capable of processing under the current Int32 data type.
As a result, the malware checking engine is crashing, and consequently, emails and messages have been stuck in transport queues across Exchange Servers 2016 and 2019.
But you can now breathe a sigh of relief because the Redmond tech giant has released a fix patch for this bug.
Manual and automated solutions provided by Microsoft
Just as the company promised on the first day of 2022, it has finally delivered a fix for this nasty problem.
In order to get the fix, IT admins can change the execution policy for PowerShell scripts by running Set-ExecutionPolicy -ExecutionPolicy RemoteSigned.
Afterward, the script can be downloaded with a simple click. and ran on each Exchange mailbox server that downloads antimalware updates.
There is also a manual solution available, which according to Microsoft, is currently automated because it might take some time to make changes, download updated files, and clear transport queues.
Log Name: Application Source: FIPFS Logged: 1/1/2022 1:03:42 AM Event ID: 5300 Level: Error Computer: server1.contoso.com Description: The FIP-FS "Microsoft" Scan Engine failed to load. PID: 23092, Error Code: 0x80004005. Error Description: Can't convert "2201010001" to long.
Log Name: Application Source: FIPFS Logged: 1/1/2022 11:47:16 AM Event ID: 1106 Level: Error Computer: server1.contoso.com Description: The FIP-FS Scan Process failed initialization. Error: 0x80004005. Error Details: Unspecified error.
The tech giant makes it clear that any manual or automated solution must be performed on every on-premises Exchange 2016 and Exchange 2019 server, and the script can even be run simultaneously on multiple servers.
[PS] C:\Program Files\Microsoft\Exchange Server\V15\Scripts>.\Reset-ScanEngineVersion.ps1 EXCH1 Stopping services... EXCH1 Removing Microsoft engine folder... EXCH1 Emptying metadata folder... EXCH1 Starting services... WARNING: Waiting for service 'Microsoft Filtering Management Service (FMS)' to start... WARNING: Waiting for service 'Microsoft Filtering Management Service (FMS)' to start... WARNING: Waiting for service 'Microsoft Filtering Management Service (FMS)' to start... WARNING: Waiting for service 'Microsoft Filtering Management Service (FMS)' to start... WARNING: Waiting for service 'Microsoft Exchange Transport (MSExchangeTransport)' to start... EXCH1 Starting engine update... Running as EXCH1-DOM\Administrator. -------- Connecting to EXCH1.CONTOSO.com. Dispatched remote command. Start-EngineUpdate -UpdatePath http://amupdatedl.microsoft.com/server/amupdate -------- [PS] C:\Program Files\Microsoft\Exchange Server\V15\Scripts>Get-EngineUpdateInformation Engine : Microsoft LastChecked : 01/01/2022 08:58:22 PM -08:00 LastUpdated : 01/01/2022 08:58:31 PM -08:00 EngineVersion : 1.1.18800.4 SignatureVersion : 1.355.1227.0 SignatureDateTime : 01/01/2022 03:29:06 AM -08:00 UpdateVersion : 2112330001 UpdateStatus : UpdateAttemptSuccessful
In all cases, using Microsoft’s emergency script might take some time to run. The script might also take some time to clean up any missed messages in the transport queue.
Public reaction to the fix has been mixed, with some saying it works, while others are claiming it doesn’t do anything.
Other users report that running the script multiple times could help fix the issue, indicating that Microsoft could have done a better job.
Have you managed to sort it out using the solution provided by Microsoft? Let us know in the comments section below.