Exchange Year 2022 Problem: FIP-FS Scan Engine failed to load – Can’t Convert “2201010001” to long (1.1.2022)

[English]Kurzer Hinweis an die Administratoren im Dienst, deren On-Premises Exchange Server gerade streiken und die FIP-FS Scan Engine (Virenscanner) nicht laden können, und einen Fehler Can't Convert "2201010001" to long  melden. Ihr seid wohl nicht allein, zum 1.1.2022 scheinen wohl einige Exchange Server zu mucken. Es gibt wohl ein Exchange Year 2022 Problem. Hier ein schneller Überblick, was Sache ist.


Anzeige

Virenscanner FIP-FS

FIP-FS ist wohl der Anti-Malware-Virenscanner, der seit Exchange Server 2013 an Bord ist. Dieser soll die On-Premises Exchange Server-Installation auf schädliche Inhalte überprüfen. Allerdings scheint diese Anti-Malware Scan Engine häufiger Probleme zu bereiten. Frank Zöchling hat bereits im Oktober 2016 den Beitrag Exchange 2016: FIPFS Event ID 6027 Filter Updates werden nicht runtergeladen veröffentlicht, der auf zahlreiche Fehlermöglichkeiten beim Aktualisieren der Signaturdateien hinweist.

Und Anfang Dezember 2021 hat jemand auf serverfault.com den Eintrag Exchange 2019 Antimalware engine updates download but don't get applied gepostet. Dort erzeugt die FIP-FS  MS Filtering Engine permanent Einträge in der Ereignisanzeige, weil Updates nicht installiert werden konnten. Es hat wohl verschiedene Exchange-Versionen getroffen und dürfte mit Downloads von Updates oder Virensignaturen zu tun haben. Dort wurde der Fehler durch Microsoft wohl korrigiert.

FIP-FS-Fehler Can't Convert "2201010001" to long

Ich bin gerade auf Twitter durch einen Follower auf nachfolgenden Tweet aufmerksam gemacht worden, der das Problem, welches seit dem 1. Januar 2022 auftritt, in aller Kürze beschreibt.

Exchange: FIPS Scan Engine failed to load - Can't Convert

Unter Exchange kann die Microsoft Scan Engine FIP-FS nicht geladen werden. Stattdessen wird der Fehler Can't Convert "2201010001" to long gemeldet. In Folge-Tweets meldet sich ein weiterer Nutzer mit dem Namen Joseph Roosen:

Umm ya having issues with no mailflow because of this since that keeps crashing over and over since 0000 UTC.
Dear we have a problem with hybrid since this service keeps crashing so basically mail is down.
@MSFTExchange @Microsoft @MSFT365Status

Passt also, der Exchange lässt keine Mails mehr durch. Und über Facebook hat mich jemand auf diesen Tweet von Joseph Roosen hingewiesen, der das etwas im Kontext beleuchtet:

Passt aktuell wohl: Pünktlich zum Jahreswechsel streikt der Virenscanner bei Exchange Server und jagt Administratoren einen Schrecken ein. Bei Microsoft gibt es seit März 2021 den Beitrag The FIP-FS Scan Process failed initialization. Error: 0x80010105 AND Faulting application name: scanningprocess.exe, der sich auf Exchange Server 2016 auf Windows Server 2016 bezieht. Dort gibt es den aktuellen Eintrag vom 1.1.2022:


Anzeige

The exchange server was stuck with this error:

The FIP-FS "Microsoft" Scan Engine failed to load. PID: 39268, Error Code: 0x80004005. Error Description: Can't convert "2201010003" to long. / Event ID 5300

I have disabled filtering:

Set-MalwareFilteringServer exch-19 -BypassFiltering $true

and email is going agian … and I am looking for more info how to recover malware scanning service

FYI
happy new year exchnage

Da scheinen also einige Exchange-Server betroffen zu sein.

Workaround: Anti Malware-Agent deaktivieren

