[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.
Anzeige
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:
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.
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
Anzeige
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!
Hi, wir haben auch 2 Server. Danke für den Artikel!
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ß
Hallo,
haben noch CU21+Updates, gleiches Fehlerbild.
Gruss
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.
Super, vielen Dank. Bei uns hat nur der Workaround geholfen. Wir haben alle Server auf dem aktuellen Patch-Stand.
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. ;)
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.
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.
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
Wir sind leider auch betroffen.
Die Scan-Engine auszuschalten ist für mich aber nicht der richtige Weg.
Habt ihr noch andere Ideen?
Hat schon jemand versuch einen Case zu eröffnen? Der Workaround ist ja nicht wirklich ideal.
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 …
https://web.archive.org/web/20231126090508/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!
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!
Ja, vielen Dank für die Workaround!
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
wie kann ich den Update manuell anstupsen und kontrollieren ob es die Signatur beinhaltet?
Zum selber überprüfen:
Add-PSSnapin Microsoft.Forefront.Filtering.Management.Powershell
Get-EngineUpdateInformation
& $env:ExchangeInstallPath\Scripts\Update-MalwareFilteringServer.ps1 -Identity servername
Get-EngineUpdateInformation
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.
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.
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
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.
Hallo,
auf unseren Exchange Servern (2016 + 2019) hat der Workaround ebenfalls geholfen.
Auch wir sind davon betroffen.
Der beschriebene Workaround scheint zu funktionieren.
Im Anschluss noch ggf. den TransportService durchstarten
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.
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.
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' !!
1x Ex2016 auf Win 2016 -> Betroffen!
1x Ex2013 auf Win 2012R2 -> Nicht betroffen!
1x Ex2019 auf Win 2019 -> Nicht betroffen!
Danke Olli,
wir sind nicht betroffen. Alles gut und schnurrt.
habt ihr amsi auch deaktiviert?
https://techcommunity.microsoft.com/t5/fasttrack-for-microsoft-365/exchange-server-mail-stuck-on-queue-due-to-cyber-attack-01-01/m-p/3049211
Wenn man jetzt ein Malware Versender wäre, dann wäre das wohl die perfekte Welle, der perfekte Tag…
Exchange 2016 CU20: Betroffen, aber Mailzustellung funktioniert weiterhin.
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 :-)
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…
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
Das kann ich nicht bestätigen. Bei uns gibt es diese Verzögerung trotz aktiviertem Workaround nicht.
Hast du eine Filterregel, die nach Dateianhängen filtert? Bei mir war genau das die Ursache. Ich hab die Regel deaktiviert und seitdem keine Verzögerung mehr. Vielleicht sind da Abhängigkeiten zum Malware scan…
danke das war es.
fms service is bei mir nach anwenden des workarounds gestoppt
Bei uns auch!
Der Dienst steht zwar noch auf automatisch, ist aber nicht gestartet…
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
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.
Komisch, wir setzen einen 2016er ein mit allen CUs und updates aber hier geht noch alles…
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.
> Das Problem mit dem gestoppten Microsoft Filtering Management Service sollte aber trotzdem seit heute auftreten.
Wo finde ich dazu mehr?
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.
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.
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?
>>> 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.
Danke. Hat geholfen!
Danke, das hat mir den Tag gerettet!
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.
Inzwischen hat das Exchange Team einen Blogartikel verfasst:
https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-transport-queues/ba-p/3049447
Danke, ich habe es mal in einem Artikel Microsoft bestätigt Exchange Year 2022 Problem FIP-FS Scan Engine failed to load (1. Jan. 2022)für Sonntag aufgegriffen.
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)
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…
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
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 :/
@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.
"Restart-Service FMS -Force" dann geht es. wir hatten das gleiche problem
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.
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.
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!
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.
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