08.12.2024

1724

Autodiscover in Outlook schlägt fehl - Microsoft 365 korrekt eingestellt

Hallo zusammen,

ich habe ein Problem mit der automatischen Einrichtung eines Microsoft 365-Kontos in Outlook (neueste Version, Windows 11). Trotz korrekter DNS-Konfiguration und erfolgreicher Tests funktioniert Autodiscover in Outlook nicht wie erwartet.

Ausgangssituation:

Domain: `mydomain.tld`
DNS-Konfiguration:

CNAME: `autodiscover.mydomain.tld` → `autodiscover.outlook.com`
MX: `mydomain-tld.mail.protection.outlook.com`
Weitere Einträge (TXT, SPF, SRV, etc.) sind vollständig und korrekt, keine Fehler im Microsoft 365 Admin-Center.

Ergebnisse von Tests:

Der Microsoft Remote Connectivity Analyzer zeigt bei Autodiscover mit OAuth keine Fehler an.
`nslookup autodiscover.mydomain.tld` löst korrekt auf (`autodiscover.outlook.com` inkl. der Alias- und IP-Adressen).

Problem in Outlook:

Beim Erstellen eines neuen Profils (Systemsteuerung > Mail oder direkt in Outlook) poppt ein weißes Anmeldefenster kurz auf und verschwindet sofort wieder. Danach erscheint die Fehlermeldung, dass die Kontoeinstellungen nicht automatisch ermittelt werden konnten.
Wenn ich ein leeres Profil starte, werden Postfächer zunächst gesucht, aber keine gefunden. Ich kann die E-Mail-Adresse manuell eingeben und die Einrichtung funktioniert dann – allerdings scheinbar ohne korrekten Autodiscover-Prozess.

Bisher durchgeführte Maßnahmen:

Autodiscover-Einstellungen angepasst:

Registrierungseintrag `AlwaysUseMSOAuthForAutoDiscover` auf `1` gesetzt.
Weitere Schlüssel wie `ExcludeScpLookup` auf `1` gesetzt, um alternative Autodiscover-Methoden auszuschließen.

Caches gelöscht:

Lokale Autodiscover-Cache-Dateien (`%LOCALAPPDATA%\Microsoft\Outlook\Autodiscover\*.xml`) entfernt.
DNS-Cache geleert (`ipconfig /flushdns`).

Netzwerk geprüft:

Keine Proxy-Einstellungen aktiv, Firewall und Sicherheitssoftware testweise deaktiviert.
`Test-NetConnection autodiscover.outlook.com -Port 443` erfolgreich.

Outlook-Profile und Daten zurückgesetzt:

Profile über die Systemsteuerung gelöscht und lokale Daten in `%APPDATA%` sowie `%LOCALAPPDATA%` entfernt.

Fragen:

Warum wird der Autodiscover-Prozess in Outlook nicht korrekt durchlaufen, obwohl die DNS-Konfiguration und Remote-Tests erfolgreich sind?
Gibt es bekannte Probleme, die bei der modernen Authentifizierung (OAuth) in Verbindung mit Autodiscover auftreten?
Gibt es weitere Einstellungen oder Logs, die ich überprüfen sollte, um die Ursache einzugrenzen?

Vielen Dank im Voraus für eure Unterstützung! 😊

Beste Grüße

René

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 670055

Url: https://administrator.de/forum/autodiscover-in-outlook-schlaegt-fehl-microsoft-365-korrekt-eingestellt-670055.html

Ausgedruckt am: 15.01.2025 um 14:01 Uhr

13 Kommentare

Neuester Kommentar

Hallo,

hatte ich auch noch nicht.

https://www.reddit.com/r/Office365/comments/vo55d5/office365_login_windo ...

Da stehen ein paar Ideen.

Eigenschaften von Internet -> "Einstellungen automatisch erkennen" im letzten Post.

Ansonsten siehst ja selber die Beiträge. Fehler passt zu deinen: Erscheint kurz und dann "disapears".

