Verlauf Wir migrieren Exchange 2010 auf 2019. Mit Exchange 2016 befinden wir uns in der Mitte und 2010 läuft noch.
Umfeld
Serverumgebung Active Directory Domänenebene: 2012R2 Anzahl Domänencontroller: 4 x3 DCs mit 2012R2 x1 DCs mit 2022 x1 Exchange 2010-Server x1 Exchange 2016-Server
Clientumgebung Nr. 1: Windows 10 Pro Desktop Outlook v16 (x86) (Microsoft 365)
Clientumgebung Nr. 2 Windows 2022 Datacenter Outlook v16 (x86) (Microsoft 365)
Clientumgebung Nr. 3: Windows 2012R2 Datacenter Outlook v16 (x86) (Microsoft 365)
Clientumgebung Nr. 4: OWA wird auf dem Exchange 2016-Server gehostet und über Chrome aufgerufen. Problembeschreibung
In allen Clientumgebungen, in denen der Outlook-Client verwendet wird, kann ein Benutzer den Outlook-Client (normalerweise) nach dem Schließen nicht erneut öffnen. Nachdem der Outlook-Client in den Fehlerzustand übergegangen ist, wird beim Starten des Programms die folgende Meldung zurückgegeben.
„Microsoft Outlook kann nicht gestartet werden. Das Outlook-Fenster kann nicht geöffnet werden. Die Ordnergruppe kann nicht geöffnet werden. Der Anmeldeversuch bei Microsoft Exchange ist fehlgeschlagen.“
Dieser Fehlerzustand bleibt etwa 15 Minuten lang bestehen, bevor der Client wieder in einen funktionierenden Zustand zurückkehrt. Alternativ kann die auf dem Exchange 2016-Server gehostete Website „Exchange Back End“ neu gestartet werden, um den Client wieder in einen funktionierenden Zustand zu versetzen. Dadurch können Clients sofort eine Verbindung zum Exchange-Server herstellen.
Ich habe stundenlang versucht, das Problem zu beheben, aber ich komme nicht weiter. Hat jemand einen Rat?
Danke,
D
Antwort1
Zeit für ein Update,
Mithilfe eines Drittanbieters scheinen wir eine funktionierende Lösung zu haben. Wir haben das Standard-Drosselungsprofil bearbeitet und auf betroffene Benutzer angewendet. Die spezifische Einstellung, die geändert wurde, war RcaMaxConcurrency. Der Standardwert war auf 40 eingestellt, also haben wir ihn auf unbegrenzt erweitert und nur auf betroffene Benutzer angewendet. Nachdem dies wirksam wurde, ist das Problem bei den betroffenen Benutzern noch nicht wieder aufgetreten. Erwähnenswert ist auch, dass diese Änderung nach der Migration auf 2019 vorgenommen wurde. Das Problem war 2016 und 2019 dasselbe, aber wir haben erst nach der Migration auf 2019 eine Lösung gefunden.