Y2K22 Bug stoppt Exchange Mailzustellung

Das Jahr 2022 beginnt für alle Exchange Admins mit einer Überraschung: Der Exchange Antimalware Agent hat Probleme mit dem Datum 01.01.2022, so dass ab einer bestimmten Uhrzeit keine Mail mehr zugestellt wurden (Mal sehen, was der 02.02.2022 oder der 22.02.2022 bringen..)
Achtung: Betroffen sind 2016 und 2019 onpremise – auch bei Hybrid Bereitstellungen, die den onpremise Server zur Mailübermittlung verwenden.

https://www.heise.de/news/Y2K22-Bug-stoppt-Exchange-Mailzustellung-Antimalware-Engine-stolpert-ueber-2022-6315605.html

Wir veröffentlichten gestern einen WorkaRound. Nun gibt es ein Update (02.01.2022)

Das Exchange Team hat ein Skript veröffentlicht, das das Problem behebt:
Email Stuck in Transport Queues – Microsoft Tech Community

Das Skript muss auf allen Servern ausgeführt werden. Dabei empfiehlt das Exchange Team mit dem Server mit der längsten Queue (get-queue) zu beginnen. Sie können bei mehreren Server auch parallel vorgehen.
Erste Erfahrung von uns: Geduld ist gefragt!
Mit dem Folgenden aktivieren Sie vorher wieder den AntiMalwareAgent in der Exchange Shell (Empfohlen):

cd $exscripts
.\Enable-AntimalwareScanning.ps1
Restart-Service msExchangeTransport

Den Erfolg des Skripts können Sie kontrollieren, in dem Sie die Submission Queues auf den Servern überprüfen. Sie sollten sich leeren (get-queue).

Sie können natürlich auch den gestern veröffentlichten WorkaRound anwenden:

Abhilfe als WorkaRound

Führen Sie jeden Ihrer Exchange Server das Folgende in der Exchange Shell aus:

Cd $exscripts
.\disable-AntiWareScanning.ps1
Restart-service msExchangeTransport

Es gehen keine eingehende und ausgehende Mail verloren!

Wir konnten noch nicht überprüfen, ob das von Heise erwähnte Signaturupdate den WorkaRound überflüssig macht. Das werden wir schnellstens in der 1. KW 2022 erledigen.

Wenn Sie keine andere AntiSpamösung haben, ist der WorkaRound problematisch, damit AntiMalWare-Überprüfung abgeschaltet wird!

In mindestens einem Fall mussten wir auf allen Server den Dienst msExchangeIS neustarten. Das kann in einer Database Availability Group (DAG) ohne Ausfall erfolgen, indem die Datenbanken auf einem anderen Server in der DAG aktiviert werden und dann der Dienst neugestartet wird. Das ganze wird dann für alle Server in der DAG je einmal durchgeführt. Bevor Sie den Informationsspeicher neu starten, überprüfen Sie jeweils mit get-MailDatabasecopyStatus ob alle Kopien und der Contenindex healthy sind.

In einem anderen Fall war es notwendig, einen Server neuzustarten.

In diesen beiden Fällen lieferte der Befehl

Get-queue –server <Name des Servers>

eine Submission-Queue, die sich nicht abgebaut wurde oder Queues mit dem Namen SmtpDeliverytoMaibox, die ebenfalls nicht abgebaut wurden.

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on pinterest
Pinterest
Share on email
Email
Scroll to Top