Anmeldeproblem mit Outlook 2024 Classic und Exchange Server 2019

Ich stelle mal ein Problem hier im Blog ein, mit dem ein Leser sich herumschlägt. In seiner Unternehmensumgebung, die er als Administrator betreut, hat er einige von ca. 400 Nutzern, die sich unter Microsoft Outlook 2024 nicht am  Exchange Server 2019 anmelden können. Das Problem hatte ich bereits im Juni 2025 in Zusammenhang mit mehreren Office-Versionen beschrieben.

Lesermeldung des Outlook 2024-Problems

Der Blog-Leser ist als Administrator in einem Unternehmen beschäftigt, in dem Microsoft Office 2024 für die Anwender zum Einsatz kommt. Die Nutzer verwenden dabei auch Microsoft Outlook 2024, um auf einen Exchange Server 2019 zuzugreifen. Soweit alles fein.

Nun hat sich der Leser vor einigen Tagen gemeldet, weil plötzlich ein Problem mit Outlook 2024 in Verbindung mit Exchange 2019 (On-premises) auftritt. Das Fehlerbild lautet, dass sich der Nutzer mit seinem Outlook 2024-Client plötzlich nicht mehr am Exchange  Server 2019 anmelden kann. Es besteht dann keine Verbindung mehr zwischen Client und Server.

Dann wird dem Benutzer oben stehender Fehlerdialog angezeigt.  In der Taskleiste wird dem Benutzer dann ein gelbes Dreieck als Warnung, dass keine Verbindung besteht, eingeblendet.

Schaut man sich den Outlook-Verbindungsstatus zum Microsoft Exchange-Server an, werden dort die Verbindungen als getrennt aufgelistet.

Das Krude an diesem Fehlerbild: Der Fehler tritt nicht durchgehend auf, sondern betrifft nur wenige Nutzer aus einer Menge von 400 Anwendern. Wenn dieses Problem auftritt, kann der Benutzer auch einzelne Schaltflächen (in der Multifunktionsleiste, Ribbon) nicht mehr auswählen.

Noch einige Details

Als Office-Version kommt auf den Windows-Clients Microsoft Office LTSC Pro Plus in der Build 16.0179332.20540 in dieser Umgebung zum Einsatz. Es sind so um die 400 Nutzer mit diesem Office versorgt. 

Als Server wird Windows Server 2022 betrieben, wobei dort wohl eine Terminal Server-Rolle installiert ist (auch Citrix wurde erwähnt). Der Exchange Server 2019 hat CU15 installiert und ist auf Build 15.2.1748.37. Es ist eine gültige Subscription wegen geplantem Update auf Exchange SE vorhanden.

Fehler erst seit kurzem

Der Leser schreibt, dass an der Konfiguration die letzte Zeit nichts geändert wurde. Am 10.09.2025 wurden die Windows Updates installiert, und am 11.09.2025 kam dann das Exchange CU 15 zur Installiert.

Die Fehlermeldung kam anfangs sporadisch, nach einigen Tagen bekam der Administrator mehrere Nachfragen. Es gibt eine Gemeinsamkeit: Betroffene Benutzer verfügen über "große" Postfächer mit vielen angehangenen Ressourcen, schreibt der Leser. Was hat er bisher zur Kontrolle unternommen:

• Es sind keine weiteren Updates vorhanden und die Zertifikate sind auch gültig
• Im Event Log findet sich nichts auffälliges, OWA und ActiveSync melden kein Problem
• Es wurden die Outlook-Dateien im Profil unter AppData gelöscht und die Vorgaben für "best practices" kontrolliert

Alle diese Maßnahmen führten bisher nicht zum Erfolg. Ein neues Nutzerprofil wurde zum Test bisher noch nicht erstellt.

Der Leser merkt noch an, dass der Nachteil von Microsoft Office 2024 Classic für ihn sei, dass der Updates nicht rückgängig machen/ deinstallieren könne. Der Hintergrund seien die gegebenen Funktionen von OWA und AS. Daher habe er eher Outlook im Fokus, und nicht den Exchange Server 2019. Ob da durch Änderungen seitens Microsoft im Hinblick auf den Wechsel auf Microsoft Exchange SE erfolgen, kann der Leser nicht einschätzen.

