Microsoft patches Y2K-like bug that borked on-prem Exchange Server Microsoft has kicked off 2022 by issuing a patch for Exchange Server 2016 and 2019, which both possessed a “latent date issue” that saw emails queued up instead of being dispatched to inboxes. “The problem relates to a date check failure with the change of the new year,” states a January 1st post to the Exchange Blog. …
This sounds like a result of some legacy code, a good few years old which was expected to be replaced and then was forgotten about. Maybe the coder who marked it in his/her calendar or ToDo list left and no one else knew about it.
As mentioned in the articles, it's very Y2K-like, no one expected the code to still be in use after it's "Use By" date.
This isn't "legacy" - it's a horrible hack, as they're trying to encode a character based representation into a numeric variable and seems to be the result of some horrible mental confusion. This should have never been written in the first place. They need an absolute thrashing.
I would not call them a "coder" any more than someone that "programs HTML"
> [ ... ] they're trying to encode a character based representation into a numeric variable [ ... ]
That's not what's going on here.
It's pure stupidity on the part of the implementor - namely Microsoft.
They decided to use a signed 32-bit integer instead of an unsigned 64-bit integer to represent a date - namely the type time_t.
Maximum possible value of a 32-bit signed integer: 2,147,483,647. Evidently, 2,201,010,001 won't fit, so it overflows.
Maximum possible value of a 64-bit unsigned integer: 18,446,744,073,709,551,615.
If they changed signed to unsigned but kept the 32-bit integer size in their patch - which is very likely, given Microsoft's legendary QOI - they're going to run into the time_t problem in 2038.
They only had 22 years to think about this, so we gotta cut them some slack.
Congrats to Microsoft for making everyone re-live the party atmosphere of 12/31/1999. Cue mandatory Prince song here.
The current fix: Represent 2022-01-02 as 2021-12-33. Using the same logic they are good until 2024-12-19 12:47. If they switch to uint32_t they get to 2042-12-31 23:59 without trickery and 2042-94-96 72:95 works out as 2050-01-07 01:35. I could live to see this bug back again at the start of 2043 but 2050 is probably past my sell by date <sarcasm>so there is no need to switch to a 64-bit type ever</sarcasm>!
It is more than pure stupidity as this is not a time_t limit, its signed roll-over is still 2038 so a bit more to go as today is only 1641290719
Nope, what they appear to have done is use an integer as a 'string' YYMMDDhhmm for some WTF reason. Honestly that is so much worse as clearly they have not bothered to use any standard (and hopefully tested) time library, not POSIX time_t nor even win32 calls, in order to handle things but rolled their own incompetent hack.
No the known 2038 bug is when storing dates as seconds from the epoch and applies to signed 32-bit https://en.wikipedia.org/wiki/Year_2038_problem
Microsoft have hit the limit early because they are using a less efficient encoding
they take the 6 2-digit YY MM dd HH mm SS fields and encode these as base 100 numbert then convert to binary as the valid ranges in all but the year fields have maximum values less than 99 there are huge unused ranges and they ran out of space now.
This was not just Microsoft. SonicWALL's on-prem email security appliances GUI stopped updating at New Years also - https://www.sonicwall.com/support/knowledge-base/email-security-stops-logging-junkbox-and-message-logs/220103080034540/
So far SonicWALL has not explained this. Email did continue to flow through the devices.
There are two things to observe here (in naming updates with yymmdd####)...
1. changing the type from the equivalent of "int32_t" to "uint32_t" would solve the problem for several thousand years.
2. Does everyone understand that by reserving four digits for an update counter *within a day*, Microsoft effectively said "our software is sooooo bad, we might actually have to post a thousand or more updates *in a single day*"? Sheesh! :)
1. changing the type from the equivalent of "int32_t" to "uint32_t" would solve the problem for several thousand years.
But they'd have lost the ability to handle BC dates.
2. Does everyone understand that by reserving four digits for an update counter *within a day*, Microsoft effectively said "our software is sooooo bad, we might actually have to post a thousand or more updates *in a single day*"?
It's the sort of conservative approach they should have taken in handling the date in the scanner.
Post-dated spam has been coming in for at least the last 20 years. It didn't cause failure of delivery in the version of Exchange I was using -- but it did cause failure of aging and deletion, with post '22 mail never matching the deletion criteria.
This post has been deleted by its author
Object-Oriented coding exists since when already ? Why are we still coding dates in strings instead of having a date object that has, say, four elements : year, month, day, timezone ? We should have a time object with hour, minutes, seconds, hundredths. And we could have a date-time object inheriting from both.
That would avoid all these shenanigans about trying to convert dates into numbers.
And, Borkzilla, you might want to check your Excel code. It works there.
"That would avoid all these shenanigans about trying to convert dates into numbers."
Everything in a computer is a sequence of 1s and 0s. Even your precious Objects are just a collection of numbers. Conversion will always be necessary, if not by you then by the library you call. "yyddmmssff" -.> int32 is an egregiously bad way to do it, but the solution is "library", not "objects".
There must be stories out there of companies where this year someone said "I'm sick of paying our admins to be on standby every new year's eve in case there's a date rollover problem - it just never happens!".
But for those of us who are unaffected, we can enjoy this nice example of "premature optimisation is the root of all evil".
Honestly, it's hard not to hear the black helicopters overhead from this latest screw-up with MSFT's avowed intention of forcing everyone into the cloud. Although, since a hybrid Azure deployment still requires Exchange servers on prem even if all mailboxes are in EXO, it's hard to know if it's Exchange or simply on-prem AD they're really after. (I joke. Kind of.)
That said, it's classic business as usual with Exchange CUs. While the window between OS patch releases and production deployment has increasingly narrowed in my little world, there's very little that'd induce me to apply an Exchange CU less than 2 months after release. In fact, in recent years, there have been perhaps two I've applied within a month. (Applied other workarounds for a few others in the interim. )
For even the "super urgent" ones, I've waited at least 10 days after release and carefully reviewed the changes... and waited for the screaming to die down and the fixes to be released.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
