Exchange Server: „Die Nachricht wurde vom Kategorisierungs-Agent zurückgestellt“

Zum Jahreswechsel gibt es direkt ein Problem mit der Mailzustellung auf Exchange Servern. Mails bleiben in der Warteschlange mit der folgenden Meldung hängen:

„Die Nachricht wurde vom Kategorisierungs-Agent zurückgestellt“

Mails werden weder gesendet, noch empfangen. Dieses Problem tritt seit dem 01.01.2022 auf allen Exchange 2016 / 2019 Servern und wird vom Transport Agent „Malware Agent“ verursacht. Mit dem folgenden Befehl lässt sich prüfen, ob der Malware Agent gestartet ist:

Get-TransportAgent
Kategorisierungs-Agent

Steht der „Malware Agent“ auf „True“ bleiben die Mails in der Warteschlange hängen. Als Workaround kann das Antimalware Feature der Exchange Server abgeschaltet werden, bis Microsoft ein entsprechendes Update liefert. Mit dem folgenden Script kann das Antimalware Feature abgeschaltet werden:

cd $exscripts
.\Disable-AntimalwareScanning.ps1
Get-Service MSExchangeTransport | Restart-Service
Disable-AntimalwareScanning.ps1

Im Prinzip handelt es sich bei diesem Fehler um den „Jahr 2000“ Bug des Exchange Servern, nur eben 22 Jahr später. Ursache ist, dass Microsoft versucht hat ein Datum als Integer zu speichern, mit dem Jahreswechsel ist nun die Zahl aber zu groß und passt nicht mehr in ein Integer, etwa so:

Jahr 2022 Bug

Nachvollziehen lässt sich dieser Fehler im Eventlog, hier taucht das Event 5300 (Quelle: FIPFS) auf:

Can't convert "2201010005" to long.

Dieses Problem bringt den Malware Agent aus dem Tritt und die Mails verbleiben in der Warteschlange. Dieses Problem ist zugegebenermaßen etwas ungünstig, so an Neujahr… Auch dürften recht viele von dem Problem betroffen sein, denn das AntiMalware Feature ist in der Standardeinstellung aktiviert.

Exchange Admins sollten also am besten heute noch kurz die Einstellungen auf den Servern kontrollieren und den Workaround umsetzen, damit die Mails wieder zugestellt werden.

Frohes Neues und herzlichen Dank an Firma Microsoft an dieser Stelle…

Update: Auf dem Exchange Team Blog wurde eine Bestätigung des Fehlers veröffentlicht. In der Meldung heißt es, dass ein Fix für das Problem in Entwicklung ist, aber noch mehrere Tage bis zur Fertigstellung benötigt. Solange muss man sich also mit dem Workaround behelfen. Hier der Link zum Beitrag auf dem Exchange Team Blog:

Der Workaround sollte übrigens noch dieses Wochenende umgesetzt werden, da Exchange die Mails nach 48 Stunden aus den Warteschlangen löscht und einen Unzustellbarkeitsbericht versendet. Wer also sicherstellen will, dass alle Mails ankommen, kann nicht bis Montag warten.

Update: In dem oben verlinken Artikel hat Microsoft nun auch ein Script veröffentlicht, welches das Problem behebt. Nachdem das Script ausgeführt wurde, kann das AntiMalware Feature mit dem folgenden Befehl wieder aktiviert werden:

cd $exscripts
.\Enable-AntimalwareScanning.ps1

Nachdem der Fix von Microsoft angewendet wurde, muss der Server neu gestartet werden.

