Outlook mit MAPIove...
 
Benachrichtigungen
Alles löschen

Outlook mit MAPIoverHTTP und Kerberos (Negotiate) extrem Langsam

14 Beiträge
7 Benutzer
1 Likes
3,840 Ansichten
 rudi
(@rudi)
Active Member
Beigetreten: Vor 3 Jahren
Beiträge: 10
Themenstarter  

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.

 


   
Zitat
(@geloeschter-benutzer)
Reputable Member
Beigetreten: Vor 2 Jahren
Beiträge: 263
 

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


   
rudi reacted
AntwortZitat

NorbertFe
(@norbertfe)
Noble Member
Beigetreten: Vor 3 Jahren
Beiträge: 1420
 
Veröffentlicht von: @rudi

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.


   
AntwortZitat
 rudi
(@rudi)
Active Member
Beigetreten: Vor 3 Jahren
Beiträge: 10
Themenstarter  

@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!


   
AntwortZitat

NorbertFe
(@norbertfe)
Noble Member
Beigetreten: Vor 3 Jahren
Beiträge: 1420
 

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)

Veröffentlicht von: @stardust

MS Support Agent mit dem wir aktuell zusammenarbeiten erklärt. 

Der hätte dir das aber auch eigentlich erklären können müssen. ;)


   
AntwortZitat
 mlux
(@mlux)
New Member
Beigetreten: Vor 2 Jahren
Beiträge: 1
 

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.

https://techcommunity.microsoft.com/t5/iis-support-blog/missing-net-tcp-net-pipe-net-msmq-and-msmq-formatname-bindings/ba-p/830142

Er hat das allerdings als nicht entscheident eingestuft, da die Einträge auch vor CU23 nicht da waren. Ich habe noch nicht getestet…


   
AntwortZitat

(@exchadmin)
New Member
Beigetreten: Vor 2 Jahren
Beiträge: 2
 

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.


   
AntwortZitat
 rudi
(@rudi)
Active Member
Beigetreten: Vor 3 Jahren
Beiträge: 10
Themenstarter  

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.


   
AntwortZitat

(@rk1992)
New Member
Beigetreten: Vor 1 Jahr
Beiträge: 2
 

Hallo zusammen,

 

gibt es hier mittlerweile neue Infos? Problem besteht bei uns im Februar 2023, voll durch gepatched immernoch.. 

Grüße


   
AntwortZitat
 rudi
(@rudi)
Active Member
Beigetreten: Vor 3 Jahren
Beiträge: 10
Themenstarter  

@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?


   
AntwortZitat

(@rk1992)
New Member
Beigetreten: Vor 1 Jahr
Beiträge: 2
 

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. 


   
AntwortZitat
(@m4d1s0n)
Eminent Member
Beigetreten: Vor 3 Jahren
Beiträge: 17
 

Veröffentlicht von: @norbertfe

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)

Veröffentlicht von: @stardust

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?

 


   
AntwortZitat

NorbertFe
(@norbertfe)
Noble Member
Beigetreten: Vor 3 Jahren
Beiträge: 1420
 

Steht doch im Zitat drin. Per set-casmailbox


   
AntwortZitat
(@exchadmin)
New Member
Beigetreten: Vor 2 Jahren
Beiträge: 2
 

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.

Diese r Beitrag wurde geändert Vor 3 Monaten von exchadmin

   
AntwortZitat

Teilen: