Outlook Clients nach Schließen keine Verbindung zu Exchange

Hallo zusammen,

wir haben ein merkwürdiges Problem, bei dem momentan weder wir, noch diverse Dienstleister weiterkommen.

Im Einsatz:

- Exchange 2019 CU14 OnPrem Standalone

- 2x Domain Controller Server 2019 (Forest- und Domainlevel auf 2016)

- Clients nutzen hauptsächlich Outlook 2016

Problem: wenn ein User (egal welcher, egal von welchem Client, egal welche Outlook-Version) Kalender öffnet, und dann Outlook schließt, kann sein Outlook beim erneuten Öffnen keine Verbindung mehr zum Exchange herstellt. Outlook bringt rechts unten "getrennt". Der Verbindungsstatus sagt mir aber, dass die Verbindung hergestellt sei. Auch der Verbindungstest klappt, alles fein. Dann das ganz komische: erst nach einer Wartezeit von exakt 15 Minuten kann Outlook wieder eine Verbindung herstellen und alles ist wieder gut.

Wir haben schon das komplette Internet durchforstet, und auch schon seeehr vieles ausprobiert. Z.b.:

- Mit und ohne Cache-Modus

- Flushdns am Client

- Mapi und NSPI Limits erhöht

- Millionen Mal Outlook-Profil gelöscht und neu angelegt

- alle Outlook-Versionen von 2013 bis O365 probiert

- clientseitig komplett AV deinstalliert

- in der Ereignissanzeige ist weder am Exchange, noch auf den DCs, noch auf den Clients ein Hinweis zu finden

Das alles und noch mehr bringt gar nichts. 15 Minuten warten, und dann erst klappt es wieder. Im Hintergrund muss irgendetwas den erneuten Anmeldeversuch des Clients blocken. Während dieser Wartezeit ist die OWA durchgehend, auch mit Kalender verfügbar. Hier gibt es nie Probleme.

Ich habe noch einen Post von einem User gefunden, der exakt das selbe Problem hatte, leider verlief der Thread im Nirvana: https://community.spiceworks.com/t/outlook-desk…times/949880/16

Ich freue mich über jeden Tipp!

Hi Norbert, vielen Dank! Zu den Fragen:

- AV Clients: Eset Endpoint Protection v11

- AV Exchange: Eset Mail Security. Die Ausnahmen setzt Eset in dem Fall automatisch, prüfe ich aber nochmal

- Kein Proxy

- Keine Firewall, Clients und Exchange sind im selben Netz

- Das Problem tritt immer dann auf, wenn die Kalender zum Synchronisieren anfangen. Wenn ich nur Mails schreibe, etc. ohne das Kalender geladen werden, tritt das Problem nicht auf

- Zeit ist synchron

Es muss irgendein mir unbekanntes Limit geben, welches dann erneute Verbindungen erst wieder nach 15 Minuten zulässt. Auch ein Neustart des Clients oder ein Recyclen der AppPools ändert nichts daran

Guten Morgen,

nein, wir nutzen keine Addins. Im Safe-Mode besteht das Problem ebenso. (Neu angelegte) Benutzer, die nicht auf Kalender zugreifen, haben das Problem überhaupt nicht. Bei uns geht es speziell um eine Abteilung, die auf sehr viele Raumkalender zugreift.

Browser: wir nutzen Edge, aber in der OWA besteht das Problem nicht, nur mit Outlook.

In den Protokolldateien finde ich das:

2024.07.25 08:18:10 <<<< Logging Started (level is LTF_TRACE) >>>>
2024.07.25 08:18:10 HELPER::Initialize called
2024.07.25 08:18:10 Initializing: Finding a Transport
2024.07.25 08:18:10 MAPI XP Call: XPProviderInit in EMSMDB.DLL, hr = 0x00000000
2024.07.25 08:18:10 MAPI Status: (-- -- ---/--- -- ---)
2024.07.25 08:18:10 MAPI XP Call: TransportLogon, hr = 0x00000000
2024.07.25 08:18:10 Initializing: Found a transport, Error code = 0x00000000
2024.07.25 08:18:10 MAPI XP Call: AddressTypes, hr = 0x00000000, cAddrs = 3, cUids = 1
2024.07.25 08:18:10 MAPI Status: (IN -- ---/OUT -- ---)
2024.07.25 08:18:10 MAPI XP Call: TransportNotify(BEGIN_IN|BEGIN_OUT), hr = 0x00000000
2024.07.25 08:18:10 HELPER::Initialize done, Error code = 0x00000000
2024.07.25 08:18:10 HELPER::GetCapabilities called, Error code = 0x00000000
2024.07.25 08:18:17 HELPER::Uninitialize called
2024.07.25 08:18:17 MAPI Status: (-- -- ---/--- -- ---)
2024.07.25 08:18:17 MAPI XP Call: TransportNotify(END_IN|END_OUT), hr = 0x00000000
2024.07.25 08:18:17 MAPI XP Call: TransportLogoff in EMSMDB.DLL, hr = 0x00000000
2024.07.25 08:18:17 MAPI XP Call: Shutdown, hr = 0x00000000
2024.07.25 08:18:17 Resource manager terminated

Aber alle Posts im Internet dazu verlaufen auch wieder im Nichts

Nachtrag: ich will es noch nicht zu laut verschreien, aber ich denke ich konnte das Problem soeben lösen. Ich habe den betroffenen Mailboxen eine unlimitierte ThrottlingPolicy zugewiesen, und das Problem war weg. Unlimitiert ist zwar nicht die schönste Lösung, aber in unserem Fall war es die einzige.

Ursprünglich waren diese Werte zugewiesen:

AnonymousMaxConcurrency : 1
BookingSelfServiceMaxConcurrency : 10
ConsensusMaxConcurrency : 10
SchedulesMaxConcurrency : 5
EasMaxConcurrency : 10
EwsMaxConcurrency : 27
ImapMaxConcurrency : Unlimited
OutlookServiceMaxConcurrency : 27
OwaMaxConcurrency : 20
OwaVoiceMaxConcurrency : 3
PopMaxConcurrency : 20
PowerShellMaxConcurrency : 18
PowerShellMaxTenantConcurrency : Unlimited
PswsMaxConcurrency : 18
RcaMaxConcurrency : 40
CpaMaxConcurrency : 20
RcaSharedMaxConcurrency : Unlimited
DiscoveryMaxConcurrency : 2
PushNotificationMaxConcurrency : 20
EncryptionSenderMaxConcurrency : 200
EncryptionRecipientMaxConcurrency : 20
SuiteMaxConcurrency : 20