Exchange SE sporadische Client Zugriffsprobleme

[possum72 9]

Hallo zusammen

 

Habe hier einen Exchange SE welcher mir seit einigen Tagen Kopfzerbrechen bereitet.

Folgende Szenarien konnte ich beobachten:
Es ist bis jezt 2-3 mal vorgekommen, dass ALLE Benutzer per Outlook keinen Zugriff mehr auf Exchange haben. Aber so nach ca. 1-2 Minuten funtioniert es dann wieder. Passierte die letzten 10 Tage 2 mal. Erkennbar ist es daran, dass je nach Einstellung des Cache-Modus entweder rechts unten im Outlook "Verbinungsversuch" steht, oder das Anmeldefenster für das Konto erscheint.
Aber bei einigen Benutzern passiert es, dass der Zugriff bis zu 10mal am Tag kurzzeitig weg ist (manchmal nur für Sekunden).

Es handelt sich dabei aber auch immer um unterschiedliche Benutzer und unterschiedliche Geräte.

 

Am Anfang hatte ich das Netzwerk in Verdacht. Konnte aber hier keinen Fehler finden (Log in Cisco Switche und auch Monitoring zeigen keinen Fehler). Auch die Zugriffe auf TerminalServer, Drucker, Warenwirtschaft, usw. funktionieren tadellos.

Was aber auch einmal bis jetzt passierte ist, dass Scan to Mail nicht funktionierte (was ebenfalls über den Exchange läuft).

Da der Exchange eine VM ist, wurde auch mal testweise eine andere Netzwerkkarte benutzt. Gab auch keine Verbesserung

 

Sicherheitsprogramme wie Sophos Advanced Server hatte ich mal testweise deinstalliert und danach auch den Windows Defender deaktiviert. 
Gleiches Phänomen.

 

Ereignisanzeige ist weiß wie Babypopo.

Updates vom OS (Windows Server 2019) und Exchange SE sind aktuell.

 

Also irgendetwas muss hier beim Exchange sein, dass er immer wieder für kurze Zeit blockt. 

 

So, und nun benötige ich wirklich eure Hilfe, weil mir langsam die Ideen ausgehen.

 

 

Viele Grüße

 

Andreas

 

[testperson 1.920]

Hi,

 

werden dir Zertifikate angezeigt, wenn du in der Exchange Management Shell "Get-ExchangeCertificate" ausführst bzw. passt das Auth Zertifikat (Get-AuthConfig)? Ist auf den Clients (dem Server) eine Securitylösung, die ggfs. SSL aufbricht?

 

Sofern die Extended Protection an ist, könntest du diese testweise einmal deaktivieren: ExchangeExtendedProtectionManagement - Microsoft - CSS-Exchange

.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection

 

Gruß

Jan

[Nobbyaushb 1.618]

Die anderen VM auf dem Host haben kein Problem?

Wie sieht das sizing von der VM aus?

Was für ein Hypervisor?

[possum72 9]

vor 11 Stunden schrieb testperson:

Hi,

 

werden dir Zertifikate angezeigt, wenn du in der Exchange Management Shell "Get-ExchangeCertificate" ausführst bzw. passt das Auth Zertifikat (Get-AuthConfig)? Ist auf den Clients (dem Server) eine Securitylösung, die ggfs. SSL aufbricht?

 

Sofern die Extended Protection an ist, könntest du diese testweise einmal deaktivieren: ExchangeExtendedProtectionManagement - Microsoft - CSS-Exchange

.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection

 

Gruß

Jan

 

Hallo Jan

Nun das Zertifikat sieht eigentlich in Ordnung aus. Habe es mit einem anderen Exchage SE verglichen. Nur das dort (warum auch immer) der SMTP Dienst aktiviert ist und bei dem wo es keine Probleme gibt ist dieser nicht aktiviert. Exchange ExtendesProtection ist nicht aktiviert.

Viele Grüße

Andreas
 

vor 11 Stunden schrieb Nobbyaushb:

Die anderen VM auf dem Host haben kein Problem?

Wie sieht das sizing von der VM aus?

Was für ein Hypervisor?

 

Die anderen VMs (insgesamt 7) haben tatsächlich keinen Probleme. Es läuft drauf ein VMWare Version 7.0 Update 3. Ich habe Zuweisung der Hardware sehr großzügig bemessen.

128GB Arbeitsspeicher, 24 CPUs, 2 Festplatten wo überall noch 500GB frei sind. Auf dem virutellen Swotch laufen auch noch 2 andere Maschinen, die keine Probleme machen. Aber da ich 3 virtuelle Switch habe werde ich mal trotzdem einen anderen verwenden.

 

[Nobbyaushb 1.618]

24 vCPU finde ich oversized

Wie viele Cores hat der Host zur Verfügung?

Takt?

