Skip to main content

[Sorry for this OT, but that’s a severe worldwide bug]

A major bug has hit the Microsoft Exchanges on premise since January 1st 2022, because of using a int32 variable that long exceeds the maximum value of 2,147,483,647 causing the service goes error and blocking the queue mail.

A first solution released by the community was to disable the malware filtering service with the following powershell lines:

Set-MalwareFilteringServer -Identity <nameserver> -BypassFiltering $true
Restart-Service MSExchangeTransport

Microsoft yesterday released a powershell .ps1 that tricks the service by “unlocking the month of December 2021 to infinite days”, so today would be 34 December 2021.

https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-exchange-on-premises-transport-queues/ba-p/3049447

Honestly, I don’t know if this can be considered a good solution.

 

For more updates, there’s a dedicated subreddit:

https://www.reddit.com/r/sysadmin/comments/rt91z6/exchange_2019_antimalware_bad_update/

It‘s a better solution than disabling the malware agent entirely, if you don‘t have an additional malware scanning service before the exchange server.

But that would be another bad design decision not to have one 😂

 

The real fix for this issue will be surely provided with the next CU update.


Not having an additional malware scanning system in 2022 is very risky. :cold_sweat:

Real fix will be inside next CU, I agree with you, but we’ll probably have to wait until March 2022.

I hope Microsoft will release a new emergency fix in the next few days!


The bad part of this issue is, that Microsoft can’t fix it from their side. So if you are/were affected you had to take action and fix it yourself.


The bad part of this issue is, that Microsoft can’t fix it from their side. So if you are/were affected you had to take action and fix it yourself.

Like every on-premise bug :joy:
The absurd thing is the error of the integer variable, such mistake is not acceptable.


Comment