none
Exchange 2010 mit Office 2019 und Autodiscover RRS feed

  • Frage

  • Hallo

    Mit Office 2019 kamen leider nicht nur neue Features hinzu, sondern auch ein essentielles (zumindest für uns) wurde entfernt :(
    Nämlich die Möglichkeit bei der Einrichtung eines Exchange-Kontos die Server-Adresse manuell angeben zu können.

    Sicherlich werden wahrscheinlich 98% der Admins dieses Feature nicht vermissen, da sie vermutlich eine musterhafte IT-/Exchange-Infrastruktur haben. Unsere IT-Infrastruktur ist sicherlich alles andere als gewöhnlich, doch historisch bedingt lief diese jetzt über 15 Jahre zuverlässig und vor allem auch günstig! ;)
    (und wie heißt es so schön - never touch a running system ;) )

    Jetzt ist natürlich der Punkt gekommen, wo man sich wirklich ernsthaft damit beschäftigen muss, ob es Sinn macht unsere IT-Infrastruktur beizubehalten oder doch Zeit ist diese grundlegend umzustrukturieren.
    Vorweg: Pauschale, knappe und nicht ganz qualifizierte Aussagen wie "hohl dir einfach eine feste IP-Adresse oder wechsle auf einen Exchange 365 Account und gut ist..." können sich diejenigen sparen. Das wäre das gleiche als wenn ich als Leihe oder aus Bequemlichkeit in einem Thread eines Autoforum mit dem Titel "Hilfe, mein Auto springt nicht mehr an!" den Tipp gebe "kauf Dir ein neues Auto!". Jemand technisch visierter würde zuerst mal den Tipp geben, check mal die Batterie, Zündkerzen etc.
    Erst dann würde er einem nahelegen sich vielleicht sich mal mit dem Gedanken zu beschäftigen ein neues Auto zu kaufen aus den und den Gründen.

    Jetzt bin ich etwas abgeschweift. Entschuldigt.

    Der Server, um des es sich hier handelt, besitzt (immer noch) lediglich eine dynamische IP-Adresse! (in der Startup-Phase wurde versucht die Ausgaben so gering als möglich zu halten). Die eingehenden Mails wurden einfach via einem POP3-Konnektor von externen E-Mail-Postfächern (hoster) geholt.
    Wichtig: Hoster stellt die Domain 'company.de' bereit. Im Exchange haben die einzelnen Personen natürlich auch E-Mail-Adressen in der folgenden Form: xy@company.de

    Eigentlich gab es bis heute keine technischen Gründe, welche es zwingend nötig machten die IT-Infrastruktur komplett zu überarbeiten.

    Interner Anbindung der Postfächer funktioniert natürlich tipi topi, da es ja im Prinzip eine saubere/best practice IT-Infrastruktur ist.

    Bei der Anbindung von remote (Smartphones, Home PC) musste man natürlich etwas "tricksen", da die Adressauflösung von company.de natürlich an den Hoster geht und nicht an den eigenen Server. War aber im Prinzip auch kein Problem, da man bei der Einrichtung von Outlook einen anderen Server angeben konnte (bzw. bei sonstigen E-Mail-Clients auf einem Smartphone). Also wurde hier einfach company.freeddns.org verwendet. Funktionierte mit einem Self-Signed-SAN Zertifikat dann aber ohne Probleme.

    Aber genau die Angabe eines beliebigen Servers gibt es bei Outlook 365/2019 nicht mehr :/
    Es wird jetzt nur noch zu dem Server aufgelöst, der in der Mail-Adresse steckt. Somit landen die Autodiscover-Anfragen beim Hoster und kommen natürlich nie bei uns an.

    Die erste naheliegende Idee von mir war, bei Outlook dann eben die Form xy@company.freeddns.org zu verwenden und diese den einzelnen internen Postfächern als weitere SMTP-Adresse bekannt zu machen. Funktioniert aber irgendwie nicht wirklich.

    Darum die Frage an hardcore admins: Kann man EINFACH das System so modifizieren, dass Outlook unseren Server (wieder) findet? Denkt ihr das wäre technisch überhaupt machbar? Oder wo seht ihr Probleme oder Randeffekte? (denke die meisten haben diesbezüglich wahrscheinlich noch nie Gedanken darüber gemacht ;) )

    Also mein Ziel ist es jetzt nicht 1 Woche zu experimentieren (da es dann wirklich günstiger ist - auf die Arbeitszeit bezogen - einen ganz normalen öffentlichen Mailserver bereit zu stellen mit fester IP, MX-Record und Zertifikaten) und nicht den kompletten Server zu "verbiegen".

    Das allereinfachste wäre natürlich wieder "irgendwie" die abweichende Serveradresse eingeben zu können. Witzigerweise bin ich bei Versuchen über diesen Dialog gestolpert. Ich weiss zwar nicht mehr wie ich das genau geschafft habe, aber bei irgendwelchen Fehlern fliegt der Assistent auf diese Seite. Sie ist also noch da, wird nur nicht mehr angezeigt! :)

    VG



    Donnerstag, 28. März 2019 20:53

