[English]Nach der Installation der Sicherheitsupdates vom 14. Februar 2023 gab es im Blog einige Hinweise aus dem Kreis der Administratoren, dass Exchange-Webdienste (EWS) Probleme bereitet. Die Kalenderaktualisierung macht beispielsweise Probleme. Die Deinstallation des Sicherheitsupdates löste das Problem wieder. Ergänzung: Das „revidierte“ Sicherheitsupdate für Exchange Server 2016 CU 23 löst das Problem nicht. Inzwischen hat Microsoft aber den Bug reproduzieren können und einen Workaround veröffentlicht – der aber nur partiell hilft. Daher ein kurzer Überblick über den Sachverhalt – vielleicht können Administratoren aus der Leserschaft da was zu sagen.
EWS-Probleme nach Sicherheitsupdate
Zum 14. Februar 2023 hat Microsoft die Sicherheitsupdates für Exchange 2013 bis 2019 veröffentlich, um verschiedene Sicherheitslücken zu schließen. Ich hatte im Blog-Beitrag Exchange Server Sicherheitsupdates (14. Februar 2023) berichtet. Aus der Leserschaft kamen dann Kommentare über Probleme mit EWS (Exchange-Webdienste). Frank schreibt in diesem Kommentar:
Wenn’s nur das wäre. Die Meldungen mehren sich über EWS Abstürze und den damit verbundenen Problemen.
Auf meinem Ex2016 kann ich das ebenfalls bestätigen.
Serverseitige Suche geht nicht, Addins laden nicht, Terminplanungsassistent oder Kalenderfreigaben die ewig brauchen zum laden…
praktisch alles was auf EWS aufbaut geht nur sporadisch bis gar nicht.
Und Leser Enno ergänzt in diesem Kommentar:
EWS Probleme habe ich auch und wir haben das Update einfach zurück gerollt. Anscheinend hat ein Fix im aktuellen Patch einen Deserialze Problem und landet in einem „Deny“, welcher im Code irgendwo etwas mitigieren soll. So verstehe ich den StackTrace aus dem Event Log mit der ID 1325
Message: Deserialization of type System.MarshalByRefObject blocked due to InDeny at location ClientExtensionCollectionFormatter. […]
Nachdem Blog-Leser Martin mich heute mit folgender Mail kontaktiert hat, habe ich die Hinweise in diesem Blog-Beitrag mal separat herausgezogen.
Hallo Günter,
in den Kommentaren zu deinem Artikel: Exchange Server Sicherheitsupdates (14. Februar 2023) … finden sich inzwischen vermehrt Hinweise, dass es zu EWS-Problemen kommt. Ich kann das aus unserer Umgebung bestätigen:
So ist z.B. auch der Zugriff auf freigegebene Kalender, deren Mailbox auf einem bereits gepatchten System liegt, nicht mehr möglich („Kalender konnte nicht aktualisiert werden“).
Hingegen klappt der Zugriff auf Kalender, deren Mailboxen auf noch ungepatchten Servern liegen, problemlos.
Das nur als Ergänzung, falls du noch einen eigenen Artikel zu dem Thema verfassen magst.
An dieser Stelle mein Dank an die Leser. Ein Benutzer mit dem Alias nak_87 hat im Techcommunity Artikel zu den Sicherheitsupdates ebenfalls einige Kommentare zu Problemen (f ASP.NET (1325) und WAS (5011) Fehler) gepostet.
EventID 5011, WAS
Schwerwiegender Kommunikationsfehler im Windows-Prozessaktivierungsdienst bei einem Prozess für den Anwendungspool „MSExchangeServicesAppPool“. Die Prozess-ID ist „14692“. Das Datenfeld enthält die Fehlernummer.
Die Outlook-Suche funktioniert nicht mehr. „Etwas ist schief gelaufen…“ und „Verbindungsproblem“. Installiert wurde KB5023038-x64-de.exe für Exchange Server 2016. Gibt noch weitere Nutzer, die über EWS-Probleme in den Kommentaren klagen. Nutzer enno0815de schreibt hier:
Hi, we have the same problems with EWS on WinServer2016 (Patchlevel Jan2023) and latest CU for Exchange 2016. All clietns which uses EWS are broken, f.e. Teams, MacMail and Evolution. We rolled the update back as we need EWS. Is there any workaround already available? Regards Enno
Auch hier wird von einem kaputten EWS berichtet. Auch auf reddit.com finden sich solche Berichte. Die Rückkehr zum Januar 2023-Patchstand unter Exchange Server 2016 behebt diese Probleme.
Revisions-Update mit Fix?
In meinem Blog-Beitrag Microsofts Februar 2023-Patchday: Falsche Updates in WSUS, Exchange und Windows habe ich u.a. berichtet, dass Microsoft für Exchange Server veraltete Update-Pakete von Januar 2023 ausgerollt hat. Inzwischen wurde dieser Fehler korrigiert und das neue Update wird installiert. In diesem Kommentar schreibt cram, dass mit dem zweiten Februar 2023-Update für Exchange Server 2016 keine EWS-Probleme mehr auftreten.
Exchange 2016 CU23:
Nach dem zweiten Update ist jetzt wieder alles gut. Die Buildversion ist jetzt 15.01.2507.021. In der Windows Update Historie taucht das Update zwei Mal auf.Ja alles läuft und über Windows Update geladen. ECP und Kalender sind nicht kaputt.
Carsten bestätigt in einer Antwort, dass bei ihm „ECP, OWA, Kalender, Suche, alle auf Exchange 2016 CU23“ funktionieren. Ob die EWS-Probleme damit behoben sind, kann ich nicht endgültig abschätzen. Ergänzung: Nachfolgende Rückmeldungen zeigen, dass das nicht hilft.
Microsoft veröffentlicht Workaround
Microsoft ist sich des EWS-Problems bewusst und konnte es in seinen Labors reproduzieren. Sie haben nun den Abschnitt „Bekannte Probleme“ in diesem Techcommunity-Artikel um den folgenden Text erweitert.
After installation of February 2023 SU, some Exchange 2016 and 2019 customers can see EWS application pool crash with Event ID 4999 with the following error:
E12IIS, c-RTL-AMD64, 15.01.2507.021, w3wp#MSExchangeServicesAppPool, M.Exchange.Diagnostics, M.E.D.ChainedSerializationBinder.EnforceBlockReason, M.E.Diagnostics.BlockedDeserializeTypeException, 437c-dumptidset, 15.01.2507.021.The issue is causing connectivity issues to clients using the EWS protocol. We have a workaround for this (but note that events 4999 might still continue to be logged but functionality should be restored). If you are experiencing this problem, our recommendation is to use the following workaround and keep February SU installed:
1. Create the following regkey in the exchange servers:
SOFTWARE\Microsoft\ExchangeServer\v15\Diagnostics\DisableBaseTypeCheckForDeserializationThe regkey is ‘string value’ type and needs to have a value of 1.
2. Create the below setting override:
- New-SettingOverride -Name „Adding learning location ClientExtensionCollectionFormatter“ -Server <ServerName> -Component Data -Section DeserializationBinderSettings -Parameters @(„LearningLocations=ClientExtensionCollectionFormatter“) -Reason „Deserialization failed“
- Force the application of the setting by running the following:
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart IIS app pools.
Gemäß nachfolgenden Kommentaren hilft der Workaround. Ergänzung 2: Der Workaround hilft nur teilweise. Martin hat mich zum 17.2.2023 per Mail kontaktiert und schreibt folgendes:
Hi Günter,
wir haben den Workaround auch gestern Abend noch bei uns implementiert, scheint aber nur teilweise zu helfen:
Outlook unter Windows funktioniert wieder brav und zeigt auch freigegebene Kalender an, allerdings ist die Suche noch beeinträchtigt.
Bei Outlook unter macOS 13.2.1 Ventura hab ich allerdings alle paar Minuten Disconnects, dann nach ein paar Minuten wieder einen Reconnect –> dann wird auch gesynct und der Zugriff auf Kalender geht ebenso, aber dann reißt die Verbindung auch schon wieder ab. Bei nem Kollegen identisches Verhalten, kann also recht sicher ausschließen, dass es nur meine Maschine/Netzanbindung betrifft.
Die Meldungen zu macOS-Problemen hatte ich vorher im Internet auch schon gelesen.
Ergänzung 3: Microsoft hat inzwischen auch den Support-Beitrag EWS web application pool stops after the February 2023 Security Update is installed mit Informationen und Workarounds veröffentlicht.
Ähnliche Artikel:
Exchange Server Sicherheitsupdates (14. Februar 2023)
Microsofts Februar 2023-Patchday: Falsche Updates in WSUS, Exchange und Windows
Hi Günter,
ich kann leider nicht bestätigen, dass mit dem Revisions-Update eine Besserung einhergeht :-( Eine unserer Kisten ist doppelt gepatcht:
Security Update for Exchange Server 2016 CU3 (KB5023038)
(taucht 2x im Updateverlauf auf: Patch –> Reboot –> Patch –> Reboot)
Problematik leider unverändert, auch identische Fehlermeldungen :-(
In den Kommentaren des Exchange-Team-Blogposts bestätigt nun MS, dass es die EWS-Probleme reproduzieren kann:
„We have reproduced the problem now too. Until the reliable workaround is available, the only way to make this go away is to uninstall the Feb SU temporarily. January SU does not cause this issue.“
Am besten erst gar nicht installieren b.a.W.
Danke für die Ergänzung – muss mir beim durchscrollen durchgerutscht sein, oder war noch nicht drin.
Genau.
Ich habe erst einmal die Meldungen zum SU abgewartet und jetzt nach dem Bekanntwerden der Probleme die Entscheidung getroffen, das Februar-SU nicht zu installieren.
Da das SU Sicherheitslücken schließt, die bisher in freier Wildbahn noch nie ausgenutzt wurden halte ich das Risiko für vertretbar.
achja hab gestern mal bei uns getestet. addons im owa kein problem. so auch keine ews fehler gefunden. könnt vielleicht daran liegen, dass wir die extended protection nicht eingeschaltet haben, da wir move to archive sachen haben und das dort probleme macht
Eine Sache ist mir jetzt doch aufgefallen:
Wir benutzen die CodeTwo Software für Signaturen etc.. Seit dem Update hat das Programm immer wieder Aussetzer beim abarbeiten den Regeln. Es gibt komischweise keinen Fehler, aber ich kann gar klar in den Logs sehen, dass sporadisch Emails einfach nicht behandelt werden. Wenige Minuten später geht wieder alles. Das war vor dem Update nicht der Fall.
Zwei Exchange Server 2016 auf Server 2016 Datacenter, zusammen in einer DAG, Extended Protection ist aktiviert, Server haben keinen Internetaccess, Updates wurden per WSUS installiert:
Sowohl nach dem ersten Patch als auch nach dem aktualisierten Patch haben wir keinerlei der genannten Probleme. Beide Server funktionieren einwandfrei.
Derzeitiger Build nach den beiden Updates: 15.01.2507.021
Es gibt einen temporären Workaround für das EWS-Problem, siehe unter „Known issues with this release“ auf dieser Seite:
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-february-2023-exchange-server-security-updates/ba-p/3741058
Der temporäre Workaround scheint zu funktionieren. Zumindest habe ich seit ~10 Minuten keinen EWS Crash (ASP.NET + WAS) in den Logs und auch die Suche funktionierte auf Anhieb. Später teste ich noch eine Awendung die auf EWS setzt, bin gespannt.
Update: leider kommt der Fehler weiterhin und auch die Suche beendet ihren Dienst.
Update 2: ich hatte einen Tippfehler im Servernamen beim Script. Seit der Korrektur scheint es gut auszusehen. Auch die EWS Anwendung läuft fehlerfrei durch.
Falls es jemanden interessiert: mit folgendem Befehl kann man die Einstellung wieder entfernen:
Remove-SettingOverride -Identity „Adding learning location ClientExtensionCollectionFormatter“
Heute trat beim ersten Kunden folgender Fehler im HealthChecker auf:
Bin Search Folder Not Found
X:\Exchange Server\V15\ClientAccess\ecp\web.config
More Information: https://aka.ms/HC-BinSearchFolder
Die weiterführenden Informationen von Microsoft beziehen sich allesamt auf den Fall, dass das ECP ohne Funktion ist. Das funktioniert jedoch einwandfrei.
Hat jemand die Meldung schon im Zusammenhang mit dem Sicherheitsupdate Februar beobachtet?
Nachtrag: die web.config Datei habe ich mit einem identischen Kunden verglichen, der Inhalt ist 1:1 identisch.
Nachtrag 2: gestern war es noch: Exchange Health Checker version 23.02.14.1742, heute ist es Version 23.02.16.1412. Ist dort ggf. ein Fehler enthalten?
Nachtrag 3: vor ein paar Stunden war es sogar noch Version 23.02.14.1742. Bei der Installation gab es keinen Fehler.
Nachtrag 4: gerade nochmal beim Kunden vor heute Mittag ausgeführt. Fehlermeldung erscheint dort jetzt ebenfalls. Script scheint fehlerhaft zu sein.
Die Meldung „Bin Search Folder Not Found“ taucht bei mir nach der Installation der Updates auch auf (Exchange 2016 CU23), konnte bisher aber keine Probleme feststellen.
Kann ich ebenfalls bestätigen.
Exchange Health Checker in der Version v23.02.16.1810 zeigt diesen Fehler an. Grundsätzlich läuft alles. Im Eventlog gibt es auch keine Fehler.
Die Anzeige haben wohl viele Administratoren. mit dem Ergebnis, dass es trotzdem funktioniert und keine Fehler erkennbar sind. Die Verzeichnisse vom Exchange sind da.
Im Gitrepository wurde bereits eine Anfrage (Issue) von einem Betroffenen erstellt.
https://github.com/microsoft/CSS-Exchange/issues/1506
Der „Fehler“ bzgl des bin Folders kommt bei mir auch. Nachdem alles soweit funktioniert gehe ich ebenfalls von einem Fehler im Scipt aus.
Ich muss doch mal nachfragen wenn ich das alles lese:
Wer installiert denn am ersten Abend M$ Updates in einer Produktivumgebung?
Lebensmüde? :)
Bei 1. soll ich einen Reg Key machen – das habe ich verstanden und bei 2. auch einen Eintrag in der Reg oder einen Befehl per die Power Shell oder Exchange Shell abgeben?
Könnte das jemand mal irgendwie übersetzen?
1. Create the following regkey in the exchange servers:
SOFTWARE\Microsoft\ExchangeServer\v15\Diagnostics\DisableBaseTypeCheckForDeserialization
The regkey is ’string value‘ type and needs to have a value of 1.
2. Create the below setting override:
New-SettingOverride -Name „Adding learning location ClientExtensionCollectionFormatter“ -Server -Component Data -Section DeserializationBinderSettings -Parameters @(„LearningLocations=ClientExtensionCollectionFormatter“) -Reason „Deserialization failed“
Force the application of the setting by running the following:
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart IIS app pools.
So heute Abend mal getraut!
Exchange 2016 CU 23 auf Server 2012 R2.
„SU Februar 2023“ Update installiert über Windows Update.
Extra nochmal neu gesucht, damit er auch das aktuelle Update lädt:
Freigegebene Kalender, Suche usw. funktionieren.
Build Version wird im Health-Checker richtig angezeigt.
alles in Ordnung.. und die Exchange Dienste starten nun wieder automatisch, nach dem „Januar SU 2023“ Update wurden diese ja nicht mehr gestartet.
Hat funktioniert.
Gleiche Umgebung, hat ebenfalls funktioniert.
Stand heute macht das Update immer noch Probleme:
Reproduzierbar fallen DAG dem Update zum Opfer.
Während der Installation des ersten DAG-Mitgliedes bleiben alle Clients verbunden. Nach dessen Neustart und dem Schwenk aller DBs gibt es weiter keine Auffälligkeiten.
Erst wenn der Installer auf dem 2. DAG Mitglied ausgeführt wird und ungefähr 80% erreicht hat, ist EWS auf einmal auch auf dem bereits gepatchten Server kaputt: Er liefert nur weiße Seiten aus. Die Authentifizierung funktioniert noch, sowohl für ECP als auch OWA, aber sonst nichts. Da das Update von hier aus aber auch gerne mal mehr als eine Dreiviertelstunde Stunde braucht, sollten Admins trotz Redundanz durch DAG dieses Update besser außerhalb der Betriebszeiten durchführen.
Dies ist nun die 3. DAG, bei mir dieses Verhalten mit diesem Update begegnet.
Welche Version habt ihr im Einsatz? Unsere beiden DAGs unter 2016 CU23 und Windows Server 2016 laufen tadellos.
Kann es sein dass die Problem immer noch aktuell sind? Wir haben gerade eine Migration zu Exchange 2016 hinter uns und massive Probleme mit EWS
Kann die Probleme noch bestätigen (Windows Server 2022/Exchange 2019 CU 13, letzter Patchstand).
Besonderheit: Wir nutzen einen Virenscanner für Exchange, der wiederum Microsoft Exchange Web Service Managed API erfordert.
Vielleicht ist das die Ursache?
Würde mich auch interessieren, ob man den Workaround wieder entfernen kann. Gibt es hierzu Aussagen?