https://superuser.com/questions/1349327/outlook-needs-password-but-dialo ...

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity, create a DWORD value named
EnableADAL and set it to zero.
Under the same registry key, create a DWORD value named DisableADALatopWAMOverride and set it to 1

Lieben Dank! Das hat aber nicht zum Erfolg geführt. Ich bin ratlos. Es funktioniert nur noch der "Trick" mit dem leeren Profil.

Wenn ich ein leeres Profil starte, werden Postfächer zunächst gesucht, aber keine gefunden. Ich kann die E-Mail-Adresse manuell eingeben und die Einrichtung funktioniert dann – allerdings scheinbar ohne korrekten Autodiscover-Prozess.

Und nun fällt mir ein weiteres Problem auf: Ich habe ein freigegebenes Postfach, welches ich über "Kontoeinstellungen > Weitere Einstellungen > Erweitert > Zusätzlich diese Postfächer öffnen > Hinzufügen" einbinden möchte. Im alten Profil ist für das betroffene Postfach die Schaltfläche "Hinzufügen" ausgegraut, während im neuen Profil für das gleiche Postfach aktiv. Ich werde immer verwirrter...

Ich kann die E-Mail-Adresse manuell eingeben und die Einrichtung funktioniert dann

Ist denn eine Email Adresse im AD an der richtigen Position hinterlegt?

Der Microsoft Remote Connectivity Analyzer zeigt bei Autodiscover mit OAuth keine Fehler an.

Dieser testet von extern. Intern im Netz können noch weitere DNS Hürden existieren, z.B. ein SCP Eintrag, wenn ihr vorher einen Exchange on Premisses hattet. Teste mal Outlook extern, um das mit einem Schwung auszuschließen.

Moin,
tritt das Problem nur bei einem Client auf?
Nur bei einem M365 Benutzer?
Nur Intern?
Was sagt nslookup autodiscover.mydomain.tld ?
Was sagt Test-NetConnection autodiscover.mydomain.tld -Port 443 ?

Klingt für mich weniger nach einem Autodiscover-Fehler, sondern vielleicht ein Windows-Problem. Schonmal alle M365-Verbindungen "gekillt"?
- Office-Programm z.B. Word starten, rechts oben abmelden, ggfs. mehrmals abmelden
- Teams starten und (mehrmals) abmelden
- in der Systemsteuerung prüfen ob der Rechner mit Azure verbunden ist > abmelden und trennen
- in "localappdata% die Ordner löschen: OneAuth, TokenBroker, IdentityCache
- wenn das alles nicht hilft Windows Profil löschen und neu anmelden

MfG

Danke, ich habe alles nochmals systematisch überprüft un kann einen Autodiscover-Fehler mittlerweile ausschließen.

Der Fehler taucht bei ziemlich allen Clients auf und zwar in unterschiedlichen Netzwerken. Einzelne Gemeinsamkeit ist die Nutzung von Exchange-Online im Rahmen von Microsoft 365. Nun habe ich einen (hässlichen) Weg gefunden, mit ihm kann ich aber einigermaßen (über)leben:

Neues Profil erstellen – dabei schlägt die Einrichtung der E-MAil-Adresse fehl. Dennoch Profil speichern und nicht verwerfen.
Outlook mit dem neuen (leeren) Profil starten und warten, bis keine E-Mail-Adresse gefunden wird
E-Mail-Adresse manuell eingeben und wieder warten.

Eins habe ich vergessen, hier zu beschreiben und ich weiß nicht, inwiefern das wichtig ist: Die getesteten Netzwerken laufen unter Windows Server 2022 Datacenter mit einem lokalen AD. Das AD ist nicht mit Azure verbunden und es wird demnach nicht damit synchronisiert.

Hi!

Zitat von @temuco:
Eins habe ich vergessen, hier zu beschreiben und ich weiß nicht, inwiefern das wichtig ist: Die getesteten Netzwerken laufen unter Windows Server 2022 Datacenter mit einem lokalen AD. Das AD ist nicht mit Azure verbunden und es wird demnach nicht damit synchronisiert.