Antworten

  • Moin,

    jetzt erst mal ne pauschale Antwort, die ich mir auch sparen könnte, denn Du weißt das ja auch selber: Outlook 2019 mit Exchange 2010 ist nicht supported und das bedeutet soviel wie: nicht getestet durch den Hersteller.

    Wenn Du eine sauber funktionierende DynDNS-Auflösung hast und das öffentliche DNS flexibel genug ist, kannst Du statt des A-Eintrages autodiscover.domain.com auf den SRV-Eintrag ausweichen, der dann auf Deine DynDNS-Adresse verweist. Das SSL-Zertifikat, das da präsentiert wird, muss natürlich den DynDNS-Namen mit beinhalten.

    Und das i-Tüpfelchen wäre dann, über GPO bzw. LocalGPO die Autodiscover-Suche per A-Eintrag totzutreten und nur SCP und SRV-Eintrag drin zu lassen. Alternativ kannst Du alle Wege tot treten und dich auf Local XML zurückziehen, in der dann wieder die DynDNS-Adresse stehen würde. Die müsstest Du dann auch intern auflösen, zumindest bei Devices, die mal intern und mal extern sind. Und die externen URLs sollten natürlich auf allen virtuellen Verzeichnissen auf DynDNS gesetzt sein.

    Übrigens: IIRC, wurde das von Dir vermisste Feature nicht erst in Outlook 2019 sondern bereits mit 2016, wenn nicht sogar mit 2013 abgeschafft.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Also ich habe es nun doch nicht mit dem SRV Eintrag im DNS realisiert. Ging natürlich auch, allerdings gibt Outlook bei dieser Variante eine Umleitungswarnung aus. Wäre im Prinzip nicht schlimm und es kann auch eine Checkbox gesetzt werden, dass die Meldung in Zukunft nicht mehr angezeigt wird. Doch mit einem CNAME-Alias auf die DynDNS Adresse funktionierts auch und das ohne Meldung ;)

    Aber Danke für den Denkanstoß in die richtige Richtung. Dadurch wusste ich in welches "Kapitel" ich mich wieder einlesen musste. Im Prinzip hätte ich auch selbst drauf kommen können, da man ja weiss welche Nodes Autodiscover ja prüft. Aber oftmals ist die Lösung einfacher als man denkt ;)

    Ach ja, der Grund wieso es früher funktionierte war nicht der Unterschied altes und neues Office (auch mit dem alten funktionierte somit eine direkte Adressauflösung nicht durch die fehlenden DNS Einträge). Es fiel allerdings nur deshalb nicht auf, da bei Outlook immer explizit bei Einrichtung des Postfachs RPCoverHTTP aktiviert wurde.

    Donnerstag, 11. April 2019 06:38

