Ich greife mal ein Thema auf, welches mir die letzten Wochen häufiger untergekommen ist: Störungen und Fehlfunktionen durch die Microsoft-Funktion Autodiscover. Meine Vermutung: Es hängt mit dem Oktober 2025-Patchday zusammen. In den C2R-Installationen holt Office ja automatisch die Updates.
Microsofts Autodiscover ist dazu gedacht, Benutzern das Outlook-Profi (für Verbindungen mit Exchange Server) einzurichten. Laut dieser Seite wurde die Funktion erstmals mit Exchange Server 2007 eingeführt. Frank Carius hat Autodiscover diesen Artikel gewidmet. Was gut gedacht ist, scheint aber in der Praxis, aus unterschiedlichen Gründen, Probleme und die komischsten Effekte zu verursachen.
Beispiele für Autodiscover Probleme (Okt. 2025)
Nachfolgend liste ich mal kursorisch einige Fälle auf, die mir die letzten Tage unter die Augen gekommen sind, und wo Autodiscover mutmaßlich die Ursache für Probleme war (möglicherweise hat Microsoft was beim Oktober 2025 Patchday geändert).
Klassiker: Outlook-Probleme beim Einrichten eines Exchange Kontos
Der Klassiker, wo Autodiscover Probleme bereiten kann, ist das Einrichten von Microsoft Outlook für ein Exchange Konto. Dann erscheint z.B. die Fehlermeldung:
Die Aktion kann nicht abgeschlossen werden der Name stimmt mit keinem Namen in der Adressliste überein.
Ein solcher Fall ist beispielsweise in diesem Thread auf administrator.de beschrieben. Dort scheint seit ca. 22. Oktober 2025 das Problem aufzutauchen. Die Lösung bestand darin, Autodiscover zu deaktivieren (siehe unten).
Umleitung bei Exchange Online-Anmeldung
Es gibt einen weitere Beitrag Umleitung der Anmeldung zu EXO bei on-premise Exchange vom 22. Oktober 2025 auf administrator.de. Der Thread-Starter schreibt, dass seit ca. dem 20. Oktober auf einem Microsoft Exchange Server 2019 (On-premise) bei einem Benutzer/einem Postfach folgendes Problem auftritt. Startet der Benutzer (Rechner ist in einer Domäne Mitglied) Microsoft Outlook um sich an seinem Postfach am On-premises Exchange Server anzumelden, gibt es Probleme. Anstatt einer transparenten Anmeldung erscheint das OAuth-Anmeldefenster.
Die genannte Lösung besteht darin, Autodiscover am Client per Registrierungseingriff abzuschalten.
Leserdiskussion zu AutoDiscover-Ärger in Exchange Umgebungen
Hier im Blog gibt es diesen Kommentar-Thread zum Blog-Beitrag Patchday: Microsoft Office Updates (14. Oktober 2025). Leser Stephan schreibt, dass er nach dem Office-Update vom 14. Oktober 2025 vereinzelt Ärger in einer lokalen Exchange Umgebung mit Autodiscover hatte. Es kommt wohl ständig ein Anmeldefenster, wie auch andere Blog-Leser in Folgekommentaren schrieben. Es ist fast ein halbes Dutzend Leser, die sich in Kommentaren als betroffen gemeldet haben. Die Lösung war, Autodiscover per Registrierungseintrag zu deaktivieren.
Autodiscover deaktivieren
Autodiscover lässt sich per Gruppenrichtlinie oder durch die nachfolgenden Anweisungen in einer .reg-Datei bzw. durch manuelles Eintragen in den Registry-Zweig deaktivieren.
Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover] "ExcludeExplicitO365Endpoint"=dword:00000001 "ExcludeHttpsRootDomain"=dword:00000001
Frank Carius beschreibt hier die Gruppenrichtlinie, mit der sich AutoDiscover gezielt für einzelne Funktionen deaktivieren lässt.
MVP: 2013 – 2016
Als Exchange on-Prem Betreiber seit Exchange 2010 kenne ich das ExcludeExplicitO365Endpoint und es wurde ab Office 2013 oder 2016 (zu lange her…) notwendig. Sonst sporadisch Modern-Auth Login-Popups. Da es ein mal in unseren User GPO gesetzt wurde, ist das Thema erledigt und trat nie wieder auf (set it and forget it)
Warum das Thema bei on-Prem derzeit hochpoppt ist vielleicht die "erzwungene" Migration auf Exchange SE, die auch wir – rechtzeitig vor der Deadline – umgesetzt hatten. Da ist natürlich extrem wichtig, alle internen und externen URLs sauber zu setzen. Nicht nur für Autodiscover! Die Zertifikate müssen passen, DNS muss passen. Bei Split-brain DNS externes und internes DNS checken und immer überlegen, von wo die Clients grade zugreifen.
Mit hat es das Autodiscover nur während der Migration verhagelt. Weil eine neuer Exchange immer gleich hier und jetzt schreit, aber noch gar nicht konfiguriert ist. Auch nach der Postfachmigration von Exchange 2016 auf den interims Exchange 2019 musste man den IIS Pool öfter mal "recyclen", weil der selbst nicht mehr wusste, wo das Postfach denn liegt. Nach so 2 Tagen hat sich das ganze eingepegelt und läuft wieder sauber. Der letzte Exchage 2019 ist nun auch SE.
Anderer Gedanke: Migrieren viele Betroffene aus einem klassischen AD zu einem Entra joined Modell? Da greifen dann die alten, über die Jahre eingeschliffenen GPO nicht mehr und an sowas wie ExcludeExplicitO365Endpoint denkt keiner mehr.
Sonst hat sich an dem Thema aus meiner Sicht seit ca. 2016 nicht sehr viel geändert. Wer keine Hybrid-Bereitstellung nutzt, sollte das Autodiscover selbstredend auch nicht auf die MS-Server setzen, sondern auf den nach – wie auch immer – außen veröffentlichten Autodiscover von der onPrem-Installation. In meinem Fall hängt eine Sophos XGS davor, der Exchange hat Extended Protection aktiv. Das wird bis zum nächsten Mega 0-day hoffentlich reichen….
Vergangene Woche hat sich ein Kunde gemeldet, dort erscheint im 20 Minutentakt plötzlich, wahrscheinlich nach den letzten Office-Updates, in Outlook wieder die Meldung, dass ein Dienst nicht hinzugefügt werden konnte (Modern Auth Fenster). Eine Anmeldung ist nicht möglich.
Das Problem ließ sich in der Vergangenheit mit den oben beschriebenen Registryeinträgen abschalten. Offenbar jetzt nicht mehr. Gab hier in 2025 auch einen Blogeintrag zum Thema.
Der Kunde setzt Onprem Exchange SE ein. Lösung bislang noch unbekannt.
temp. Lösung könnten folgende 2 Keys sein:
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity
"EnableADAL"=dword:00000000
[HKEY_CURRENT_USER\Software\Microsoft\Exchange]
Das folgende stammt nicht von mir, aber aus den Kommentaren vom Artikel 06-2025, ggf. nur die gewünschten Auto-Abfragen aktiviert lassen. D.h. wenn der interne SCP Eintrag sauber ist, diesen aktiv lassen und auch den Default HTTPS autodiscover Eintrag, so würde ich vorgehen.
[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeExplicitO365Endpoint"=dword:00000001
"ExcludeHttpsRootDomain"=dword:00000001
"ExcludeScpLookup"=dword:00000001
"ExcludeSrvRecord"=dword:00000001
"ExcludeHttpRedirect"=dword:00000001
"ExcludeHttpsAutoDiscoverDomain"=dword:00000001
"AlwaysUseMSOAuthForAutoDiscover"=dword:00000001
Bedient man heutzutage so ein Betriebssystem?
Ist das modern so?
Warum gibt es von Microsoft kein Tool, wo man diese Einstellungen bequem mit Schaltern einstellen kann und wo diese Einstellungen in verständlicher Sprache erklärt werden?
Man kann aber auch mal seine rosarote MS-Brille absetzen und objektiv feststellen:
Microsoft hat es total verkackt.
"AlwaysUseMSOAuthForAutoDiscover_aber_nicht_Sonntags_von_7_bis 13_Uhr_und_Feiertags_schon_gar_nicht"=dword:1!!1111!!1
du möchtest sicherlich einiges zu Recht ändern, aber du willst auf GAR KEINEN Fall zu jedem Registry Eintrag einen Schieberegler in der GUI
Doch natürlich willst du das, weil man da nicht viel falsch machen kann.
Was glaubst du wo die ganzen Infos darüber welcher Server mit welchem Port etc. angesprochen werden von Outlook gespeichert wird? Das steht alles in der Registry, genauso wie der Schalter "Neues Outlook" dort gesteuert wird.
Warum überhaupt so einen verbastelten Frickelkernschrott wie die Registray nehmen?
Weil das ganze System seit Windows 95 komplett auf der Registry basiert.
Falsch, bei Windows NT immer schon und seit Windows 3.1 in der Consumerschiene.
Ist wie das ganze System mittlerweile zu einem quasi unwartbaren Moloch geworden.
Genauso wie der unwartbare Textadventure-Moloch slash-etc… wo dann noch jede Konfig-Datei komplett anders aufgebaut ist. Hightech der 1970er als der *NIX-Kram entstand.
Habt ihr die GPOs wie hier beschrieben entsprechend konfiguriert?
https://gpsearch.azurewebsites.net/#12629
Passen die DNS Einträge?
Bei uns funktioniert der SE ohne Probleme und kontaktiert auch nicht O365.
Man kann den Microsoft-Exchange-Server auch durch den kostenlosen in RUST geschriebenen Open-Source "Stalwart Mail & Collaboration Server" ersetzen.
github. com/stalwartlabs/stalwart
Der kann nicht nur email, sondern auch Kalender, Kontakte, Datenfreigabe.
Dann hätte man vermutlich weniger Probleme als mit der inzwischen bizarr-seltsamen MS-Software-Philosophie.
Ich würde mein Business nicht auf einer Open Source Software die noch in Version 0.X daherkommt aufbauen.
Der neue MS-Outlook-Abteilungsleiter möchte übrigens Outlook komplett neu bauen.
Er fängt mit dem KI-Kern an und die Outlook-Funktionen sollen an diesen KI-Kern angeflanscht werden.
Jede Woche will er neue Features haben.
Das erhöht den Druck auf die Programmierer so stark, dass Fehler unvermeidlich sind.
Seine Vision:
"Think of Outlook as your body double"
theverge. com/tech/806162/microsoft-outlook-ai-overhaul-notepad
Outlook soll also mein Doppelgänger werden?
Das ist Neusprech für Totalanalyse der User.
Das "Neue Outlook" scheint ja ein totaler Reinfall zu sein, wenn die so kurz nach dessen Veröffentlichung eine komplette Neukonstruktion vorhaben.
Probleme mit Autodiscover und moderner Authentifizierung in älteren oder historisch gewachsenen AD-Umgebungen resultieren in der Regel aus Fehlern, Abkürzungen oder unvollständigen Konfigurationen aus der Vergangenheit. Hinzu kommt oft eine fehlende oder rudimentäre Dokumentation, mit der das aktuelle IT-Team leben muss, sowie eine nie erfolgte technische Übergabe durch die früheren Administratoren. Die IT muss ein System steuern und weiterentwickeln, das sie nur teilweise versteht. Meist fehlt die Zeit oder das Budget, um den alten Zustand nachzudokumentieren. Gerade bei Updates oder beim Aufbau hybrider Organisationen werden diese Altlasten sichtbar und verursachen teure Probleme.
Für das Debugging von Autodiscover empfehle ich euch das wirklich gute Whitepaper von Frankys Web zu dem Thema (https://www.frankysweb.de/download/exchange-autodiscover-whitepaper) und die Testconnectivity-Suite von Microsoft (https://testconnectivity.microsoft.com). Wer diese Inhalte nicht versteht, sollte die Grundlagen erarbeiten (ChatGPT kann hierbei helfen) oder gezielt Unterstützung einkaufen.
Da hast du ziemlich exakt meine berufliche Situation beschrieben. Ich bin diese Altlasten zum Glück los mit der Migration zu 365 (auch wenn ich lieber mit Mailserver Plus von Synology gearbeitet hätte)
Die Ursache für unser in den Kommentaren beschriebenes Problem konnten wir heute finden.
Bislang waren die folgenden zwei Schlüssel per GPO in der Registry im Pfad
"HKEY_CURRENT_USER\\Software\\Policies\\Microsoft\\Office\\16.0\\Outlook\\AutoDiscover" gesetzt:
"ExcludeExplicitO365Endpoint"=dword:00000001
"ExcludeHttpsRootDomain"=dword:00000001
Seit Freitag erschien bei einem Kunden in Outlook wieder ein Modern Auth Anmeldefenster mit dem Fehler, dass ein Dienst nicht installiert werden konnten. Bislang haben die zwei Einträge das Problem behoben gehabt.
Nun scheint es so, dass der Pfad "HKEY_CURRENT_USER\\Software\\Policies\\Microsoft\\Office\\16.0\\Outlook\\AutoDiscover" nicht mehr ausgewertet wird.
Tragen wir die Schlüssel manuell im Nicht-GPO Pfad ein "HKEY_CURRENT_USER\\Software\\Microsoft\\Office\\16.0\\Outlook\\AutoDiscover" ist das Problem sofort behoben. Laut Microsoft sollte der Policy-Pfad den Nicht-Policy-Pfad übersteuern.
Möglicherweise besteht hier ein neuer Bug seit dem letzten Patchday. Konnte jemand ähnliche Beobachtungen machen?
Hat Microsoft wieder damit begonnen, die Outlook (new) Variante parallel zu installieren?
Wer die Outlook New Variante gestatet hat, dem wurden die Registry Werte umgebogen.
Ist deren Installation unterbunden?
War hier glaube ich auch schon mal ein Thema …
Ich bevorzuge Synology MailPlus, nicht verständlich wieso viele nicht mal endlich Windows Server rauswerfen und Exchange HybridCloud Mist, und auf lokale/zentrale eigene server setzen.
In MailPlus kann man Exchange migrieren und auch AD kann man übernehmen. Beste ist halt nur einmalige Kosten, keine laufenden Abo Kosten.
Und es gibt einen hübschen Webmailer welcher auch Gruppenpostfächer usw. kann.
Aber jeder wie er mag. Ich mag Outlook Classic, sobald MS dass ganz dicht macht gibt eben nur noch Webmailer. Neue Outlook in US Cloud kommt nicht in Frage.
"Aber jeder wie er mag. Ich mag Outlook Classic, sobald MS dass ganz dicht macht gibt eben nur noch Webmailer. Neue Outlook in US Cloud kommt nicht in Frage."
In dem Moment, wo Exchange Online verwendet wird spielt das auch keine große Rolle mehr, denn dann sind die Maildaten eh schon bei MS. Und das wird über kurz oder lang das Ziel sein, MS will On-Prem am liebsten gestern als morgen loswerden.
Das es überhaupt nochmal einen On-Prem Exchange gegeben hat ist meiner Meinung nach nur dem Druck von zu vielen, zu großen Kunden geschuldet, die nicht in die Cloud wollen/können/dürfen. Die wollte MS aktuell nicht verlieren, ansonsten wäre mit Support-Ende von Exchange 2016/2019 nur noch EXO übrig geblieben.
Wenn Du Lust hast und mir mal einige Textfragmente per Mail zukommen lässt – würde ich mal einen Beitrag drüber machen.
Du magst Outlook Classic? Ehrlich?
Diese ganzen Profilfehler die regelmäßig auftreten. Naja ist besser geworden in den letzten 1-2 Jahren, aber davor? Richtig nervig…
ja! :-)
Mit eigenem Mailserver via imap+smtp und caldav+carddav läuft es soweit. Kein Mapi Exchange gedöns.
Bei Tobit David hat man solche Probleme überhaupt nicht. (u.U. aber andere)
Soweit ich das jetzt im Laufe der Zeit mitbekommen haben, tritt das Problem "nur" auf, wenn der User ein privates oder business Microsoft Konto hat, welches auf die gleiche Mailadresse ausgestellt ist, wie sein (onpremise/hosted exchange Postfach).
hier gibt es übrigens ein Tool für Enduser welches den entsprechenden Registry Eintrag setzt: https://www.managed-office.at/wissensdatenbank/item/office-365-autodiscover-uebergehen
Gott bin ich froh dass ich meinen letzten Exchange on Premise vor 2 Wochen endgültig heruntergefahren habe und mit diesem Mist nichts mehr zu tun habe. Bzw. nur noch Exchange 365, das wesentlich problemloser funktioniert (Zufall?).
Seit einer Woche versuche ich dieses Problem im Zusammenhang mit Outlook 2024 zu lösen. Ich habe jetzt all die Tage bis tief in die Nacht alles ausprobiert, auch all diese Registryhacks, es bringt alles nichts: Dauernd kommt dieses Scheiß-Microsoft-Konto-Fenster und unterbricht mir die Exchange-Verbindung – ich habe alles durch. Ich will mich aber in gar keiner App mit einem Microsoft-Konto einloggen.
Ich bin als privater Endanwender völlig überfordert und krieg es ums Verrecken nicht hin – ich könnte heulen, es ist nicht zu fassen.
Hallo zusammen
Ich habe dasselbe Problem wie Michael K. es geschildert hat.
Folgendes heute Morgen getestet. Neuen Windows Server 2025 mit Patch Stand August 2025 installiert. Outlook 2024 LTSC installiert. Verbindung zu Exchange SE (installiert auf Server 2025), Patchstand Oktober 2025 funktioniert sowie auf zweiten Exchange SE (installiert auf Server 2025), Patchstand August 2025 funktioniert.
Windows Server 2025 mit Outlook auf Stand Oktober 2025 aktualisiert.
Keine Verbindung möglich auf Exchange SE Patchstand Oktober 2025.
Verbindung möglich auf Exchange SE Patchstand August 2025.
Windows Server 2022 mit Outlook 2024 LTSC funktioniert weiterhin auf beide Exchange SE Patchstände.
Gemäss KB5066835 (Known Issue Rollback) die Policy lokal installiert und aktiviert.
Hat auch nichts gebracht.
Verbindung zu Exchange SE Patchstand Oktober 2025 geht nicht.
Verbindung zu Exchange SE Patchstand August 2025 geht.
Falls jemand eine Knopf kennt oder ähnliches, der das Problem löst. Wäre super. Danke.
Bis jetzt keine Ahnung, wie ich es lösen kann.
Seit heute ist dieses nervige Problem wieder da.
Hat wohl bei MS wieder einer am Code rumgespielt, oder sind es die 30% KI-Code? Jedenfalls meganervig, dass man die Updates nicht selbst kontrollieren kann!
Es gab doch noch in den letzten Tagen gar keine Updates für den SE bzw. Outlook.
Also sollte das irgendetwas anderes sein.