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 ...
Updated Jan 11, 2022
Version 36.0
Blog Post
Dani Kaplan This wasn't due to a change on 31st Dec. The problem is caused by an integer overflow error: the anti-malware component is converting the date/time into "YYMMDDHHMM" format and storing it as a signed 32-bit number (max value 2147483648). So, in Dec 2021, the number would start with "2112..." (below the threshold). In Jan 2022, the number would start with "2201..." (above the threshold).
The_Exchange_Team I think it would be useful to add this info to your blog post. I also have to echo what David_Richard said: when I was investigating the problem, I found Twitter threads (by your customers) several hours before anything appeared here. Even if you didn't have a solution right away, at the very least it would be useful for you to say "We know about this and we're working on it". That would save people time, e.g. I initially thought that it was a local problem to my environment so I was looking for anything related to back pressure.
In theory, this would be an ideal scenario for EEMS, if you could fix the problem automatically for any IT staff who finished work on Friday and won't find out about it until Tuesday morning. However, I'm guessing that this isn't possible if the fix requires customer action.