autodiscover intern

Autodiscover ist im Office365 "hart verdrahtet" (hat man mir so gesagt)

Da kann man per Registry Abhilfe schaffen: (eigene Einträge ergänzen, "falsche" deaktivieren.

Ich bin hier leider nicht zu 100% sicher das das dein Problem löst, aber evetl. hilft es ja doch weiter. Kurzes Feedback wäre klasse.

Folgende Text in.reg Datei speichern, ausführen (Solche Sachen nat. immer auf eigene Verantwortung!)

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]

"ExcludeExplicitO365Endpoint"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover\RedirectServers]

"autodiscover-s.outlook.com"=hex(0):

"autodiscover-s.partner.outlook.cn"=hex(0):

"autodiscover-s.outlook.de"=hex(0):

"autodiscover-s.office365.us"=hex(0):

"autodiscover.hotmail.com"=hex(0):

"xxx.xx.xx"=hex(0):

Vielleicht noch die Frage warum Autodiscover?

Mailkonten in aktuellen Outlooks richte ich IMMER über die Systemsteuerung und dann "Mail (Microsoft Outlook) (32-Bit)" ein. Hier habe ich manuelle Setup-Möglichkeiten.

Wenn ich aber erst Outlook starte und dann das Konto einrichten möchte klappt das nie

Wahrscheinlich aus o.g. Grund (autodiscover)

Stimmt das Ergebnis wenn du ein ping oder tracert auf den internen (Split)DNS EIntrag machst?

Wenn es von extern geht, von intern aber nicht hast Du ein Problem mit Deinem split DNS und nicht mit dem Autodiscover.

Das Autodiscover dient eh nur dazu beim ersten einrichten eines Clients die Tipperei zum Teil zu ersparen.

Daraus ergibt sich auch, das wenn Du 8443 beim internen Zugriff nutzen willst, du es natürlich auch beim Zugriff von extern tun musst wenn sich ein und das selbe Gerät abwechselnd intern oder extern befinden kann.

Die nächste Frage wäre ob Du Den SRV Eintrag auf Deinem Split DNS für intern ebenfalls eingerichtet hast?

Viele derartige Probleme lassen sich mit einem Loopback bzw FullNat im Router umgehen, der schickt Anfragen von intern mit der eigernen externen URL in den eigenen Router über die Portweiterleitung im eigenen Router zum ensprechendem (Ziel-)Gerät. Entweder der Router hat eine entsrechende Einstellung (Lancom, Bintec, Speedports, oder in modernen Firewall UTP (Sophos, Securepoint) muss man das in der Firewall abbilden. Um DNS muss ich mir dann keine Gedanken mehr machen. Split DNS kann auch schnell zur allgemeinen Verwirrung beitragen. Ist ja auch ein wenig getrickst. Nur weils geht muss ichs ja nicht unbedingt machen.

Beispiel:

Im eigenen Netz ist der Davidserver: 192.168.2.11

Aus dem Lan gebe ich z. B. im Smartphone welches per WLAN im eigenen Netz angemeldet ist ein mail.<eigeneMaildomain>:8443

Im Portforwarding des Routers steht:

Port 8443 wird weitergeleitet an den Mailserver 192.168.2.11

Im Router ist ein Loopback (bzw FullNAT in der UTP) für das eigenen LAN eingerichtet

Im Loopback schickt der Router die Anfrage durch den Loop in die Portweiterleitung.

Im FullNAT wird im Router bei der Anfrage ein S(ource)NAT Eintrag erstellt und wir gleich wieder noch im UTP zum D(estination)NAT

Wenns der Router nicht packt, muss der halt neu.

olise Bei einer Securepoint kannst du auch einen Eintrag im Nameserver machen, das eine externe Adresse deinserver.spdns.de intern auf die interne IP des David Servers auflöst. So geht das auch.

Wenn du extern Port 8443 benutzt, müsste man die Webbox natürlich intern auch über 8443 betreiben.

in der Webbox.ini Parameter "httpsport="

Zitat von ComputerManni

Viele derartige Probleme lassen sich mit einem Loopback bzw FullNat im Router umgehen, der schickt Anfragen von intern mit der eigernen externen URL in den eigenen Router über die Portweiterleitung im eigenen Router zum ensprechendem (Ziel-)Gerät.

Nur weil das geht bedeutet das allerdings nicht das dieser Workaround sauberer wäre als eine korrekt aufgesetzte Split-DNS Umgebung

Und wenn man sein Split-DNS sauber aufsetzt ist das am Ende auch keine Verwirrung

Zitat von ComputerManni

Split DNS kann auch schnell zur allgemeinen Verwirrung beitragen. Ist ja auch ein wenig getrickst. Nur weils geht muss ichs ja nicht unbedingt machen.

Denn Split DNS ist ganz anders als Full-Nat eben gar nicht getrickst.

Wenn man Split-DNS in so einer Situation vermeiden und wirklich sauber arbeiten will lässt man Geräte die sich auch extern herumtreiben auch nie wirklich ins interne Netz, sondern immer nur in eine Mobile Devices DMZ von wo aus sie immer durch die innere Firewall auf interne Dienste zugreifen müssen, in dem Fall haben sie allerdings auch keine Notwendigkeit für ein Split-DNS oder ein Full-NAT.

Wer allerdings gerne mal den Postlagernden Versand des David Servers nutzt tut dennoch gut daran Split-DNS korrekt aufzusetzen und den https Porst seines David Servers intern gleich zu konfigurieren wie von außen, denn sonst wird es umständlich und erfordert Handarbeit (oder eben so einen Workaround wie Full-NAT) sich intern mal fix die postlagernden Anhänge anzuschauen, was besonders doof bei Nachrichten ist welche auch einen internen Empfänger haben, der die Nachricht nicht nur zur Kenntnis, sondern die Anhänge öffnen können soll. (wären es nur interne Empfänger würde man ja auf Postlagernd ganz verzichten, ist aber auch nur ein externer dabei der das zwingend erforderlich macht muss man die Pille halt schlucken, aber das nur am Rande bemerkt )

Zusammenfassend:
Full-Nat ist eigentlich der größere Hack, der manchmal allerdings einfacher einzurichten ist, wenn man in seiner Umgebung schlicht kein Split-DNS einrichten kann und sollte daher auch nicht als "bessere" Lösung für Fehler beim einrichten einer Split-DNS Umgebung propagiert werden

Olise: Wo liegt denn der A-Record und MX der Autodiscover URL?

Riawie: Es gibt hier ja nicht DIE Lösung, und ob es getrickst ist oder nicht, kommt auf den Blickwinkel an. Natürlich kann man es als getrickst betrachten, wenn ein interner Host über eine externe URL aufgelöst wird. Entscheident ist, das der Admin weis was er tut.