Did The Y2K22 Bug Impact Your Exchange Server?

Did The Y2K22 Bug Impact Your Exchange Server?

Do you have an on-premise Microsoft Exchange Server? Did you notice you were missing e-mails on January 1st? Were you missing emails since January 1st and did not notice right away? If you answered, yes, it is likely that your system was affected by what is being called the Y2K22 Bug.

As the clock hit 12:00 AM on January 1, 2022, not everyone was filled with excitement about what the new year would bring. After experiencing two of the most unforgettable years of our lives, the anticipation was that 2022 would be better to us than 2020 and 2021. Unfortunately, things started off on a sour note for businesses and organizations that still have an on-premise Microsoft Exchange Server.

What Happened When the Clock Struck Midnight?

Microsoft had an unexpected mishap with its Exchange servers. The Microsoft Exchange servers were not able to process the new date of January 1, 2022, and this meant the servers were unable to process mail. Cyber security analysts were made aware of the issue after a patch was scheduled by Microsoft to pave the way for the processing of the new date. Unfortunately, the patch didn’t quite deliver. The bug has an impact on Exchange Server 2013, 2016, and 2019.

Additionally, the issue was initially attributed to Microsoft Exchange Server’s malware-scanning engine which manages dates in the form of 32-bit variables. The version checking performed against the signature file caused the malware engine to crash. However, Microsoft stated that the situation was not caused by a fault in either Exchange or its malware-scanning engine. According to Microsoft, the issue was caused by the engine’s date-checking process. Microsoft also stated that the issue was not a cyber security issue.

Microsoft uses the generalized-time syntax of YYMMDDHHMM. Unfortunately, the new year’s date was converted to signed int32, meaning the new value was 2,201,010,001. That accounted for the issue. Microsoft Exchange can only count up to 2,147,483,647. Therefore, the new value was too long. This led to an integer overflow which resulted in Exchange servers crashing, causing emails to get stuck in Exchange 2016 and 2019 transport queues.

What Happens Next?

Microsoft created a solution that addresses the issue of messages being stuck in transport queues on Exchange Server 2016 and Exchange Server 2019. However, customer action is needed to implement the solution offered by Microsoft. The automated solution involved using a script that needed to run on Exchange mailbox servers using an elevated Exchange Management Shell.

Without continuous monitoring, would you have known what was happening? Not too many people were expecting to receive an overflow of emails on New Year’s Day because it’s not exactly the busiest time for e-mails to come in. Would you have noticed if you did not receive at least one email? Many people were probably not checking their emails on New Year’s Day.

Not only is continuous monitoring necessary, but so is a fast response. For many workplaces, leaders were not aware that any of this was even happening until they returned to work after the holiday break. Can you imagine how many emails were stuck in the transport queue without some users even realizing it? Resolving the Microsoft Exchange Server issue was certainly not something businesses and organization leaders had on their list of things to do to bring in the new year, but many businesses and organizations did not have to face this issue because they do not have an in-house Exchange Server.

We have clients and that don’t have Exchange Servers in-house, and you may not need it either. If you would like to find out if you really need an in-house Exchange Server, please give us a call today at 719.355.2440.

Thanks to our friends at Orbis Solutions in Las Vegas for their ongoing support of our YouTube channel and blog.