Der Betroffene aus obigem Tweet hat inzwischen über Twitter eine sehr einfache Lösung gepostet. Er hat den Anti Malware-Agenten auf dem Exchange Server deaktiviert.

Exchange fix

Dazu gibt es das Script Disable-AntiMalwareScanning.ps1. Dann werden zwar keine Malware-Scans mehr ausgeführt – aber die Mails lassen sich wieder versenden und zustellen. Noch jemand, der von dieser Neujahrsüberraschung betroffen ist.

Ergänzung: Blog-Leser Marcus S. hat auf Facebook darauf hingewiesen, dass der PowerShell-Befehl:

Get-TransportAgent "Malware Agent" | Disable-TransportAgent

auch funktioniert und die Mails wieder durchkommen. Ergänzung: Microsoft hat im Dokument Disable or bypass anti-malware scanning einige Erläuterungen zum Thema zusammen getragen.

Ergänzung 2: Microsoft hat das Ganze bestätigt und arbeitet an einem Fix (siehe Microsoft bestätigt Exchange Year 2022 Problem FIP-FS Scan Engine failed to load (1. Jan. 2022)).

Ergänzung 3: Es gibt einen temporären Fix, siehe Temporärer Fix für Exchange Year 2022 Problem FIP-FS Scan Engine failed to load (1. Jan. 2022)

Ähnliche Artikel:
Exchange-Server 0-day-Exploits werden aktiv ausgenutzt, patchen!
Wichtige Hinweise Microsofts und des BSI zum Exchange-Server Sicherheitsupdate (März 2021)
Exchange-Probleme mit ECP/OWA-Suche nach Sicherheitsupdate (März 2021)
Microsoft MSERT hilft bei Exchange-Server-Scans
Exchange-Hack: Neue Patches und neue Erkenntnisse
Anatomie des ProxyLogon Hafinum-Exchange Server Hacks
Exchange-Hack: Neue Opfer, neue Patches, neue Angriffe
Neues zur ProxyLogon-Hafnium-Exchange-Problematik (12.3.2021)
Gab es beim Exchange-Massenhack ein Leck bei Microsoft?
ProxyLogon-Hack: Repository für betroffene Exchange-Administratoren
Microsoft Exchange (On-Premises) one-click Mitigation Tool (EOMT) freigegeben
Sicherheitsupdate für Exchange Server 2013 Service Pack 1 – Neue CUs für Exchange 2019 und 2016 (16.3.2021)
Microsoft Defender schließt automatisch CVE-2021-26855 auf Exchange Server
Exchange ProxyLogon News: Patch-Stand, neue Ransomware etc. (25.3.2021)
Neues zum Exchange-Hack: Wie schaut es mit dem Risiko aus? (1. April 2021)
Vorwarnung: 0-Day-Schwachstellen, ist das nächste Exchange-Drama im Anrollen?
Sicherheitsupdates für Exchange Server (Juli 2021)
Kumulative Exchange Updates Juni 2021 veröffentlicht
Exchange Server Security Update KB5001779 (13. April 2021)
Exchange-Schwachstellen: Droht Hafnium II?
Exchange Server: Neues zu den ProxyShell-Schwachstellen
Angriffe auf Exchange Server per ProxyShell-Schwachstelle rollen an (13.8.2021)
Angriffswelle, fast 2.000 Exchange-Server über ProxyShell gehackt
ProxyShell, ProxyLogon und Microsofts Exchange-Doku für Ausnahmen vom Virenschutz
Exchange und ProxyShell: Neues von Microsoft und Sicherheitsspezialisten
Tianfu Cup 2021: Exchange 2019 und iPhone gehackt
Babuk-Gang nutzt ProxyShell-Schwachstelle in Exchange für Ransomware-Angriffe
Exchange Server November 2021 Sicherheitsupdates schließen RCE-Schwachstelle CVE-2021-423
BSI/CERT-Warnung: Kompromittierte Exchange-Server werden für E-Mail-Angriffe missbraucht (Nov. 2021)
Warnung (CERT-Bund, USA, GB) vor Angriffen auf Exchange und Fortinet
ProxyNoShell: Mandiant warnt vor neuen Angriffsmethoden auf Exchange-Server (Nov. 2021)
Warnung: ProxyShell, Squirrelwaffle und ein PoC-Exploit, patcht endlich eure Exchange-Server
CERT-Bund-Warnung: 30% der deutschen Exchange Server mit offenem OWA angreifbar
Beispiele für Viren-Mails nach Übernahme eines Exchange-Servers


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Anzeige