Ansonsten habe ich keine weitere Idee 

Warum 3 vSwitche?

[possum72 9]

vor 58 Minuten schrieb Nobbyaushb:

24 vCPU finde ich oversized

Wie viele Cores hat der Host zur Verfügung?

Takt?

Ansonsten habe ich keine weitere Idee 

Warum 3 vSwitche?

 

Nun, der Host besitzt 32 Cores (2*Xeon Gold 6526Y). Soll ich diese verringern ? Die VSwitche wurde zur "Ausfallsicherheit" angelegt. Aber ich gebe Dir recht, hätte man auch anders lösen könne. Wobei ich glaube, dass dies nicht mein Problem ist.

 

[Nobbyaushb 1.618]

Gerade eben schrieb possum72:

 

Nun, der Host besitzt 32 Cores (2*Xeon Gold 6526Y). Soll ich diese verringern ? Die VSwitche wurde zur "Ausfallsicherheit" angelegt. Aber ich gebe Dir recht, hätte man auch anders lösen könne. Wobei ich glaube, dass dies nicht mein Problem ist.

Keine Ahnung, dafür müsste man sich das ganze anschauen, und das ist m.E. in einem Forum schlecht bis nicht leistbar

[NorbertFe 2.343]

vor 2 Stunden schrieb possum72:

Exchange ExtendesProtection ist nicht aktiviert.

Warum nicht?

vor 2 Stunden schrieb possum72:

Nur das dort (warum auch immer) der SMTP Dienst aktiviert ist und bei dem wo es keine Probleme gibt ist dieser nicht aktiviert.

Weil das selfsigned Zertifikat immer als internes Transportzertifikat aktiviert wird (beim Setup). Das sollte man auch so lassen und alle externen Zertifikate sollten bei Aktivierung auch die Frage nach dem Überschreiben mit "nein" beantworten. Falls das nicht angezeigte Zertifikat ein externes Zertifikat ist, dann wurde das nicht über die Exchange Powershell (oder ECP) importiert sondern über die Zertifikatskonsole. Da hilft dann nur Zertifikat löschen und per Exchange Powershell importieren und die das Zertifikat für die Dienste neu aktivieren.

 

Ansonsten wär ich auch jemand der 24vCPUs erstmal skeptisch anschaut. Erscheint mir bei Single Serverkonstellationen aufgrund der mutmaßlich geringen Nutzeranzahl recht viel. Aber ohne weitere Infos kann man da schlecht was raten. Zum Thema 

vor 15 Minuten schrieb possum72:

"Ausfallsicherheit"

böte sich ja wohl eher ein Switch Embedded Teaming an, anstatt 3 vSwitches zu konfigurieren, bei denen man im Ausfall-Fall je erstmal manuell eingreifen muss.

 

Ansonsten als grundsätzlichen Rat: Nimm dir mal den Exchange Healthchecker und mach alles was gelb oder rot ist erstmal grün ;)

 

Danach kann man weitersehen.

 

Bis dann

Norbert

[possum72 9]

Hallo zusammen

Tja, mein Problerm besteht immer noch. Den HealtChekcer habe ich durchlaufen lassen. Ja es waren ein paar Stellen Rot markiert. Habe ich gerade gebogen. Aber leider war das nicht die Lösung. Folgendes ist mir aufgefallen. Wenn das Problem auftaucht erscheint im Outlook der Fehler, dass derzeit keine Verbindung mit dem Server hergestellt werden kann. Komischerweise steht aber rechts unten im Outlook "Verbunden mit Microsoft Exchange".

Wie erwähnt kommt man währendessen mit OWA ohne Probleme drauf. Ich hätte noch die Idee, dass man vielleicht doch den Exchange auf eine frische ServerInstallation kopiert und dann mal testet. Was meint Ihr ? War ja das Thema wegen der Netzwerkkonfiguration in VMWare.

Viele Grüße

 

Andreas

 

[NorbertFe 2.343]

vor 1 Stunde schrieb possum72:

Exchange auf eine frische ServerInstallation kopiert

Andere nennen das Migration. ;)

[agmblp4eh4e 11]

Die von dir beschriebenen kurzen Ausfälle sind ein bekanntes Phänomen bei Exchange 2019/Outlook-Clients. Häufige Ursachen sind DNS- oder Autodiscover-Probleme, Lastspitzen durch den IIS/Exchange-Dienste, fehlerhafte Zertifikate oder eine instabile RPC-over-HTTP/MAPI-over-HTTP-Verbindung. Es lohnt sich, gezielt die Exchange-Logs (Connectivity, RPC, IIS) sowie DNS- und Zertifikatseinstellungen zu prüfen.

• DNS/Autodiscover:

  • Outlook hängt stark von Autodiscover ab. Schon kleine DNS-Fehler oder Zeitüberschreitungen können zu kurzen Verbindungsabbrüchen führen.

  • Prüfe, ob interne und externe DNS-Einträge korrekt gesetzt sind und ob Autodiscover sauber aufgelöst wird.