Wenn Microsoft Outlook 2024 wegen des Fehlers "hängt", und Schaltflächen nicht angeklickt werden konnten, zeigt der Task-Manager das sowohl die CPU-Last als auch die RAM-Auslastung in Ordnung seien, merkt der Leser an. Es arbeitete bei diesem Test, wo der Fehler auftrat, wohl nur ein einziger Nutzer auf dem Terminal-Server. In diesem Fall handelte es sich um den Citrix-Server, den der Leser verwendet, um Software vorab upzudaten oder zum Testen.

Der Fehler ist seit längerem bekannt

Beim Schreiben des Blog-Beitrags habe ich bei obigem Screenshot beim Fehlerhinweis "Einen Dienst hinzufügen" gestutzt. Das Problem mit dem Dienst, der sich nicht hinzufügen lässt, hatte ich im Beitrag Outlook Classic-Problem: Verlangt "Einen Dienst hinzufügen" (Juni 2025) bereits aufgegriffen.

Was ich mir aus den Kommentaren zusammenreime: Dort wurde ein Proxy als Ursache für die Verbindungsabbrüche und ein Zusammenhang mit den CoPilot-Aktivitäten vermutet. Der Leserkommentar hier verweist auf den Techcommunity-Post Copilot is now available in classic Outlook for Windows und erscheint recht zielführend zu sein. Die Erklärung: Microsoft hat CoPilot auch für Outlook Classic eingeführt, aber die Nutzer benötigen eine Lizenz. Hier die Zitate aus dem Kommentar:

Some people already mentioned this but in order for Copilot in classic Outlook to work, you need to have a Copilot license and Autodiscover V2 service.

The Autodiscover V2 service is disabled if the DisableAutodiscoverV2Service registry entry exists under the

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover

subkey, and the DWORD value of the DisableAutodiscoverV2Service entry is 1.

Der Vorschlag eine Lesers lautete: Vielleicht hilft es Autodiscover V2 zu deaktivieren, um Copilot zu unterdrücken, obwohl Copilot offiziell nur in den Abo-Versionen von Office verfügbar ist. Weitere Betroffene bestätigten, dass das Abschalten des Autodiscover V2-Diensts per Registry-Wert (0) den CoPilot deaktiviert und das Problem der Verbindungsabbrüche gelöst habe. Andere Leser schreiben, dass es nichts bringt. Ein weitere Leser schrieb, dass AutoDiscover, wie hier bei Frank beschrieben, geholfen habe.

Ein Leser gibt an, dass die im Beitrag Add a Service Credential pop-up in Outlook Critical issue beschriebene Maßnahmen bei ihm das Problem gelöst habe. Das Office 2024-Update vom 3.9.2025 hat wohl bei einigen Leuten auch Abhilfe geschaffen – obige Fehlerbeschreibung deutet aber darauf hin, dass da was neues passiert sein kann.

GPO soll Problem fixen

Ergänzung: Der Leser hat sich zum 23. September 2025 nochmals bei mir per E-Mail gemeldet und schrieb: "Ich habe meine produktive Testumgebung (der TS des Admin) heute Nacht nochmal auf Stand heute Vormittag vor Beginn der Fehlersuche zurück gesetzt und die einzelnen Schritte/ Änderungen einzeln getestet und auch wieder rückgängig gemacht, immer mit reboot zwischen der einzelnen Schritte."

Der Leser hat dann die Exchange Gruppenrichtlinie AutoErmittlung deaktivieren gesetzt und schreibt: "Ich würde mich recht sicher festlegen, das diese Einstellung der GPO das Problem beseitigt, das dieses Einstellungen alleine das Problem beheben. Bei meiner Testumgebung hat alles andere einzeln keinen Erfolg gezeigt. Das ist ja auch von einem Kommentar beschrieben, ich glaube das es dort aber mit der Registry angepasst wurde, ich finde GPOs besser (eigener Geschmack, keine Kritik). Ich bin durch, ich schreibe die Tage ob das Problem wirklich behoben ist."