Das sollte(TM) keine Rolle spielen, genaueres kann man dir aber erst dann sagen:

Zitat von @support-m:
Nur Intern?
Was sagt nslookup autodiscover.mydomain.tld ?
Was sagt Test-NetConnection autodiscover.mydomain.tld -Port 443 ?

Und mit deinem internen (AD) DNS Server alles in Ordnung? Was sagt dcdiag und dcdiag /test:dns ?

MfG

Die getesteten Netzwerken laufen unter Windows Server 2022 Datacenter mit einem lokalen AD. Das AD ist nicht mit Azure verbunden und es wird demnach nicht damit synchronisiert.

Wenn das AD den mit dem selben Name endet, wie die Email Adresse, gibt es bestimmt ein DNS Problem.

Nun habe ich einen (hässlichen) Weg gefunden, mit ihm kann ich aber einigermaßen (über)leben

Das kann dir an andere Stellen noch Kopfschmerzen bereiten z.B. Kalender Freigaben, Einladungen, gesharete Postfächer usw...

Wenn das AD den mit dem selben Name endet, wie die Email Adresse, gibt es bestimmt ein DNS Problem.

Das ist nicht der Fall.

Das kann dir an andere Stellen noch Kopfschmerzen bereiten z.B. Kalender Freigaben, Einladungen, gesharete Postfächer usw...

Das ganze fiel erst auf, als wir ein geteiltes Postfach einrichten wollten. Vielleicht sind wir auch aus dem Grund komplett durcheinander geraten, weil Exchange-Online Ewigkeiten brauchte, bis das geteilte Postfach richtig in Outlook ankam. Wir dachten zunächst, dass dies nicht funktionieren würde. Ganz krass war der Versand neuer E.Mails aus dem geteilten Postfach: Hat man die Absenderadresse manuell eingegeben oder von der DropDown-Liste ausgewählt, schlug der Versand zunächst fehl. Erst als ich die Adresse von der globalen Adressliste auswählte, ging es.

Nach ca. 6 Stunden war es auch möglich, die im DropDown-Feld angezeigte Absenderadresse fehlerfrei zu verwenden. Das wiederholte sich auf anderen Rechnern bzw. mit anderen Benutzerprofilen.

Intuitiv geht sicher anders.

Was sagt nslookup autodiscover.mydomain.tld ?

nslookup autodiscover.mydomain.tld
Server:  DC.mydomain.local
Address:  192.168.70.207

Nicht autorisierende Antwort:
Name:    autod.ms-acdc-autod.office.com
Addresses:  2603:1026:c0d:76::8
          2603:1026:c0d:1001::8
          2603:1026:c0d:1020::8
          52.98.253.40
          40.99.149.104
          52.98.252.232
Aliases:  autodiscover.mydomain.tld
          autodiscover.outlook.com
          atod-g2.tm-4.office.com

Was sagt Test-NetConnection autodiscover.mydomain.tld -Port 443 ?

Test-NetConnection autodiscover.mydomain.tld -Port 443
WARNING: TCP connect to (40.99.157.24 : 443) failed
WARNING: TCP connect to (52.98.252.88 : 443) failed
WARNING: TCP connect to (40.99.149.184 : 443) failed

ComputerName           : autodiscover.mydomain.tld
RemoteAddress          : 40.99.157.24
RemotePort             : 443
InterfaceAlias         : Ethernet
SourceAddress          : 192.168.70.5
PingSucceeded          : True
PingReplyDetails (RTT) : 14 ms
TcpTestSucceeded       : False

Und mit deinem internen (AD) DNS Server alles in Ordnung? Was sagt dcdiag und dcdiag /test:dns ?

dcdiag

Verzeichnisserverdiagnose

