Exchange Y2K22 Bug: Kein Versand von Mails über Outlook mehr

Hallo zusammen,
ich hatte gerade das Problem das Unser Exchange Cluster keine Mails mehr versenden bzw, genau genommen nicht mehr zustellen wollte. Insbesondere welche nicht über die default Connectoren kamen. Alle Mails wurden in die Warteschlange gestellt mit dem Fehler: Die Nachricht wurde vom Kategorisierungs-Agent zurückgestellt.

Das Problem war am Ende der Transport-Agent Malware Agent, meine Lösung habe ich dann hier gefunden:

https://www.frankysweb.de/community/exchange2013/exchange-2013-e-mails-a ...

In kurz den Agent abschalten:

Get-TransportAgent "Malware Agent" | Disable-TransportAgent

(auf jedem Server)

Wir setzen Exchange 2016 Version 15.1 ‎(Build 2308.8)‎ ein. Und haben seit über zwei Wochen nichts geändert (Frozen Zone)

Zur Diskussion, hatte jemand ein ähnliches Problem? Gerade über die Feiertage. Das Problem trat ziemlich genau Neujahr auf. Und scheinbar haben andere Ähnliche Probleme nach den ersten Rückmeldungen.
Und wie kann sich der Agent einfach aktivieren oder hat sich nur das Filterverhalten geändert, und der Agent war vorher vielleicht einfach kein verhinderungsgrund?

Achso zum Thema Sicherheit wir scannen Mails mit einem vorgeschalteten System.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 1678015805

Url: https://administrator.de/contentid/1678015805

Ausgedruckt am: 21.11.2024 um 17:11 Uhr

7 Kommentare

Neuester Kommentar

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

TL DR; “a signed long is not big enough for a 6 digit date + 4 digits time or serial number”.

So for those of us who are too young to remember the Y2K scare, welcome to “Y2K22”!

The “long” data type allows for values up to 2,147,483,647. It appears that Microsoft uses the first two numbers of > > the update version to denote the year of the update. So when the year was 2021, the first two numbers were “21”, > > and everything was fine. Now that it’s 2022 (GMT), the update version, converted to a “long” would be 2,201,01,001 - > - which is above the maximum value of the “long” data type. @microsoft: If you change it to an ‘unsigned long’, then > the max value is 4,294,967,295 and we’ll be able to sleep easy until the year 2043!

Set-MalwareFilteringServer -BypassFiltering $True -identity <SERVER>

oder

& $env:ExchangeInstallPath\Scripts\Disable-Antimalwarescanning.ps1

und den Transport Dienst neu starten hilft.

Frohes Neues!

Mahlzeit - und frohes neues Jahr!

"Dumme" Fleißarbeit direkt am ersten Tag des neuen Jahres.

Ich hoffe, das ist kein Omen...

./Disable-AntimalwareScanning.ps1
net stop msexchangetransport
net start msexchangetransport
Get-Queue

Get-Queue

sollte bestenfalls (ein paar Minuten nach dem Neustart des Transportdienstes) eine "0" zurückliefern. Und dann ist der Spuk auch vorüber, vorerst.

Mal schauen, wann wir das AntimalwareScanning dann wieder aktivieren "dürfen"...

Cheers,
jsysde

Gleiches Problem mit Exchange 2019 CU 11, Disable Malware-Agent und Neustarten des Transportdienstes hat geholfen.

Zum Glück bin ich grad noch hier online gekommen, wollte jetzt dann mit Ausbauen und Entstaubens des Servers beginnen. Sonst wär ich erstmal im Blindflug geflogen was nun aufgrund meiner Tätigkeiten das Problem der nicht zuzustellenden Mails verursacht hätte.

Vielen Dank an den Thread

Bei einem Kunden mit Exchange 2012 - CU kA gleiches Problem. Habs ebenfalls mit dem PS Befehl behoben. Sollte man aber dann wohl im Auge behalten.

Letzte Mail kam um 01:15 Uhr an. Danach war Feierabend