Exchange 2016 Autodiscover Login

  • Hallo zusammen,


    ein schöner Fehler zu Dokumentationszwecken. Umzug Exchange 2010 zu Exchange 2016.

    Server Versionen:

    Windows Server 2008R2 mit Exchange 2010, 14.3.382.0

    Windows Server 2016 mit Exchange 2016 15.1.2106.2


    Outlook's im Haus:

    Office 2013 Pro Plus

    Office 2016 Standard

    Office 2019 H&B


    Nach dem verschieben von Postfächern Exchange 2010 zu Exchange 2016 erscheint bei den Outlook Clients ab version 2016 ein Loginfenster.
    Es ist keine Verbindung mehr mit Outlook möglich. Egal ob Extern oder Intern.


    Owa, ActiveSync, Mobildevices geht alles. Auch ältere Outlookversionen vor 2016 gehen ohne Problem.


    Nach 4h raten, habe ich die Datenpakete mitgeschnitten (tcpdump) und konnte in Auth über outlook.office365.com sehen. Der Client fragt wohl möglich
    nur noch direkt die Office Wolke.


    Nach dem man dann weiß, wonach man googlen muss, ist das hier dann ganz logisch:

    https://kb.intermedia.net/article/39713


    Aber! Es kann ja nicht an Outlook direkt liegen. Es muss ja ein zusammenspiel von Exchange2016 und >= Outlook 2016 sein! Ich hab vorher auch Clients

    neu aufgesetzt und hatte das Problem bisher nicht.


    Unsere Firmendomain, ist auch leider bei M$ bekannt, da dort unter einer Email unsere VL's liegens. Ich vermute es ist die Kombination aus den drei Faktoren:

    • Exchange 2016 move
    • Outlook>=2016
    • Domäne ist M$ bekannt

    Was halten die Experten davon?


    Vg
    Alex

  • Hi igfas,


    die Antwort haben wir in deinem anderen Thread doch bereits gegeben.
    Hast du ein IISRESET oder zumindest den Autodiscover Pool auf dem Exchange 2016 neu gestartet, nach dem die Postfächer auf den 2016 verschoben wurden?

    Outlook frägt in den neuen Versionen (Ich weiß gerade nicht sicher ab welcher es dazu gekommen ist), immer in die Cloud, wenn er lokal nicht fündig wird.
    Normal sollte er (kurze Ausführung :D) zunächst den Autodiscover aus dem SCP ziehen (Domänenmitglieder), dann auf die Autodiscover URL und wenn nichts gefunden wird frägt er in die CLoud.

    Dies kannst du auch per Registry unterbinden (wie du ja bereits geschrieben hast)


    Die genaue Rangfolge ist im Netz oft zu finden, wie ein Autodiscover abläuft.

    Grüße

    Phil

  • Hi,


    @Hast du ein IISRESET oder zumindest den Autodiscover Pool auf dem Exchange 2016 neu gestartet, nach dem die Postfächer auf den 2016 verschoben wurden?


    Ich hatte auch beide Server neu gestartet keine Besserung. Daher kann ich Autodiscover ausschließen. Ich hatte auf beiden Servern die URLs nochmal neu gesetzt. Neustart. DNS geprüft. Per DIG die DNS geprüft. Auch Extern. Servicerecords geprüft. SCP in den Serviceknoten geprüft. Alles korrekt.


    Der Client fragt erst nach der Cloud. Hab ich noch nicht gehabt ... Auf iPhone Android hatte das Autodiscover Problemlos geklappt. Auch mit 2013....


    Ich vermute dass Zusammenspiel von den drei Faktoren oben.

    • Offizieller Beitrag

    Aber! Es kann ja nicht an Outlook direkt liegen.

    Ach, das weißt du, weil es beim Exchange 2010 funktioniert? ;) Der macht im Zweifel einfach einen Fallback auf TCP/Mapi und gut ist. Setz den entsprechenden Registrywert doch einfach per GPO und gut ist. Microsoft schraubt soviel am Autodiscover und an den Outlooks, da hast du heute das Verhalten und nach dem nächsten Patch ein leicht anderes.

  • Also irgendwas passt hier nicht zusammen.


    Auf meine Frage hast du doch geantwortet, dass du den Server mehrfach neu gestartet hast, somit wird der IIS neu gestartet (Dienst Neustart) durchgeführt und der Anwendungspool zurückgesetzt und es hat "keine" Besserung gebracht. Laut deiner Aussage.


    Also ändert auch die 5 Min zahl nicht viel daran.

    NorbertFe

    hat dir eigentlich alles gesagt. Es ändert sich sowieso ständig. Genau so, dass Microsoft das Autodiscover gegen die CLoud eingebaut hat und am Anfang niemand wusste ;).

  • Das eine hat ja mit dem anderen nicht zu tun. Mit dem nicht verfügbaren shared mailboxen, ja kann ich mir mit dem Anwendungspool vorstellen. Das Problem mitdem Autodiscover dürfte damit nicht zu lösen sein.


    Wir setzten den Key, halt auch Extern und gut ist. Nur d00f, wenn du User USA/Frankreich/Türkei und Japan hast.... welch ein Spaß.

  • Die Shared Box Thematik ist aber in deinem anderen Thread hier zu finden :).


    Keine lange Diskussionen. Wie du geschrieben hast verteilst den Reg Key und die Welt ist in Ordnung.
    Extern hin oder her, wenn es ist wie du sagst, dass es direkt mit O365 verbindet, muss er Key an jedem Client gesetzt sein.


    Nur d00f, wenn du User USA/Frankreich/Türkei und Japan hast.... welch ein Spaß.

    Klingt nach spaß in den nächsten Wochen.


    Ein schönes Wochenende.