[English]Kurze Umfrage an die Administratoren unter der Leserschaft, die eine Microsoft Exchange On-Premises Installation unter Windows Server 2019 betreiben. Habt ihr nach der Installation des Juli 2022 Update Leistungsprobleme mit Microsoft Exchange festgestellt? Mir liegt der Hinweis eines Blog-Lesers vor, der das Sicherheitsupdate wieder deinstallieren musste.
Anzeige
Windows Update KB5015811
Das kumulative Update KB5015811 wurde zum 12. Juli 2022 von Microsoft für Windows 10 Enterprise 2019 LTSC sowie Windows Server 2019 LTSC freigegeben. Mit dem Patch wurden Sicherheitslücken beseitigt und ein PowerShell-Problem behoben. Microsoft hat nicht sehr viele Informationen zu diesem Update veröffentlicht (siehe auch Patchday: Windows 10-Updates (12. Juli 2022)). Wer sich für die Details der Fixes interessiert, findet eher im kumulativen Preview-Update KB5014669 Antworten. Denn unter der Haube wurden eine Reihe Probleme gepatcht.
Probleme mit Microsoft Exchange
In einer privaten Nachricht hat mich Blog-Leser Wolfgang P. auf Facebook kontaktiert. Er betreibt seine Exchange Server 2019 als DAG (Database Availability Group), ist aber nach dem July 2022-Patchday in böse Probleme gelaufen. Wolfgang schrieb mir folgendes:
Servus Günter,
vielleicht könntest du mal ein Auge drauf werfen:
Meine Exchange 2019 DAG hat nach Installation von KB5015811 einen massiven Performanceverlust erlitten. Das Weiterleiten von z.B. 3 MB großen Mails wurde mit einem Pop-Up "Outlook versucht Daten vom Server abzurufen" quittiert. Der Vorgang wurde dann zwar erfolgreich abgeschlossen, dauerte aber rund 3 Minuten.
Auf allen Knoten das besagte KB deinstalliert und es läuft wieder normal. Da ich bisher keine Posts dazu gefunden habe frage ich mich, ob es nur mir so erging?
Dass die Deinstallation des Juli 2022-Updates KB5015811 dieses Leistungsproblem beseitigt, ist ein deutlicher Hinweis, dass es mit den Patches zusammen hängt. Die Frage in die Runde ist, ob jemand etwas gleichartiges festgestellt hat?
Ähnliche Artikel:
Microsoft Office Updates (5. Juli 2022)
Microsoft Security Update Summary (12. Juli 2022)
Patchday: Windows 10-Updates (12. Juli 2022)
Patchday: Windows 11/Server 2022-Updates (12. Juli 2022)
Windows 7/Server 2008R2; Windows 8.1/Server 2012R2: Updates (12. Juli 2022)
Patchday: Microsoft Office Updates (12. Juli 2022)
Microsoft Patchday-Nachlese Juli 2022 (Windows, Office)
Anzeige
Anzeige
Bei uns ist alles klar, allerdings beziehen wir Updates über WSUS.
"… wurde zum 12. August 2022 von Microsoft für Windows 10 Enterprise 2019 LTSC …"
sollte wohl
"… wurde zum 12. Juli 2022 von Microsoft für Windows 10 Enterprise 2019 LTSC …"
heißen.
Ja, ich lebe halt kräftig in der Zukunft, um so was zeitnah (vor Veröffentlichung der Patches) hier im Blog bereits thematisieren zu können ;-).
keine Performanceverluste.
Hallo, ich erinnere mich, dass die AMSI Schittstelle Probleme mit Outlook verursacht. Könnte das auch an der AMSI Schnittstelle liegen? die kann man abschalten.
Bei uns ist kein deratiges Problem erkannt worden. Würde aber ebenso den Tipp geben, sich vielleicht näher mit Outlook zu beschäftigen.
Interessant wäre zu wissen, ob es ebenso auftritt wenn allein OWA genutzt wird? Je nach Outlook Variante (2019, 2021, O365, etc.) gibt es durchaus einige Stolperfallen, die nach meiner Erinnerung her recht ähnliche Phänomene auslösen können.
Keine Probleme hier. Allerdings nutzen wir den OnPremise-Exchange vorwiegend zum Managen des Exchange365 und nicht wirklich hybrid.
Wir haben bei uns exakt das selbe Problem. Beim Löschen und Verschieben von E-Mails massiv zu beobachten, ebenso beim Versand, insbesondere aber auch beim Zugriff auf freigegebene Kalender. Je Größer ein Element zu sein scheint, desto stärke fallen die Verzögerungen aus. Subjektiv ist das Problem nach dem letzten CU Sicherheitsupdate und den danach veröffentlichten Office-Updates aufgetreten. In Verdacht haben wir eher ein Office-Update. Die Ursache konnten wir bisher aber nicht weiter eingrenzen. Kunden sind bislang nicht betroffen, einzig wir selbst. Es tritt sowohl mit Office 2019 als auch Office 365 auf.
Das Update KB5015811 ist bei uns nicht installiert, also nicht die Ursache dafür.
Moin,
spielt bei der Konfiguration ReFS mit rein?
Ich habe gerade das Problem, dass ein Server 2019 Hyper-V-Host, den ich letztes Wochenende gepatcht habe, eine grottenlangsame (teils unter 1 MB/s) Performance bei Crystal Disk Mark auf dem ReFS-Laufwerk zeigt.
Dieses Problem hatte ich vorher schon mal, das war aber nach Umstellung des Volumens von der alten ReFS-Version 1.2 auf Version 3.4 scheinbar Geschichte. Und nun erhebt dieses Problem anscheinend wieder sein hässliches Haupt.
Möglicherweise besteht ja hier ein Zusammenhang. Ich sehe das Phänomen bislang allerdings nur auf einem HPE Proliant ML 350 Gen 9, nicht auf einem Gen 10.
Das Hyper-V Volume ist hier mit NTFS formatiert.
Der interessante Teil: Während der Deinstallation des Updates sprang die Performance plötzlich wieder hoch in den grünen Bereich (Faktor 100 und mehr bei der Lese- und Schreibperformance). Nach dem Neustart hingegen schleppte sich der Zugriff hingegen wieder im zweistelligen und niedrigeren MB-Bereich dahin. Letztlich habe ich die VMs vom Laufwerk evakuiert (da auf einem anderen Server glücklicherweise noch ausreichend Speicherplatz frei war), das Volumen mit NTFS überformatiert und die VMs dann zurückkopiert. (Live-Migration funktionierte mit verschiedenen diffusen Fehlermeldungen nicht.) Seither noch keine Performanceprobleme auf dem Volumen oder in den VMs.
Ich kann das Update KB5015811 gar nicht auf den Windows Servern 2019 installieren.
Bricht beim Windows Update (über WSUS gezogen) immer wieder mit allgemeinen Fehler ab. Die manuelle Installation mit dem File vom Update Catalogue schlägt auch fehl.
Ich habe mit KB5015811 und Hyper-V das Problem, dass eine Ubuntu-VM (20.04 LTS) auf welcher EVCC (Steuerung für Wallbox) läuft nicht mehr mit der Wallbox kommunizieren kann. Die Verbindung läuft von der VM zur Wallbox über UDP. Fehler "Recv timeout". Wenn ich das Update deinstalliere läuft alles wieder. Hab das Update ein zweites Mal installiert/deinstalliert mit dem selben Ergebnis.
Hi you can apply this to netplan
tcp-segmentation-offload: false
tcp6-segmentation-offload: false
receive-checksum-offload: false
transmit-checksum-offload: false
generic-segmentation-offload: false
generic-receive-offload: false
large-receive-offload: false
or for try
ethtool –offload eth0 rx off tx off
but it is bug of Windows i dont find another solution for now
Ergänzung: Von einem Blog-Leser kam auf Facebook noch folgender Kommentar, der eine mögliche Ursache benennt.
Welcher Job ist das genau (namentlich) auf den gewartet werden muss?
Nach dem Update KB5015811 kann ich in einer VM unter Hyper-V in dieser VM keine UPD Pakete mehr empfangen. Die VM ist ein getoo Linux.
Nur die Deinstallation löst das Problem.
Ich kann das Problem bestätigen. Exchange 2019 CU 11.
Das gleiche hier mit UDP-Kommunikation zu einer VM unter SuSE SLES 15.
Wir haben hier massive Probleme mit KB5015811 auf Servern, bei denen viele Powershell-Scripte laufen.
Gerade heute ist uns deshalb ein Monitoringserver an den Anschlag gefahren und hat volle CPU-Last mit Powershell produziert.
Nach Deinstallation des KB läuft wieder alles normal.
Nicht gerade Bezug zu Exchange, aber auf jeden Fall sehe ich ein Zusammenhang mit Powershell die auch im Exchange relevant ist.