Alle Antworten

  • Moin,

    jetzt erst mal ne pauschale Antwort, die ich mir auch sparen könnte, denn Du weißt das ja auch selber: Outlook 2019 mit Exchange 2010 ist nicht supported und das bedeutet soviel wie: nicht getestet durch den Hersteller.

    Wenn Du eine sauber funktionierende DynDNS-Auflösung hast und das öffentliche DNS flexibel genug ist, kannst Du statt des A-Eintrages autodiscover.domain.com auf den SRV-Eintrag ausweichen, der dann auf Deine DynDNS-Adresse verweist. Das SSL-Zertifikat, das da präsentiert wird, muss natürlich den DynDNS-Namen mit beinhalten.

    Und das i-Tüpfelchen wäre dann, über GPO bzw. LocalGPO die Autodiscover-Suche per A-Eintrag totzutreten und nur SCP und SRV-Eintrag drin zu lassen. Alternativ kannst Du alle Wege tot treten und dich auf Local XML zurückziehen, in der dann wieder die DynDNS-Adresse stehen würde. Die müsstest Du dann auch intern auflösen, zumindest bei Devices, die mal intern und mal extern sind. Und die externen URLs sollten natürlich auf allen virtuellen Verzeichnissen auf DynDNS gesetzt sein.

    Übrigens: IIRC, wurde das von Dir vermisste Feature nicht erst in Outlook 2019 sondern bereits mit 2016, wenn nicht sogar mit 2013 abgeschafft.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Donnerstag, 28. März 2019 21:53
  • Statt DynDns kann man auch "spdns" verwenden. Die sind noch kostenlos.

    Mit dem Autodiscover war das aber auch schon in früheren Versionen  so, dass Outlook selber das nicht mehr gemacht hat. Allerdings gibt es ggf. noch das Mail-cpl, im Office-Ordner, bei mir z.B.:

    C:\Program Files (x86)\Microsoft Office\root\Office16\MLCFG32.CPL

    Dort kann man ein neues Konto mit manueller Konfig einrichten. Dies hat bei mir in 2016 zu Exchange 2010 prima funktioniert.

    Freitag, 29. März 2019 15:50
  • C:\Program Files (x86)\Microsoft Office\root\Office16\MLCFG32.CPL

    Dort kann man ein neues Konto mit manueller Konfig einrichten. Dies hat bei mir in 2016 zu Exchange 2010 prima funktioniert.

    Kenne ich und mache ich auch. Allerdings müssten diese beide auf den selben Assistenten/DLL zurückgreifen. Auf alle Fälle habe ich noch keinen unterschiedliche Vorgehensweise entdeckt.
    Aber Danke für den Tipp
    Freitag, 5. April 2019 08:28
  • Wenn Du eine sauber funktionierende DynDNS-Auflösung hast und das öffentliche DNS flexibel genug ist, kannst Du statt des A-Eintrages autodiscover.domain.com auf den SRV-Eintrag ausweichen, der dann auf Deine DynDNS-Adresse verweist. Das SSL-Zertifikat, das da präsentiert wird, muss natürlich den DynDNS-Namen mit beinhalten.

    Das mit dem SRV-Record war ein guter Tipp!
    Wenn ich dies jetzt technisch korrekt verstehe müsste dieser auf dem Hoster domain.de eingerichtet werden, oder? Der zeigt dann auf den Service _autodiscover._tcp.domain.freeddns.org. Anschließend sollte man dann als einzurichtendes Postfach wieder ganz normal bei Outlook "postfach@domain.de" eingeben können und Outlook sollte unseren Exchange Server wieder finden.





    Freitag, 5. April 2019 08:33
  • Moin,

    nein, genau umgekehrt. Der SRV lautet auf _autodiscover._tcp.domain.de und verweist auf domain.freeddns.org . Insofern ja, beim Hoster für domain.de einrichten.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 5. April 2019 10:20
  • Moin,

    nein, genau umgekehrt. Der SRV lautet auf _autodiscover._tcp.domain.de und verweist auf domain.freeddns.org.

    Hmm - hab ich doch gesagt

    Aber sehe schon, wir haben uns verstanden *lol*

    Samstag, 6. April 2019 11:16
  • Moin,

    jetzt erst mal ne pauschale Antwort, die ich mir auch sparen könnte, denn Du weißt das ja auch selber: Outlook 2019 mit Exchange 2010 ist nicht supported und das bedeutet soviel wie: nicht getestet durch den Hersteller.

    Wenn Du eine sauber funktionierende DynDNS-Auflösung hast und das öffentliche DNS flexibel genug ist, kannst Du statt des A-Eintrages autodiscover.domain.com auf den SRV-Eintrag ausweichen, der dann auf Deine DynDNS-Adresse verweist. Das SSL-Zertifikat, das da präsentiert wird, muss natürlich den DynDNS-Namen mit beinhalten.

    Und das i-Tüpfelchen wäre dann, über GPO bzw. LocalGPO die Autodiscover-Suche per A-Eintrag totzutreten und nur SCP und SRV-Eintrag drin zu lassen. Alternativ kannst Du alle Wege tot treten und dich auf Local XML zurückziehen, in der dann wieder die DynDNS-Adresse stehen würde. Die müsstest Du dann auch intern auflösen, zumindest bei Devices, die mal intern und mal extern sind. Und die externen URLs sollten natürlich auf allen virtuellen Verzeichnissen auf DynDNS gesetzt sein.

    Übrigens: IIRC, wurde das von Dir vermisste Feature nicht erst in Outlook 2019 sondern bereits mit 2016, wenn nicht sogar mit 2013 abgeschafft.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Also ich habe es nun doch nicht mit dem SRV Eintrag im DNS realisiert. Ging natürlich auch, allerdings gibt Outlook bei dieser Variante eine Umleitungswarnung aus. Wäre im Prinzip nicht schlimm und es kann auch eine Checkbox gesetzt werden, dass die Meldung in Zukunft nicht mehr angezeigt wird. Doch mit einem CNAME-Alias auf die DynDNS Adresse funktionierts auch und das ohne Meldung ;)

    Aber Danke für den Denkanstoß in die richtige Richtung. Dadurch wusste ich in welches "Kapitel" ich mich wieder einlesen musste. Im Prinzip hätte ich auch selbst drauf kommen können, da man ja weiss welche Nodes Autodiscover ja prüft. Aber oftmals ist die Lösung einfacher als man denkt ;)

    Ach ja, der Grund wieso es früher funktionierte war nicht der Unterschied altes und neues Office (auch mit dem alten funktionierte somit eine direkte Adressauflösung nicht durch die fehlenden DNS Einträge). Es fiel allerdings nur deshalb nicht auf, da bei Outlook immer explizit bei Einrichtung des Postfachs RPCoverHTTP aktiviert wurde.

    Donnerstag, 11. April 2019 06:38