Anfangssetup wird ausgeführt:
   Der Homeserver wird gesucht...
   Homeserver = DC
   * Identifizierte AD-Gesamtstruktur.
   Sammeln der Ausgangsinformationen abgeschlossen.

Erforderliche Anfangstests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\DC
      Starting test: Connectivity
         ......................... DC hat den Test Connectivity bestanden.

Primärtests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\DC
      Starting test: Advertising
         ......................... DC hat den Test Advertising bestanden.
      Starting test: FrsEvent
         ......................... DC hat den Test FrsEvent bestanden.
      Starting test: DFSREvent
         ......................... DC hat den Test DFSREvent bestanden.
      Starting test: SysVolCheck
         ......................... DC hat den Test SysVolCheck bestanden.
      Starting test: KccEvent
         ......................... DC hat den Test KccEvent bestanden.
      Starting test: KnowsOfRoleHolders
         ......................... DC hat den Test KnowsOfRoleHolders bestanden.
      Starting test: MachineAccount
         ......................... DC hat den Test MachineAccount bestanden.
      Starting test: NCSecDesc
         ......................... DC hat den Test NCSecDesc bestanden.
      Starting test: NetLogons
         ......................... DC hat den Test NetLogons bestanden.
      Starting test: ObjectsReplicated
         ......................... DC hat den Test ObjectsReplicated bestanden.
      Starting test: Replications
         ......................... DC hat den Test Replications bestanden.
      Starting test: RidManager
         ......................... DC hat den Test RidManager bestanden.
      Starting test: Services
         ......................... DC hat den Test Services bestanden.
      Starting test: SystemLog
         Fehler. Ereignis-ID: 0x0000272C
            Erstellungszeitpunkt: 12/11/2024   09:47:31
            Ereigniszeichenfolge:
            DCOM konnte über keines der konfigurierten Protokolle mit dem Computer 8.8.8.8 kommunizieren. Während der Aktivierung von CLSID {8BC3F05E-D86B-11D0-A075-00C04FB68820} von PID     2184 (C:\Windows\system32\dcdiag.exe) angefordert.
         ......................... Der Test SystemLog für DC ist fehlgeschlagen.
      Starting test: VerifyReferences
         ......................... DC hat den Test VerifyReferences bestanden.


   Partitionstests werden ausgeführt auf: DomainDnsZones
      Starting test: CheckSDRefDom
         ......................... DomainDnsZones hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... DomainDnsZones hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: ForestDnsZones
      Starting test: CheckSDRefDom
         ......................... ForestDnsZones hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... ForestDnsZones hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: Schema
      Starting test: CheckSDRefDom
         ......................... Schema hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... Schema hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: Configuration
      Starting test: CheckSDRefDom
         ......................... Configuration hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... Configuration hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: mydomain
      Starting test: CheckSDRefDom
         ......................... mydomain hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... mydomain hat den Test CrossRefValidation bestanden.

   Unternehmenstests werden ausgeführt auf: mydomain.local
      Starting test: LocatorCheck
         ......................... mydomain.local hat den Test LocatorCheck bestanden.
      Starting test: Intersite
         ......................... mydomain.local hat den Test Intersite bestanden.

dcdiag /test:dns

Verzeichnisserverdiagnose

Anfangssetup wird ausgeführt:
   Der Homeserver wird gesucht...
   Homeserver = DC
   * Identifizierte AD-Gesamtstruktur.
   Sammeln der Ausgangsinformationen abgeschlossen.

Erforderliche Anfangstests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\DC
      Starting test: Connectivity
         ......................... DC hat den Test Connectivity bestanden.

Primärtests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\DC

      Starting test: DNS

         DNS-Tests werden ordnungsgemäß ausgeführt. Warten Sie einige Minuten...
         ......................... DC hat den Test DNS bestanden.

   Partitionstests werden ausgeführt auf: DomainDnsZones

   Partitionstests werden ausgeführt auf: ForestDnsZones

   Partitionstests werden ausgeführt auf: Schema

   Partitionstests werden ausgeführt auf: Configuration

   Partitionstests werden ausgeführt auf: mydomain

   Unternehmenstests werden ausgeführt auf: mydomain.local
      Starting test: DNS
         ......................... mydomain.local hat den Test DNS bestanden.