103 Gedanken zu „Exchange Server: „Die Nachricht wurde vom Kategorisierungs-Agent zurückgestellt““

  1. Frohes Neues 2022!

    Kann ich so nicht bestätigen.
    2x Exch2016 15.01.2375.017 (DAG)

    AntimalwareAgent = active
    Mailzustellung in-extern klappt

    Antworten
    • Ebenso frohes neues 2022 allen.

      @Marc: schließe mich an, auch hier EXC16 mit 15.01.2375.12 (DAG)

      AntimalwareAgent –> Enabled True und Mailzustellung in/out funktioniert

      Antworten
        • Ich hatte das Problem auch nur auf Systemen mit Exchange 2019 auf Server 2019

          Ex2016 in der neusten Version 2375.17 war kein Problem

        • Hier 6 x 2016 Enterprise, 1 DAG, 15.01.2375.017, Agent aktiv, Queues leer, keine FIPFS-Fehler.

        • Ich habe 2 Exchange 2016er Installationen. Eine auf Server 2012 (war betroffen), eine auf Server 2019 (funktionierte). Beider Version 2375.17, allerdings zeigt get-exchangeserver beharrlich die 2375.7 an. Erst das Healthchecker Script zeigt 2375.17 (normal?).

          Jedenfalls funktionieren jetzt beide wieder. Vielen Dank für die Informationen und natürlich ein frohes neues Jahr. Mal schauen mit was uns MS im Jahr 2022 überrascht :-)

  2. problem auf windows server 2016 + exchange server 2016 cu22 (2x als DAG) present. workaround durchgeführt.
    mails werden wieder zugestellt.
    jedoch selbst wenn queues leer sind haben neue mails minutenlange verzögerungen.

    Bspw:

    Bspw.

    X-MS-Exchange-Transport-EndToEndLatency: 00:03:01.5496629

    Normal haben wir als beispiel:

    X-MS-Exchange-Transport-EndToEndLatency: 00:00:00.3882958

    Antworten
    • Selbes Problem hier. Auch immer irgendwas mit drei Minuten.
      Allerdings auch nur der Maileingang. Der Versand geht wie gewohnt schnell.

      Antworten
    • Hast du eine Transportregel, die auf Dateianhänge bzw. deren Erweiterung filtert? Genau das war bei mir das Problem. Ich hab die Regel deaktiviert und seitdem keine Verzögerung mehr.

      Hier gibt es wohl Abhängigkeiten zum Malwarefilter, denn die Regel hat auch wenn sie aktiviert war, nicht mehr funktioniert,.

      Antworten
  3. Danke für die Info und alles Gute für 2022!
    Bei uns waren übrigens ausschliesslich 2019er Server betroffen, die 2016er nicht, hier war der antimalware agent nicht aktiv.

    Antworten
  4. Hallo zusammen,

    lieber Frank dir und der ganzen Community hier ein erfolgreiches und gesundes neues Jahr!

    Ja, und vielen herzlichen Dank für Deine Info und die erste Beschäftigung im neuen Jahr!

    Viele Grüße

    Marcus

    Antworten
  5. Vielen Dank und ein frohes, glückliches und gesundes neues Jahr.
    Auf dass es nicht so weitergeht wie es angefangen hat.
    Bei uns waren beide 2019er betroffen.

    Antworten
  6. Bei mir startet regelmäßig der Dienst „Microsoft-Filterverwaltungsdienst“ neu der mit der FMS.exe scheinbar auch für das Antimaleware-Scanning zuständig ist. Seit 02:15 heute Nacht
    Ich deaktiviere auch gerade das Scanning und schaue das ob es das gleiche Problem ist.

    Antworten
  7. Hallo Frank, hallo an alle anderen – Und Happy New Year. Oder wie es Microsoft nennt: The FIP-FS „Microsoft“ Scan Engine failed to load

    Ja, der Workaround scheint zu funktionieren. Dennoch ist das eben „nur“ ein Workaround und keine echte Lösung. So sieht es zumindest einer unserer Kunden. Der hat die Sorge, dass er sich damit andere Sicherheitslöcher aufreißen könnte.

    Wir haben Microsoft kontaktiert und warten seit Stunden darauf, dass sich ein Techniker erbarmt.

    Antworten
  8. Vielen Vielen Dank. Wieder einmal eine Hilfe, wenn sie gebraucht wurde. Wünsche Allen und Natürlich Frank ein gutes und fröhliches 2022

    Antworten
  9. Hallo Zusammen und mal wieder ein „super“ Start ins 2022 :-)

    Wir haben „nur“ das MalwareFiltering auf den Exchangeservern temp. deaktiviert und nach Restart der Dienste kommen die Emails wieder durch.
    Zur ergänzenden Info:
    Set-MalwareFilteringServer -BypassFiltering $true

    (Ex2019 DAG auf W2019Core)

    Antworten
  10. Hallo Frank und vielen Dank für den Beitrag. Auch hier waren die Warteschlangen voll (Exchange 2019 CU11). WorkAraound hat geholfen. Mal schauen was als Nächstes kommt. Allen ein gesundes und erfolgreiches neues Jahr 2022.

    Antworten
  11. Hallo Frank,

    Du rettest hier praktisch leben ;-)
    Vielen, vielen Dank für die Nachricht. Habe den Workaround gerade eben bei unseren Exchange Umgebungen gemacht.
    Das wäre ein Spaß am Montag geworden ohne Deine Info.

    Weiterhin schönen Feiertag.

    Antworten
  12. eine Frage noch an alle:

    nachdem der Workaround angewandt wurde ist bei euch auch das FMS Service gestoppt bzw. wird als gestoppt und rot im Server Manager angezeigt?

    Antworten
  13. Danke für den rettenden Artikel. Es gab im Dezember bereits tagelang Probleme mit dem Scan Engine Update. Und jetzt das! Bypass reicht aus, der FMS Dienst dreht allerdings etwas durch mit dauernden Neustarts. Der 3 min. Delay ist weg, wenn man Transportregeln deaktiviert, die nach Anlagen filtern, wie Dominik erwähnte. Ein Freudenfest für Ransomware. Danke Microsoft.

    Antworten
  14. Hallo Frank,
    ich wünsche Dir ein frohes neues Jahr 2022!
    Vielen Dank für Deine tatkräftige Unterstützung im vergangenen Jahr und schon gleich wieder im Jahr 2022.
    Viele Grüße

    Antworten
  15. Hallo Frank,
    ich wünsche dir auch ein frohes neues Jahr 2022!
    Vielen herzlichen Dank für Deine Info und für den Einsatz im neuen Jahr!

    Viele liebe Grüße,
    Celine

    Antworten
  16. Neujahrstag am Abend – Geschäftsführer schreibt Mail, ob wir auch betroffen sind. Ich lese es zufällig, hab ja frei…
    Gleich gecheckt – Testmail von extern ging gleich durch

    Dann noch auf den Server und gecheckt.

    Bei uns trat es nicht auf.
    Exchange 2013 CU23 (15.0 , 1497.2) – zuletzt alles up2date

    [PS] C:\Windows\system32>get-transportagent
    Identity Enabled Priority
    ——– ——- ——–
    Transport Rule Agent True 1
    Malware Agent False 2

    Antworten
  17. Dürfte Exchange 2010 nicht betreffen, habe gerade bei unserem letzten Kunden mit Exchange 2010 reingesehen, den hätte ich so gerne bis Montag warten lassen, damit er endlich umsteigt, aber nix da, Mailfluss läuft…

    Antworten
  18. Hallo Zusammen,

    wieder einmal hat mir dieses Forum komplett den Hintern gerettet! :-) Von demher vielen vielen Dank an Frank für diesen Beitrag! Was gibt es schrägeres, wenn man genau zum 01.01. eines Jahres (wo man sich endlich mal auf 3-4 Tage Pause freut) keine Mails mehr auf sämtlichen Postfächern weder senden, noch empfangen kann. Und der Exchange „erstmal“ gar nicht so ausschaut als würde was nicht passen… hätte mir fast den Urlaub versaut! :-) Workaround hat komplett funktioniert bei mir.

    Ein frohes neues Jahr noch an alle

    LG, Andy

    Antworten
  19. Ein frohes neues Jahr wünsche ich Dir Frank!
    Danke Dir, unser Exchange 2016 war auch betroffen.
    Der Workaround hat funktioniert, wie immer vielen Dank für Deinen Hinweis :-)

    Antworten
  20. Script lief bei mir relativ lange. So ca. 20 Minuten.
    https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-transport-queues/ba-p/3049447
    Allerdings gibt es bei mir das Get-EngineUpdateInformation Script nicht im Ordner so wie beschrieben.
    Fehlt das nur bei mir oder noch bei jemandem?

    Danach habe ich den Malware Agent mit .\Enable-AntimalwareScanning.ps1 wieder aktiviert und Transportdienst neu gestartet.

    Testmails gehen leider immer noch nicht durch und im Eventlog kommt weiterhin FIPFS mit ID 2203 :/

    Antworten
    • möglicherweise sollte das antimalware scannen vorm fix aktiviert werden. damit du get-engineupdateinformation ausführen kannst musst in der powershell noch

      Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell

      aufrufen

      Antworten
    • selber fehler hier auf exchange 2016 cu22.

      somit fix wieder rückgängig machen und engine deaktivieren. testet das auch wer bei microsoft? oder testet der kunde erste die lösungen?

      Antworten
  21. Wenn dann der offizielle Patch draussen ist, kann man den Malware-Scanner wieder mit „.\Enable-AntimalwareScanning.ps1“ aktivieren, oder?

    Antworten
  22. Update:
    Nach Neustart des ganzen Servers, also nicht nur Transportdienst, scheint es jetzt wieder zu funktionieren. Keine FIPFS Meldungen mehr im Eventlog und Testmails gingen auch durch.

    Antworten
  23. auf der bereits verlinkten MS-Seite gibt’s eine Aktualisierung. Das Deaktivieren des Scanners ist nicht mehr nötig.

    – Update-Script von https://aka.ms/ResetScanEngineVersion laden uns (i.d.R.) nach C:\Program Files\Microsoft\Exchange Server\V15\Scripts entpacken
    – .\Reset-ScanEngineVersion.ps1
    – Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell.
    – Get-EngineUpdateInformation

    das Script endete beim Update mit einem Fehler. Daher direkt im Anschluss
    – .\Update-MalwareFilteringServer.ps1
    Eigentlich soll man den FQDN nutzen, da kommt aber der bereits bekannte Fehler. Daher nur den Hostnamen ohne Domain. Dann geht’s.

    Antworten
  24. Ist der Email-Eingang noch bei jemandem total verzögert?
    Der Patch „Reset-ScanEngineVersion.ps1“ wurde durchgeführt, das AntimalwareScanning wieder aktiviert, Server neu gestartet.
    Ausgehende Emails kommen sofort an, eingehende haben ca. 15 Minuen Verzögerung.

    Antworten
  25. Super, Danke Frank für die schnelle Lösung!
    Ohne Dich wäre es morgen zu einem Chaos gekommen!
    Gruß und ein erfolgreiches, gesundes Neues Jahr – mach weiter so !

    Antworten
  26. Hallo, ich habe nun auch den Fix von Microsoft durchgeführt. Das schein auch soweit zu gehen. Die Ereignisanzeige zeigt auch keine FIPFS Fehler mehr an und Mails werden zugestellt und lassen sich verschicken.

    Engine : Microsoft
    LastChecked : 01.02.2022 08:13:53 +01:00
    LastUpdated : 01.02.2022 07:10:22 +01:00
    EngineVersion : 1.1.18800.4
    SignatureVersion : 1.355.1227.0
    SignatureDateTime : 01.01.2022 12:29:06 +01:00
    UpdateVersion : 2112330001
    UpdateStatus : UpdateAttemptNoUpdate

    Identity Enabled Priority
    ——– ——- ——–
    Transport Rule Agent True 1
    DLP Policy Agent True 2
    Retention Policy Agent True 3
    Supervisory Review Agent True 4
    Malware Agent True 5
    Text Messaging Routing Agent True 6
    Text Messaging Delivery Agent True 7
    System Probe Drop Smtp Agent True 8
    System Probe Drop Routing Agent True 9

    Ich hatte allerdings ein kleines Problem, wo ich zwecks Sicherheit kurz Eure Hilfe bräuchte: Ich hatte folgende Meldung:

    Die Ausführungsrichtlinien wurden von Windows PowerShell erfolgreich aktualisiert, die Einstellung wird jedoch von einer in einem spezielleren Bereich definierten Richtlinie überschrieben. Aufgrund der Überschreibung wird die aktuelle geltende Ausführungsrichtlinie „RemoteSigned“ für die Shell beibehalten. Geben Sie „Get-ExecutionPolicy -List“ ein, um die Ausführungsrichtlinieneinstellungen anzuzeigen. Weitere Informationen erhalten Sie mit „Get-Help Set-ExecutionPolicy“.

    Daraufhin habe ich temporär unter Benutzerkonfiguration (Computerkonfiguration) –> Administrative Vorlagen –> Windows Komponenten –> Windows PowerShell: Skriptausführung aktivieren ein gpupdate durchgeführt (danach wieder rückgängig gemacht) und in der Registry den Eintrag HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell den Schlüssel „ExecutionPolicy“ gelöscht. Danach ging es. Nur ist leider jetzt in der Regitry gar kein Eintrag mehr für die PowerShell und ich bin mir nicht sicher ob ich jetzt die Powershell irgendwie „unsicher“ gemacht habe… Mit Get-ExecutionPolicy -List bekomme ich Folgendes angezeigt (Sah vorher auch so aus):

    Scope ExecutionPolicy
    —– —————
    MachinePolicy Undefined
    UserPolicy Undefined
    Process Undefined
    CurrentUser Undefined
    LocalMachine RemoteSigned

    Ist das soweit ok ? Hat das Auswirkungen dass der Regitry Eintrag nicht mehr vorhanden ist ?

    LG, Andy

    Antworten
  27. Gesundes neues, hat bei von euch schon jemand die Erfahrung gemacht ob der Fehler nur mit dem 01.01.2022 zu tun hat oder kann ich heute am 03.01.2022 den Schutz wieder aktivieren?

    Antworten
  28. Bei mir (Exchange 2019, neuste Updates installiert) schmeißt er folgenden Fehler:

    Verbindung mit *SERVERNAME* wird hergestellt.
    C:\Program Files\Microsoft\Exchange Server\V15\Scripts\Update-MalwareFilteringServer.ps1 : Fehler beim Starten des Updates für das Antischadsoftware-Modul.
    In C:\Program Files\Microsoft\Exchange Server\V15\Scripts\Reset-ScanEngineVersion.ps1:78 Zeichen:13
    + & $updateScriptPath $fqdn
    + ~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Update-MalwareFilteringServer.ps1

    ——–

    Probiere es vorerst mit dem Deaktivieren…

    Antworten
      • Danke für die Rückmeldung, aber der Fehler kommt aus einer Administrator-Shell.

        Ein Prüfen der UpdateInformation ergab folgendes:

        PS C:\Program Files\Microsoft\Exchange Server\V15\Scripts> Get-EngineUpdateInformation
        Engine : Microsoft
        LastChecked : 01.03.2022 09:44:13 +01:00
        LastUpdated : 01.01.2022 05:57:02 +01:00
        EngineVersion : 1.1.18800.4
        SignatureVersion : 1.355.1247.0
        SignatureDateTime : 01.01.2022 12:29:06 +01:00
        UpdateVersion : 2201010009
        UpdateStatus : UpdateAttemptFailed

        Antworten
        • Hi,

          bei mir (Exchange 2016 – aktuelle Updates) genau das gleiche Problem. Hab dann mal die manuelle Lösung versucht, da hängts dann bei mir beim Ausführen des Update-Scripts:

          E:\Exchange\scripts>.\Update-MalwareFilteringServer.ps1
          Wird als „*DOMAIN*\administrator“ ausgeführt.
          ——–
          Verbindung mit „“ wird hergestellt.
          E:\Exchange\scripts\Update-MalwareFilteringServer.ps1 : Fehler beim Starten des Updates für das
          Antischadsoftware-Modul.
          In Zeile:1 Zeichen:1
          + .\Update-MalwareFilteringServer.ps1
          + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
          + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Update-MalwareFilteringServer.ps1

        • Ich hab aktuell anscheinend das gleiche Problem. Die Manuelle Lösung funktioniert ebenso nicht. Jemand schon die Lösung gefunden? ;)

          Verbindung mit „**.de“ wird hergestellt.
          C:\Program Files\Microsoft\Exchange Server\V15\Scripts\Update-MalwareFilteringServer.ps1 : Fehler beim Starten des
          Updates für das Antischadsoftware-Modul.
          In C:\Program Files\Microsoft\Exchange Server\V15\scripts\Reset-ScanEngineVersion.ps1:101 Zeichen:13
          + & $updateScriptPath @p
          + ~~~~~~~~~~~~~~~~~~~~~~
          + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
          + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Update-MalwareFilteringServer.ps1

        • Ich bin in der Techcommunity in einem Beitrag von GRauth auf eine mögliche Lösung gestoßen.

          Exchange Management Shell öffnen, dann:

          Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell
          Start-EngineUpdate -Verbose

          Daraufhin sollte
          AUSFÜHRLICH: [11:21:51.626 GMT] Start-EngineUpdate : Beginning processing
          AUSFÜHRLICH: [11:21:52.238 GMT] Start-EngineUpdate : Initiating engine update for the following engines: Microsoft
          AUSFÜHRLICH: [11:21:52.507 GMT] Start-EngineUpdate : Ending processing
          erscheinen.

          Get-EngineUpdateInformation

          Engine : Microsoft
          LastChecked : 01.03.2022 07:08:54 +01:00
          LastUpdated : 01.03.2022 07:09:10 +01:00
          EngineVersion : 1.1.18800.4
          SignatureVersion : 1.355.1227.0
          SignatureDateTime : 01.01.2022 12:29:06 +01:00
          UpdateVersion : 2112330003
          UpdateStatus : UpdateAttemptSuccessful

          Ich werde dann außerhalb der Geschäftszeiten den Malware-Agent wieder aktivieren und testen, ob es klappt.

        • Hi, ich setze mal hier an, da ich „Schmand“ nicht direkt antworten kann. Vielleicht ist die Frage nach zwei Wochen ja doch noch aktuell. Wir hatten in einer Umgebung dieselbe Fehlermeldung bezüglich „& $updateScriptPath @p“ beim Ausführen des Skriptes reset-scanengeingversion.ps1. Wir haben uns durch Microsoft helfen lassen. Die Kollegen mussten selbst etwas tüffteln. Hier die Schritte zum manuellen Beheben:

          Exchange-Powershell als Administrator starten. Folgende 3 Befehle absetzen (im 2. Befehl Servername anpassen)

          Add-PSSnapin -Name Microsoft.Forefront.Filtering.Management.PowerShell
          $EngineUpdatePath = Get-MalwareFilteringServer -Identity servername.lokal | Select-Object -ExpandProperty PrimaryUpdatePath
          Start-EngineUpdate -UpdatePath $EngineUpdatePath

          1 Sunde warten, dann mit Get-EngineUpdateInformation UpdateVersion abfragen, muss mit 21… beginnen.

          Danach war zumindest bei uns die Version aktuell. Allerdings funktionierte die Mailzustellung dann immer noch nicht und die Warteschlangen wurden nach dem aktivieren des Malwarefilters wieder voll.

          Letztendlich mussten wir den Server in den Maintenance Mode schalten. Danach folgende Befehl absetzen:
          enable-transportagent „Malware agent“
          Danach den Server durchstarten und den Server wieder aus dem Maintenance Mode nehmen.

          Dies war tatsächlich erfolgreich … der Mailtransport funktioniert wieder mit aktiviertem Malwareagent.

      • Bei mir hat es bei fast allen Server nur geklappt wenn ich die Zeilen getrennt eingefügt habe:
        Also in der ExchangeShell mit Adminrechten erst folgendes:

        cd $exscripts
        .\Disable-AntimalwareScanning.ps1

        Nach dem das durch war dann den Neustart mit:

        Get-Service MSExchangeTransport | Restart-Service

        Antworten
        • Damit schaltest du die Virenprüfung im Mailflow ab. MS hat inzwischen einen Weg ohne die Deaktivierung geschaffen, den solltest du besser nutzen.

  29. Hallo!
    Ich habe das Update der Engine laut Microsoft manuell durchgeführt. Eine Aktuelle Version wird mir auch angezeigt.

    Engine : Microsoft
    LastChecked : 01.03.2022 12:52:43 +01:00
    LastUpdated : 01.03.2022 12:10:37 +01:00
    EngineVersion : 1.1.18800.4
    SignatureVersion : 1.355.1227.0
    SignatureDateTime : 01.01.2022 12:29:06 +01:00
    UpdateVersion : 2112330003
    UpdateStatus : UpdateAttemptNoUpdate

    Wenn ich jetzt Antimalware Scanning wieder aktiviere, Transportdienst auch neu gestartet. Bleiben die E-Mails dennoch in der Warteschlange mit „Die Nachricht wurde vom Kategorisierungs-Agent zurückgestellt“ .
    Server nochmal komplett durchstarten, bzw. hatte dies so auch jemand?
    Danke und Grüße

    Antworten
  30. Moin,

    vielen Dank für Deine schnelle Reaktion. Grundsätzlich läuft alles wieder, nur fehlen bei uns einige einkommende Nachrichten. Unter MessageTracking kann ich die fehlenden Nachrichten finden, aber am Ende steht EventID fail und Source Queue. Hast Du eine Idee, was mit den Nachrichten passiert sein könnte? Mit Get-Queue ist von den fehlenden Nachrichten nichts zu sehen. Werden die irgendwann in einem Verzeichnis abgelegt? Rückmeldungen hat es nicht gegeben.

    Event Log – Anwendungen:

    Quelle: MSExchange Antimalware
    Ereignis-ID: 3813 / 3811
    The anti-malware agent has deferred a message. MessageId: Message sent: 01.01.2022 15:48:45 From: xxxxxxxx@gmail.com Size: 3984 Times deferred: 5

    Quelle: MSEchange Extensibility
    Ereignis-ID: 1050
    The execution time of agent ‚Malware Agent‘ exceeded 300800 milliseconds while handling event ‚OnSubmittedMessage‘ for message with InternetMessageId: ‚Not Available‘. This is an unusual amount of time for an agent to process a single event. However, Transport will continue processing this message.

    Quelle: FIPFS
    Ereignis-ID: 5300
    The FIP-FS „Microsoft“ Scan Engine failed to load. PID: 5060, Error Code: 0x80004005. Error Description: Can’t convert „2201010009“ to long.

    MfG

    Antworten
  31. Hallo alle zusammen,

    ich habe heute eher durch
    Zufall erfahren dass es einen ’22-Bug geben soll. Mir ist das nicht aufgefallen weil der Versand und Empfang funktionierte. Grund dafür ist allerdings G-Data. Bei der Installation wurde der Agent von MS deaktiviert und ein Hauseigener von G-Data aktiviert. Erst nach einem Blick in die Ereignisanzeige vielen mir 5 Fehler die mit dem Bug zu tun haben auf.

    Ich bin mir nun nicht sicher ob ich den Bug-Fix von MS einspielen kann. Eine Rückinfo von Seiten G-Data steht noch aus.

    Hat jemand Erfahrung mit dem Bug und G-Data, kann ich den Bug-Fix einfach einspielen?

    Gruß
    tomtom

    Antworten
    • Hi tomtom,

      bei uns hat es sich ähnlich dargestellt. MS Agent ist deaktiviert und Mailversand bzw. Empfang lief problemlos. Wir nutzen jedoch Kaspersky und nicht G-Data. Problem bestand bei uns darin, dass der „Microsoft-Filterverwaltungsdienst“ nicht mehr gestartet war und auch nicht gestartet werden konnte. Daraufhin haben wir uns entschieden, das Script durchlaufen zu lassen und den Server neu zu starten, danach war alles wieder ok.

      Gruß
      Sebastian

      Antworten
  32. Problem:

    Hallo Gemeinde, habe heute erfolgreich an die 30 stk Ex2016- und Ex2019-Server aktualisiert per Reset-ScanEngineVersion-Script.

    Einer von ihnen hatte ein anderes Verhalten im Ablauf, was ich leider nicht nachvollziehen kann. Im zweiten Anlauf lief das Script nun durch, jedoch kommt ein Folgeproblem, dass der Port 25 nun nicht mehr vom TransportService geöffnet wird. Port 2525 jedoch schon. Ich bekomme keinerlei Fehlermeldung, warum dies ist. Weiß einer, wie ich das Logging des Dienstes hochsetzen kann, um das Startverhalten zu tracen?

    Probiert hatte ich schon das Deaktivieren einzelner Sender- und Empfangs-Connectoren. Auch die Transport-Agents hatte ich schon deaktiviert. Hat jemand Ideen?

    Danke vorab. Gruß Nico

    Antworten
    • Auch ich habe mit dem Script Reset-ScanEngineVersion. Dann habe ich den Maleware Agent wieder aktivert und den Transportdienst neu gestartet. Danach hingen die mails sofort wieder in der Queue fest.

      Wer hat ein Ähnliches Verhalten feststellen können?

      Antworten
      • Lief das Script denn unauffällig durch?
        Ich hatte eine Hand voll Server, bei denen es im ersten, einmal auch im zweiten Anlauf nicht rund lief. Spätestens ein 3. Aufruf lief dann problemlos.

        Ansonsten würde ich: Serverneustart, warten bis die Systemlast normal ist + anschließend nochmal das Script ausführen.

        Antworten
      • Man könnte hier mal alles lesen und feststellen, dass der reboot im allgemeinen hilft. Der Neustart des transportservices reicht nicht.

        Antworten
  33. Guten Morgen,
    hatte gestern den Malware Agent wie in der Anleitung deaktiviert an meinem Exchange 2016 CU22. Heute Morgen habe ich dann das Reset Script gestartet. Dieses läuft bereits seit 3 Stunden. Ist das normal? Hatte das schon jemand?

    Gruß Carsten

    Antworten
    • Der Download von Engine und Pattern war nicht besonders schnell. Bei allen Servern die ich bearbeitet habe ca. 30+ Minuten. Wenns jetzt evtl. noch langsamer ist, könnte noch alles „normal“ sein. „Bewegt“ sich denn noch was? ;)

      Antworten
      • Würde behaupten es startet nicht. Hab eben den Server nochmal neugestartet und den Vorgang wiederholt. Er sagt immer das das Script nicht vertrauenswürdig ist. Das bestätige ich mit M was für einmal ausführen steht. Danach blinkt darunter nur der Cursor und es passiert nichts weiteres

        Antworten
  34. Hat das Script auch jemand gestartet wo der Exchangeserver nicht nach draussen verbinden kann?
    Bei uns trifft der Fehler dankdessen nicht auf. Aber somit kann sich das Script auch nichts laden.

    Antworten
    • Wenn du den Fehler nicht hast, warum willst du denn das Skript dann ausführen? Irgendwo bei ms ist doch der händische Update Vorgang beschrieben, meine ich.

      Antworten

Schreibe einen Kommentar