Dieser Beitrag wurde unter Problemlösung, Software abgelegt und mit Exchange, Problem verschlagwortet. Setze ein Lesezeichen auf den Permalink.

65 Antworten zu Exchange Year 2022 Problem: FIP-FS Scan Engine failed to load – Can’t Convert “2201010001” to long (1.1.2022)

  1. Stefan A. sagt:

    Wir sind auch betroffen!

    Aber was komisch ist, nicht alle Server haben das Problem.
    Wir setzen Exchange 2016 in zwei Firmen ein.

    Bei einem Standort hat die Fehlermeldung nach einer Stunde wie von Geisterhand von alleine aufgehört.
    Am anderen Standort bin ich gerade dabei den Workaround umzusetzen, in der Hoffnung, danach fließen die Mails wieder.

    Unterschied wäre hier, dass der betroffene Standort auf CU22 ist und derjenige, wo es nach einer Stunde aufhörte noch auf CU21 ist.

    Ich gebe Bescheid, wenn der Workaround bei uns auch geklappt hat!

  2. Helmut sagt:

    Hi, wir haben auch 2 Server. Danke für den Artikel!

  3. Jens Diedrich sagt:

    Hallo,
    auch wir haben das Problem, haben aber nur einen Exchange 2016 laufen und der ist gerade erst vor einigen Tagen auf CU22 aktualisiert worden.
    Ich denke das ist ein Problem von CU22

    Gruß

  4. Stefan seidl sagt:

    Unser ex19 unter w2019 inkl. Aller Updates steht auch.
    Er nimmt zwar Mails an (Empfänger bekommt kein NDR) aber sie werden nicht an den User zugestellt. Argh.

  5. Markus N. sagt:

    Super, vielen Dank. Bei uns hat nur der Workaround geholfen. Wir haben alle Server auf dem aktuellen Patch-Stand.

  6. Gero sagt:

    Guten Morgen und ein "gutes" neues ;)

    wir sind auch betroffen. Aber trotz das der Dienst nicht läuft bisher keine Probleme beim versenden und empfangen. Exchange 2016 mit aktuellem CU22.

    Ich beobachte das und behalte auch den Tread hier im Auge. ;)

  7. Dirk. E. sagt:

    Unser Exchange Server 2013 war auch betroffen. Die (temporäre?) Lösung war das Abschalten der Scan Engine mit "Set-MalwareFilteringServer exch-19 -BypassFiltering $true" und ein Neustart des Transportdienstes. Nun gehen die Mails wieder durch.

  8. Jonathan sagt:

    Frohes neues Jahr euch allen.
    Jemand in der Facebook Gruppe hatte es gepostet. Exchange auf der Arbeit getestet und die Emails sind nicht durchgegangen. Logs sind voll mit dem Fehler. Workaround ausgeführt und es scheint bis jetzt zu funktionieren.

  9. Richard sagt:

    Hallo,

    hier hat es auch geklappt, nach Neustart des Transportdienstes ruhig mal ein zwei Minuten Geduld haben, die Mails kommen dann durcheinander rein/raus.

    Grüße

  10. Michael Trefz sagt:

    Wir sind leider auch betroffen.
    Die Scan-Engine auszuschalten ist für mich aber nicht der richtige Weg.
    Habt ihr noch andere Ideen?

  11. Florian Winkelried sagt:

    Hat schon jemand versuch einen Case zu eröffnen? Der Workaround ist ja nicht wirklich ideal.

  12. MüllerHeinrich sagt:

    frohes neues zusammen

    Wir sind auch betroffen. Ich hab den Agent deaktiviert, vor dem Exchange wird aber auch schon sehr gut gefiltert … Mails laufen wieder normal und die Warteschlange ist wieder leer …

  13. Helmut sagt:

    https://www.reddit.com/r/sysadmin/comments/rt91z6/exchange_2019_antimalware_bad_update/
    The "long" 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 was "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!

    • Thor sagt:

      Wie geil ist denn bitte DAS!
      Damit hat M$ ja schon den Bug des Jahres Award gewonnen. Was sind da denn für Programmierer unterwegs?

      Zum Glück werde ich 2043 schon in Rente sein. :)

      Frohes neues Jahr!

  14. Wolfgang sagt:

    Ja, vielen Dank für die Workaround!

  15. Helmut sagt:

    Since a couple of minutes Microsoft released Engine 1.1.1880.4 and Sig. 1.355.1224.0 which is working like a charm.

    MS Filtering Engine Update process has successfully committed and handed off updates for MicrosoftLast Checked:2022-01-01T08:30:23ZLast Updated:2022-01-01T08:30:39ZEngine Version:1.1.18800.4Signature Version:"1.355.1224.0"Update Version:2201010004Last Definition Update:?2022?-?01?-?01T01:03:32.000ZUpdate Path:http://amupdatedl.microsoft.com/server/amupdate

    • florian Winkelried sagt:

      wie kann ich den Update manuell anstupsen und kontrollieren ob es die Signatur beinhaltet?

    • florian Winkelried sagt:

      Zum selber überprüfen:
      Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell
      Get-EngineUpdateInformation
      & $env:ExchangeInstallPath\Scripts\Update-MalwareFilteringServer.ps1 -Identity servername
      Get-EngineUpdateInformation

      • Oswald sagt:

        Das kann ich leider nicht bestätigen. Sowohl Engine als auch Signatur haben bei uns die angegebenen Versionen. Trotzdem ist der Workaround mit Disable-AntimalwareScanning.ps1 erforderlich.

    • MOM20xx sagt:

      funktioniert nicht zumindest nicht hier. selbst mit der version heisst es:

      The FIP-FS "Microsoft" Scan Engine failed to load. PID: 20452, Error Code: 0x80004005. Error Description: Can't convert "2201010005" to long.

    • Stefan A. sagt:

      Gibt es hierzu im Anwendungslog eine ID oder Quelle, wo ich nachschauen kann, dass er die Engine und die Signatur erfolgreich gezogen hat?

      Grüße
      Stefan

    • Nicki sagt:

      Ich habe ebenfalls ausprobiert ob das Update den gewünschten Effekt bringt. Zunächst sah alles gut aus, dann habe ich mittels Set-MalwareFilteringServer -BypassFiltering $false und anschliessendem Neustart des Services getestet und bin wieder auf die gleichen Problem wie in der Nacht gestossen. Also werden wir erstmal weiter abwarten.

  16. Bernhard sagt:

    Hallo,

    auf unseren Exchange Servern (2016 + 2019) hat der Workaround ebenfalls geholfen.

  17. Julien sagt:

    Auch wir sind davon betroffen.

    Der beschriebene Workaround scheint zu funktionieren.

    Im Anschluss noch ggf. den TransportService durchstarten

  18. Jesper L. sagt:

    Hallo,
    wir nutzen einen Exchange 2016 (On-Premise) und waren auch betroffen. Der Befehl .\Disable-AntiMalwareScanning.ps1 , ausgeführt in einer Exchange-Management-Shell hat das Problem gelöst. Kann also bestätigt werden. Hinweis: Einzelne Mails scheinen nach auftreten und vor Ausführung des Work-Arounds dennoch durchgegangen zu sein gemäß unserer Logfiles. Aber wirklich nur wenige einzelne.
    Nach dem Deaktivieren des Anti-Malware-Scans liesen sich jedoch die Dienste nicht neu starten und der gesamte Exchange musste neu gestartet werden. Seitdem läuft alles.

  19. MOM20xx sagt:

    exchange server 2016 cu 22. natürlich betroffen. nach dem Ausführen von Disable-AntiMalwareScanning.ps1 auf beiden Servern. wird die Queue wieder verarbeitet.

    Ich gehe mal recht in der Annahme, dass man mit einem Enable-AntiMawareScanning.ps1 im selben Verzeichnis das Scanning wieder aktivieren kann, sowie MS einen fix geliefert.

  20. Robert sagt:

    Ich habe langsam die Nase voll von diesen Amateur-Codern… – das Jahr fängt ja schon wieder besch*ssen an :(
    Euch allen ein 'Gesundes Neues Jahr' !!

  21. Olli sagt:

    1x Ex2016 auf Win 2016 -> Betroffen!
    1x Ex2013 auf Win 2012R2 -> Nicht betroffen!
    1x Ex2019 auf Win 2019 -> Nicht betroffen!

  22. Urban sagt:

    Wenn man jetzt ein Malware Versender wäre, dann wäre das wohl die perfekte Welle, der perfekte Tag…

  23. Tobias sagt:

    Exchange 2016 CU20: Betroffen, aber Mailzustellung funktioniert weiterhin.

  24. Mike sagt:

    8 Exchange Server (2016 und 2019) in Verwaltung, davon 4 Betroffen (2×2016, 2×2019).
    Alle auf dem letzten CU.

    Danke für den Workaround :-)

  25. Stefan A. sagt:

    Also der Workaround: Anti Malware-Agent deaktivieren hat bei uns auch geholfen.

    Ich kann bisher nur noch nicht nachvollziehen, warum 2 von 3 Servern den Fehler hatten und bei einem Server der Fehler nach 1 Stunde von alleine verschwunden ist.

    Das versuche ich noch zu verstehen…

  26. MOM20xx sagt:

    der workaround ist zwar gut und schön. mails kommen aber damit verzögert an, weil bei jeder mail das fips dingens erstmal in ein timeout läuft. sehr schön zu sehen im mailheader. derzeit 1-3 minuten bei uns

    bspw.

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

    obwohl die queues leer sind

  27. weda sagt:

    das probelm hat nichts mit der CU-version zu tun, sondern ob der ANTIMALWARE-AGENT überhaupt bei der installation aktiviert wurde.
    ist das nicht der fall, spielt es (natürlich) keine rolle für die zustellung der mails ob der service läuft oder nicht.
    wir haben bei allen unseren exchange den anti-spam bereits bei der installation deaktiviert – brauchen wir auch nicht den agent, da enweder UTM davor oder was von FORTI.

    zum abschalten folgendes nutzen:
    prüfen ob der agent aktiv ist -> Get-TransportAgent -> ergebnis könnte so aussehen ->
    Identity Enabled Priority
    ——– ——- ——–
    Content Filter Agent True 1
    Sender Id Agent True 2
    Sender Filter Agent True 3
    Recipient Filter Agent True 4
    Protocol Analysis Agent True 5
    Transport Rule Agent True 6
    DLP Policy Agent True 7
    Retention Policy Agent True 8
    Supervisory Review Agent True 9
    Malware Agent True 10
    Text Messaging Routing Agent True 11
    Text Messaging Delivery Agent True 12
    System Probe Drop Smtp Agent True 13
    System Probe Drop Routing Agent True 14

    exchange-shell als admin starten ->
    & $env:ExchangeInstallPath\Scripts\Disable-AntimalwareScanning.ps1

    anschliessend den transport-service neu starten ->
    Restart-Service MSExchangeTransport

    fertig :)
    erneute prüfung der agents sollte nun folgendes ergeben ->
    Identity Enabled Priority
    ——– ——- ——–
    Content Filter Agent True 1
    Sender Id Agent True 2
    Sender Filter Agent True 3
    Recipient Filter Agent True 4
    Protocol Analysis Agent True 5
    Transport Rule Agent True 6
    DLP Policy Agent True 7
    Retention Policy Agent True 8
    Supervisory Review Agent True 9
    Malware Agent False 10
    Text Messaging Routing Agent True 11
    Text Messaging Delivery Agent True 12
    System Probe Drop Smtp Agent True 13
    System Probe Drop Routing Agent True 14

    • Sören sagt:

      Danke für deinen hilfreichen Kommentar. Hat mir geholfen.

      Ich habe mir gerade einmal das "Disable-AntimalwareScanning.ps1" Script angeschaut. Es gibt in dem Script den Parameter "ForceRestart".

      Habe eben "& $env:ExchangeInstallPath\Scripts\Disable-AntimalwareScanning.ps1 -ForceRestart" probiert, hat super funktioniert :)

      Man kann also mit dem oben geschriebenen Befehl sowohl "Disable-AntimalwareScanning" als auch "Restart-Service MSExchangeTransport" zusammen ausführen.

      ("ForceRestart" bedeutet in dem Script nicht, dass "Restart-Service MSExchangeTransport" mit "Force" ausgeführt wird, sondern nur, dass der Befehl überhaupt ausgeführt wird.

  28. Hausmeister sagt:

    Komisch, wir setzen einen 2016er ein mit allen CUs und updates aber hier geht noch alles…

    • Oswald sagt:

      Vielleicht hattet ihr früher schon einmal ein Problem wie z.B. hier beschrieben https://www.frankysweb.de/exchange-2016-verzeichnis-transportrolesdatatempunifiedcontent-muellt-festplatte-zu und daher den Workaround bereits durchgeführt. Das Problem mit dem gestoppten Microsoft Filtering Management Service sollte aber trotzdem seit heute auftreten.

      • RS sagt:

        > Das Problem mit dem gestoppten Microsoft Filtering Management Service sollte aber trotzdem seit heute auftreten.

        Wo finde ich dazu mehr?

        • Oswald sagt:

          Im Zweifel mit "Get-Service FMS". Der Dienst sollte automatisch starten, ist aber gestoppt. Im Eventlog (System) finden sich seit heute Events mit der ID 7034 und dem Text "The Microsoft Filtering Management Service service terminated unexpectedly. It has done this 3 time(s)." Ein manueller Start per "Start-Service FMS" löst das Problem leider nur für eine gewisse Zeit. Dieses Verhalten tritt auch trotz Aktivierung des Workarounds auf.

          • RS sagt:

            Das ist schon klar und habe ich ebenfalls falls beobachtet.
            Meine Frage zielte auf die Ursache und auf dessen Behebung nach Deaktivierung des AntiMalware Agents ab.

          • martin sagt:

            Hi ist bei mir ähnlich, dienste wurde nach 3 maligen start beendet und der malware agent steht aber auf false. muss hier der workaround auch durchgeführt werden? bzw sollte ich den dienst auf deaktiviert setzen?

          • Oswald sagt:

            >>> Meine Frage zielte auf die Ursache und auf dessen Behebung nach Deaktivierung des AntiMalware Agents ab.

            Das kann ich leider aktuell nicht beantworten. Da aber zumindest hier ein- sowie ausgehende Nachrichten verarbeitet werden, ein externes Gateway auf Viren/Malware/Spam prüft und durch Microsoft ein zeitnaher Patch in Aussicht gestellt wurde, werden wir mit dem gestoppten Dienst leben.

  29. Smid sagt:

    Danke. Hat geholfen!

  30. Frank W. sagt:

    Danke, das hat mir den Tag gerettet!

  31. Marius Titz sagt:

    Super vielen Dank für den Hinweis. Notbesetzung von unserer Firma hat mich angerufen, dass keine Emails mehr reinkommen. Habe zwei Stunden gebraucht bis ich hier die Lösung gefunden habe, jetzt läuft wieder alles. Vielen, vielen Dank und ein gutes neue Jahr wünsch ich euch.

  32. Paul sagt:

    Shit halpens.
    Wer auf die "geniale" Idee gekommen gekommen ist, eine 16 stellige BCD-Zahl in einem long abzulegen und zu verarbeiten, war immerhin so schlau, die Eingangswerte zu prüfen. Das letzte ist ja im Prinzip guter Stil: "traue keinen Daten die von außen kommen blind" Sonst hätte es ja nicht diese klare Fehlermeldung gegeben.

    Aber:
    Wie kann so etwas durch das Testbed von Microsoft durchkommen?
    Ich habe irgendwie das Gefühl dss Mikrosoft diese – zeitaufwendigen und teuren Tests seit ein paar Jahren gewaltig spart oder keine Leute mehr zusammen bekommt, die das Testbed beherrschen, weil einfach zu kompliziert geworden.

    Was heißt das? MS scheint ausgeblutet, satt zu sein, daran können wir nichts ändern.
    Aber unsere Rechner müssen laufen.
    Muß ich als Administrator also "mein" Testbed auf virtualen Kisten laufen lassen?
    (Scheint aber niemand zu machen, oder? Sonst hätte MS den Fehler ja schon in der Betaphase behoben.)
    So etwas nannten wir früher "Bananen software" "Reift beim Kunden" (der sich dank Monopol nicht mehr wehren kann)

  33. Paul sagt:

    Schade das man nicht den Code sehen kann…
    Früher gab es mal Compiler die im "if" alles nach "int" gecastrr hat, ausser man rs explzit selbst im "if" als unsigmed gecastet…das geht dann lange Zeit gut.
    Moderne Compiler warnen…

  34. Harry sagt:

    Spricht etwas gegen ein temporäres Abschalten der automatischen Engine Updates und Rollback auf die letzte funktionierende Version?

    Hier beschrieben: https://blog.markdepalma.com/?p=810
    Hier das Script: https://github.com/markdepalma/MSExchangeFIPFSBug

  35. Gero sagt:

    Es gibt einen Fix von MS:
    https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-transport-queues/ba-p/3049447

    Script lief bei mir relativ lange. So ca. 20 Minuten.

    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 :/

    • DW sagt:

      @Gero
      > Fehlt das nur bei mir oder noch bei jemandem?
      Das fehlt nicht. Es ist Bestandteil eines anderen SnapIn:
      Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell

      Danach kannst du das cmdlet "Get-EngineUpdateInformation" ausführen.

    • bernd sagt:

      "Restart-Service FMS -Force" dann geht es. wir hatten das gleiche problem

  36. Gero sagt:

    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.

  37. Paul sagt:

    Fehlermeldung :
    Can't Convert "2201010001" to long (1.1.2022))

    Em, das deutet darauf fhin, daß der Programmierer davon ausging, das 'long' schon ein 'unsigend int64' sein wird… Weil ja das Betriebssystem 64bit hat…?
    Aua. Anfängerfehler.

    • Christian Wimmer sagt:

      Da hat jemand halt gedacht das ist schick mit der Jahreszahl ganz vorne und nicht daran gedacht das da irgendwann ein Datentyp voll läuft. Ging ja jetzt viele Jahre gut und dann ist 2022 und … booooom!

  38. Christian Wimmer sagt:

    Das Powershell Skript hat bei uns getan. Allerdings scheiterte es am Neustart der Dienste. Ich habe die Kiste dann mal durchgestartet und seitdem flutschen die Mails wieder. Naja, bis auf ein Maillimit bei ausgehenden Mails in das wir jetzt gelaufen sind – aber auch das sollte dann in den nächsten abgebaut werden.

    Auch eine Art langsam Exchange on-prem zu killen. Die Fehler werden echt immer blöder.

  39. Dirk Schmiedeke sagt:

    Danke für die Hilfe
    Haben einen Exchange 2019 CU11
    ab 1.1.2022 kein Mailtransport mehr zum Clinet / Owa/activ Sync

    Get-TransportAgent "Malware Agent" | Disable-TransportAgent

    und die Mails kommen wieder an

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.