Hallo zusammen,
ich habe in meiner Testumgebung (MSDNAA Lizensiert), welche ich auch Privat produktiv verwende, ein Problem feststellen müssen.
Ich rede hier von 5 Benutzern mit 0815 Mailverkehr 2 – 5 Mails am Tag.
Exchange 2019 CU10 auf CU12 aktualisiert und anschließend den Sicherheitspatch von 05/2022 installiert.
Jetzt musste ich feststellen das Outlook extrem Lange braucht, sowohl von intern als auch von extern.
Egal welches Endgerät mit Outlook.
Smartphones funktionieren schnell wie gewohnt.
Öffnen von Outlook dauert wenige Minuten, zwischen Postfächern in Outlook Browsen dauert mehrere Sekunden, teilweise meldet Windows das Outlook nicht reagiert.
AMSI hatte ich testweise deaktiviert, ändert hier nichts.
Besonderheit ist das ich ADFS für OWA und ECP verwende, das dürfte aber nicht das Problem sein.
Virenscanner ist der Windows Defender.
Meine gesamte Umgebung ist Stand 22.05.2022 gepatcht.
Eventlogs sagen nichts aus.
Ich weiß von einem Kollegen, das es wohl auch einen Kunden von uns betrifft, welcher Letze Woche das Update eingespielt hat.
In Punkto Performance war das System immer normal.
Die CPU last des Exchange Servers ist während des Problems bei ca. 2 – 5% , RAM ca. 35% ausgelastet, Festplattenwarteschlange liegt bei 0,01 – 0,05.
DB Größe 9GB
Workaround:
was derzeit Abhilfe bringt ist MAPIoverHTTP global zu deaktivieren und auf RPCoverHTTP umzustellen, leider muss jedes Postfach nach der Umstellung in Outlook neu eingebunden werden.
Ich gehe davon aus dass das Problem bei MAPIoverHTTP bei Kerberos liegt, in Outlook sehe ich das Latenzen von HTTP und Negotiate bei ~2 Sekunden liegt, mit RPCoverHTTP und NTLM liegt sie bei 16ms.
Ich hatte das Mai-Update für den DC im Verdacht, das habe ich aber Deinstalliert und hat auch nichts geändert.
Hi,
habe annähernd dasselbe Setup für meine Testumgebung. Ich kann derzeit nichts negatives zu den Reaktionszeiten sagen.
Ebenfalls habe ich CU12 drauf, alle relevanten Sicherheitsupdates und bei meinen DC's das problematische WU mit dem Kerberos Problem nicht installiert.
Ansonsten alles soweit aktuell gepatched. Beim in/externen Zugriff per MAPIoverHTTP sehe ich keine Performanceprobleme.
Umgebung hat ebenfalls komplett eingerichtete ADFS Anbindung und die relevanten URL's für Exchange sind per Sophos Reverse veröffentlicht
Gruß,
Ralf
leider muss jedes Postfach nach der Umstellung in Outlook neu eingebunden werden.
Warum? Einfach warten, die stellen sich doch automatisch um. Dauert halt ein bisschen.
@stardust Derzeit noch nicht, ich warte den Nächsten Patchday ab und versuche es dann rückgängig zu machen.
@NorbertFe Maybe ;D nicht so der Geduldige ;), aber klingt einleuchtend!
Statusupdate folgt nach Patchday!
Entweder per Client wie du oben schreibst, dann kannst du es pro User steuern, oder global per set-organizationconfig (dann kannst du es aber nicht mehr steuern) oder per set-casmailbox -MapiHttpEnabled (letzteres geht afair nur bei Exchange 2019)
MS Support Agent mit dem wir aktuell zusammenarbeiten erklärt.
Der hätte dir das aber auch eigentlich erklären können müssen. ;)
Hallo,
wir haben auf einem Exchange 2016 seit CU23 das gleiche Problem (und haben den gleichen Workaround - Mapi aus, RPC an - gefunden). Haben dazu beim Microsoft Professional Support ein Ticket laufen. Supporter konnte in erster Sitzung nichts finden und will Logfiles analysieren.
@rudi: Steht bei Dir in den IIS Bindungen mehr als http und https drin? Das war das einzige was er im Vergleich mit seinem Testlab als auffällig sehen konnte. Wenn ich das mit anderen Exchange-Installationen vergleiche hat er recht.
Er hat das allerdings als nicht entscheident eingestuft, da die Einträge auch vor CU23 nicht da waren. Ich habe noch nicht getestet…
Zufällig bin ich gerade auf den Thread gestoßen. Subjektiv gefühlt seit Mai, dem letzten Sicherheitsupdate für Exchange, ist Outlook 2019 als auch 365 in Verbindung mit Exchange 2013 extrem langsam. Der Abgleich von freigegebenen Postfächern dauert extrem lange. Die Responsetime liegt immer zwischen 2000-3500 ms.
Google konnte zum der Thematik nichts passendes finden. Wenn ich die Antworten lese scheint es mir ein grundsätzliches Problem mit dem letzten Sicherheitsupdate auf allen Versionen zu geben.
Hallo zusammen,
nach dem Patchday im August 2022 habe ich alle Updates auf allen Systemen inklusive des aktuelle Exchange Update eingespielt.
Anschließend habe ich MAPIOverHTTP Domänenweit aktiv gesetzt und musste leider feststellen das das Problem immer noch besteht.
Sobald Outlook via HTTP mit negotiate verbunden ist, klettert die ø Reaktionszeit auf 1000 - 2000 ms.
Hallo zusammen,
gibt es hier mittlerweile neue Infos? Problem besteht bei uns im Februar 2023, voll durch gepatched immernoch..
Grüße
@rk1992 Von meiner Seite gibt es noch nichts neues, Problem besteht weiterhin!
Könntest du etwas zu eurer Umgebung sagen?
z.B. WAP + ADFS im Einsatz, welche Exchange Version?
Hi,
wir nutzen seit August Exchange 2019, Patchstand von letzter Woche. Die Kommunikation zu den Exchanges läuft über Citrix ADC, intern wie extern.
Den Workaround RPC anstatt MAPI zu nutzen haben wir auch bereits getestet, funktioniert. Sehe ich nur nicht ganz als Dauerlösung.
Entweder per Client wie du oben schreibst, dann kannst du es pro User steuern, oder global per set-organizationconfig (dann kannst du es aber nicht mehr steuern) oder per set-casmailbox -MapiHttpEnabled (letzteres geht afair nur bei Exchange 2019)
MS Support Agent mit dem wir aktuell zusammenarbeiten erklärt.
Der hätte dir das aber auch eigentlich erklären können müssen. ;)
Wie kann ich denn die Clients/User von MAPI auf RPC umstellen, ohne die ganze Organisation umzustellen?
Steht doch im Zitat drin. Per set-casmailbox
Zwischenzeitlich sind wir auf Exchange Server 2019 umgestiegen. Direkt nach Umstellung zeigt sich dort genau das selbe Problem. Im Outlook Verbindungsstatus ist eine Latenz von 2000 bis 8000 ms ersichtlich.
Im httpproxy Log zeigen sich diese Werte auch durchgehend. Nachdem wir mehr als eine Woche mit Fehlerdiagnose verbracht haben und mit dem Latein am Ende sind, ist seit Dienstag (09.01.) der Microsoft Support involviert.
Leider kann man bislang nichts gutes darüber berichten. Man schilderte den Fall sehr ausgiebig, beschrieb die gesamte Konfiguration und bislang getesteten Lösungen. Mindestens ein Mal am Tag wird ein neuer Supportmitarbeiter zugewiesen und fängt wieder von vorne an. Am dritten Tag wurde man dann gefragt welche Exchange Version denn im Einsatz sei. Offenbar macht sich absolut niemand die Mühe das Supportticket zu lesen, geschweige denn nachzudenken. So eine miese Unterstützung hätte ich nun wahrlich nicht erwartet.
Habt ihr zwischenzeitlich eine Lösung gefunden? Bei keinem unserer Kunden tritt das Phänomen auf.