nach CU21 Update schlechte Outlook-Performance

Hallo in die Runde,

Nach 3 Tagen Problemanalyse sehe ich scheinbar den Wald vor lauter Bäumen nicht mehr und brauche mal weitere Meinung oder den Stups in die richtige Richtung.

Ausgangssituation:

HP Proliant DL380 Gen9 Server mit VMware ESXi. 1 Server 2016 als DC (und Fileserver), 1 Exchange 2016 CU21 inkl. KB5004779, 1 Terminalserver (Server 2016)
Netzwerkanbindung : 1x Gb
Router : Sophos XG 130 mit WebServerProtection
Useranzahl : 35 User-Postfächer, 15 freigegebene PF
1x Zentrale + 2 Außenstellen per L2L-VPN über Sophos

Problembeschreibung :

Vor 4 Tagen wurde abends das Exchange2016 CU21 inkl. KB5004779 installiert. Setup lief durch ohne Probleme. Zugriff via Outlook vom Terminalserver, per OWA und ActiveSync war möglich und schnell.
Am darauf folgenden Tag beschwerten sich die User, dass ihr Outlook sehr lange beim Starten braucht und sich nach erfolgreichem Start auch sehr träge verhält. Der Start eines Outlooks dauerte ca. 4 Minuten.
Im Verbindungsstatus konnte man erkennen, dass :
1. HTTP als Protokoll benutzt wurde
2. zunächst ein "Fehler" im Status zu finden war und danach das Auth auf Negotiate stand.

Es waren nicht nur die User in den Außenstellen betroffen, sondern auch die Zentrale. Erster Verdacht war die WebProtection (die nach Anleitung von Franky eingerichtet wurde).

Fehlersuche :

Mir ist aufgefallen, dass auf dem Exchange Server einige Prozesse "IIS Worker" ca. 20% CPU Last erzeugten. Darauf hin kontrollierte ich im IIS-Manager die APP-Pools.
MSExchangeMapiFrontEnd und MSExchangeMapiMailbox waren hier die Übertäter mit 15 bzw. 16% CPU.
Ein manuelles Recyle half nicht.
Ein Neustart des Servers sorgte zunächst für Entspannung und die Outlooks verhielten sich normal. Nach ein paar Stunden ging der Spuck von neuem los.
Ein Neustart des IIS-Server-Dienstes reichte dann aber, statt des ganzen Servers.

OWA, ActiveSync und sonstige Funktionen laufen ohne Probleme.

Da ja Einige Probleme mit dem KB5004779 hatten, habe ich dies wieder deinstalliert - ohne Besserung der Situation.
Das Ereignissprotokoll ließ nicht allzuviel Rückschluss auf größere Probleme zu. Ich entschloß mich also den Exchange neu zu installieren, Konfig auf neuen Exchange anpassen, Postfächer migrieren und gut.

Dem war leider nicht so, da der neue Exchange (2016 CU 21 ) das gleiche Phänomen zeigt. Nachdem alle Postfächer migriert waren ... gleiches Spiel von vorn.
In Ereignisprotokll ist nicht viel zu finden :
      1. im Oktober auslaufendes Zertifikat
      2. Perflib 1023 : Die erweiterbare Leistungsindikator-DLL MSExchangeIS kann nicht geladen werden.
      3. MSExchangeApplicationLogic 3018 :

Scenario[ServiceHealth]: GetConfig. CorrelationId: 5beb54e8-9437-4518-967d-ce7213524dd3. The request failed. Mailbox: Url:  https://officeclient.microsoft.com/config16?CV=15.1.2308.14&Client=WAC_Outlook&corr=5beb54e8-9437-4518-967d-ce7213524dd3  Exception: System.Net.WebException: Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden.. ---> System.IO.IOException: Von der Übertragungsverbindung können keine Daten gelesen werden: Eine vorhandene Verbindung wurde vom Remotehost geschlossen. ---> System.Net.Sockets.SocketException: Eine vorhandene Verbindung wurde vom Remotehost geschlossen
bei System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult)
bei System.Net.Sockets.NetworkStream.EndRead(IAsyncResult asyncResult)
--- Ende der internen Ausnahmestapelüberwachung ---
bei System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)
bei System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)
--- Ende der internen Ausnahmestapelüberwachung ---
bei System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
bei Microsoft.Exchange.Data.ApplicationLogic.Extension.BaseAsyncOmexCommand.<>c__DisplayClass18_0.<EndGetResponseCallback>b__0()

Da ich leider nicht allzuviel mit IIS zu hatte, bin ich etwas ratlos wo ich ansetzen soll. In den IIS-Logs kann ich nicht viel fehlerhaftes erkennen. Ich bin über diverse Performance Troubleshootings gestoplert, die mir am Ende aber auch nicht mehr veraten als dass es Performance-Probleme gibt.

Als letzte Maßnahme habe ich (um mir etwas Luft zu verschaffen) per GPO den Registry-Key "MapiHttpDisabled=1" ausgerollt. Bei 1-2 manuellen Test lief das Outlook dann über RPC problemlos.

Wo würdet Ihr ansetzen um die Ursache zu finden?