Zitat von @temuco:

nslookup autodiscover.mydomain.tld
Server:  DC.mydomain.local
Address:  192.168.70.207

Nicht autorisierende Antwort:
Name:    autod.ms-acdc-autod.office.com
Addresses:  2603:1026:c0d:76::8
          2603:1026:c0d:1001::8
          2603:1026:c0d:1020::8
          52.98.253.40
          40.99.149.104
          52.98.252.232
Aliases:  autodiscover.mydomain.tld
          autodiscover.outlook.com
          atod-g2.tm-4.office.com

Ok, das sieht gut aus.

Zitat von @temuco:

Test-NetConnection autodiscover.mydomain.tld -Port 443
WARNING: TCP connect to (40.99.157.24 : 443) failed
WARNING: TCP connect to (52.98.252.88 : 443) failed
WARNING: TCP connect to (40.99.149.184 : 443) failed

ComputerName           : autodiscover.mydomain.tld
RemoteAddress          : 40.99.157.24
RemotePort             : 443
InterfaceAlias         : Ethernet
SourceAddress          : 192.168.70.5
PingSucceeded          : True
PingReplyDetails (RTT) : 14 ms
TcpTestSucceeded       : False

Ok, das war mein Fehler. HTTPS Zugriff wird so natürlich nicht klappen. Sieht jedenfalls auch gut aus.

Zitat von @temuco:

Starting test: SystemLog
         Fehler. Ereignis-ID: 0x0000272C
            Erstellungszeitpunkt: 12/11/2024   09:47:31
            Ereigniszeichenfolge:
            DCOM konnte über keines der konfigurierten Protokolle mit dem Computer 8.8.8.8 kommunizieren. Während der Aktivierung von CLSID {8BC3F05E-D86B-11D0-A075-00C04FB68820} von PID     2184 (C:\Windows\system32\dcdiag.exe) angefordert.
         ......................... Der Test SystemLog für DC ist fehlgeschlagen.

Hmm, was hat der Google-DNS bei dir zu suchen? Wo wird der genutzt? Was sagt ein ipconfig /all auf einem der Clients?

Zitat von @temuco:

         ......................... mydomain.local hat den Test DNS bestanden.

Ok, sieht auch gut aus.

Ok, das nächste was ich prüfen würde, gibt es irgendwelche Gruppenrichtlinien, die Microsoft Konten blockieren oder ähnliches?
Habt ihr eine Firewall im Einsatz, die DNS Filtering macht bzw. Content Filtering (SSL Injection)? Einen Reverse Proxy? Was für ein AV Programm nutzt ihr, macht das SSL Checks?
Wenn du ein Outlook offen hast und mit gedrücker STRG-Taste auf die Outlook Sybolleiste drückst und Verbindungsstatus anklickst, wird dort bei allen Einträgen der korrekte externe Servername angezeigt? https://outlook.office365.com ?

MfG

Wenn du ein Outlook offen hast und mit gedrücker STRG-Taste auf die Outlook Sybolleiste drückst und Verbindungsstatus anklickst, wird dort bei allen Einträgen der korrekte externe Servername angezeigt?

Und steht dort bei Verbindungsfehlern überall eine "0"?

Frage Microsoft Microsoft Office Outlook Mail Exchange Server

Mehr von temuco

Langsamer VPN-Zugriff nur bei einem virtuellen Servertemuco - 8 Kommentare

Lets Encrypt und DNS-Verwaltung in Plesk auf Strato VPS - Brauche Hilfe!temuco - 8 Kommentare

Windows 11 - hohe Systembelastungtemuco - 12 Kommentare

Eigene Dokumentverwaltung revisionssicher machen - ungefähre Kosten?temuco - 20 Kommentare

Heiß diskutiert