• MAPI over HTTP / RPC over HTTP:

  • Seit Exchange 2016 ist MAPI over HTTP Standard. Wenn hier Timeouts oder Session-Resets auftreten, kommt es zu den von dir beschriebenen kurzen Unterbrechungen.

  • In den IIS-Logs findest du Hinweise, ob Sessions regelmäßig abbrechen.

• IIS / Exchange-Dienste:

  • Exchange nutzt IIS intensiv. Wenn der Application Pool für MSExchangeMapiAppPool recycelt wird, verlieren alle Clients kurz die Verbindung. Standardmäßig passiert das einmal alle 29 Stunden, kann aber auch durch Last oder Fehler häufiger auftreten.

  • Prüfe die Einstellungen der AppPools und ob es zu unerwarteten Recycling-Ereignissen kommt.

• Zertifikate:

  • Abgelaufene oder falsch gebundene Zertifikate können sporadische Authentifizierungsabbrüche verursachen.

  • Stelle sicher, dass das richtige Zertifikat für IIS/SMTP gebunden ist und keine Warnungen im Hintergrund auftreten.

• VM/Hypervisor-Ebene:

  • Auch wenn du die Netzwerkkarte gewechselt hast: Prüfe, ob die VM eventuell Lastspitzen hat (CPU, RAM, Storage). Kurze I/O-Blockaden können Exchange-Dienste einfrieren.

  • Besonders Storage-Latenzen sind kritisch für Exchange.

• Clientseitig:

  • Manche Outlook-Versionen (z. B. 2019 mit bestimmten Builds) hatten bekannte Bugs mit MAPI over HTTP, die zu kurzen Disconnects führten

  • Teste, ob die betroffenen Clients mit der neuesten Outlook-Build laufen.

[possum72 9]

vor 5 Stunden schrieb agmblp4eh4e:

Die von dir beschriebenen kurzen Ausfälle sind ein bekanntes Phänomen bei Exchange 2019/Outlook-Clients. Häufige Ursachen sind DNS- oder Autodiscover-Probleme, Lastspitzen durch den IIS/Exchange-Dienste, fehlerhafte Zertifikate oder eine instabile RPC-over-HTTP/MAPI-over-HTTP-Verbindung. Es lohnt sich, gezielt die Exchange-Logs (Connectivity, RPC, IIS) sowie DNS- und Zertifikatseinstellungen zu prüfen.

• DNS/Autodiscover:

  • Outlook hängt stark von Autodiscover ab. Schon kleine DNS-Fehler oder Zeitüberschreitungen können zu kurzen Verbindungsabbrüchen führen.

  • Prüfe, ob interne und externe DNS-Einträge korrekt gesetzt sind und ob Autodiscover sauber aufgelöst wird.

• MAPI over HTTP / RPC over HTTP:

  • Seit Exchange 2016 ist MAPI over HTTP Standard. Wenn hier Timeouts oder Session-Resets auftreten, kommt es zu den von dir beschriebenen kurzen Unterbrechungen.

  • In den IIS-Logs findest du Hinweise, ob Sessions regelmäßig abbrechen.

• IIS / Exchange-Dienste:

  • Exchange nutzt IIS intensiv. Wenn der Application Pool für MSExchangeMapiAppPool recycelt wird, verlieren alle Clients kurz die Verbindung. Standardmäßig passiert das einmal alle 29 Stunden, kann aber auch durch Last oder Fehler häufiger auftreten.

  • Prüfe die Einstellungen der AppPools und ob es zu unerwarteten Recycling-Ereignissen kommt.

• Zertifikate:

  • Abgelaufene oder falsch gebundene Zertifikate können sporadische Authentifizierungsabbrüche verursachen.

  • Stelle sicher, dass das richtige Zertifikat für IIS/SMTP gebunden ist und keine Warnungen im Hintergrund auftreten.

• VM/Hypervisor-Ebene:

  • Auch wenn du die Netzwerkkarte gewechselt hast: Prüfe, ob die VM eventuell Lastspitzen hat (CPU, RAM, Storage). Kurze I/O-Blockaden können Exchange-Dienste einfrieren.

  • Besonders Storage-Latenzen sind kritisch für Exchange.

• Clientseitig:

  • Manche Outlook-Versionen (z. B. 2019 mit bestimmten Builds) hatten bekannte Bugs mit MAPI over HTTP, die zu kurzen Disconnects führten

  • Teste, ob die betroffenen Clients mit der neuesten Outlook-Build laufen.

 

Hallo

Vielen Dank für Deine Ausführung. Ich werde mal die Liste komplett abarbeiten und Dir dann berichten.

 

Viele Grüße

Andreas