Outlook verbindet sich innerhalb der Domain nicht mit dem Exchange Server 2016

[Oldory 0]

Hallo zusammen,

ich habe einen sehr skurrilen Fehler, und hoffe ihr könnt mir weiterhelfen.

Ich update momentan von EX2010 auf EX2016 (ein Server  hat noch Windows Server 2008 R2 mit Exchange 2010 SP3 der andere Windows Server 2016 mit Exchange 2016).

Soweit hat auch alles super geklappt, jedoch gibt es ein Problem bei der Verbindung zwischen Outlook und Exchange, wenn der PC worauf sich das Outlook befindet in der selben Domain ist wie der Exchange Server.

Ist der PC/VM nicht in der Domain, klappt die Verbindung ohne jegliche Probleme.

-Gruppenrichtlinien habe ich keine aktiv.

-Autodiscover gegen Office365 ist deaktiviert über registry

-der _srv eintrag im DNS Server wurde auch schon entfern, da der Verdacht bestand das dieser nicht ordentlich funktioniert.

 

Eventuell hilft das Autodiscovery Protokoll beim debugen: https://ibb.co/cf7dsy

 

 

Hat noch jemand Ideen was es sein könnte?

 

Vielen Dank vorab :)

 

[NorbertFe 2.035]

Der Service Record wird bei einem Domain PC sowieso nie abgefragt (jedenfalls nicht intern). Welchen Fehler erhältst du? Wie weit bist du bei der Migration? Wo zeigen die SCPs und die sonstigen URL denn jetzt aktuell hin?

[Sanches 22]

Hi,

 

in deinem verkn. Screenshot liest sich häufig "../autodiscover.xml - Fehlgeschlagen (0x....".

Da würde ich an deiner Stelle mal anknüpfen.

Dabei hilft evtl. auch die Beantwortung der Fragen von Norbert ...

 

BTW: Zertifikat passt zu den eingesetzten URLs?

 

Gruß Sebastian

[Oldory 0]

Hallo,

wenn ich den Autodiscovery Test von Outlook benutze kommen die HTTP Fehler 401 wie man in dem Bild sieht was ich im ersten Beitrag gepostet habe.

Wenn ich es mit Outlook direkt teste, kommt immer wieder die Benutzername und Passwort Abfrage, auch wenn ich den Hacken bei Passwort Speichern setze.

Wenn das Anmelden aus der Domain raus funktioniert, kann ich alle Mailboxen umziehen und bin mit der Migration soweit fertig. Im nächsten Schritt muss dann das HA Konstrukt wieder aufgebaut werden (DAG).

Die SCPs (sind ja die ClientAccessService richtig) und auch alle anderen URLs (Virtuelle Verzeichnisse) verweisen auf den Eintrag mx.DOMAIN.de und dieser wiederum hat als IP Adresse im DNS Server unseren Exchange 2016 Server eingetragen.

 

Edit:

Zertifikat ist auf mx.DOMAIN.de ausgestellt und hat als alternativ namen autodiscover ebenso wie die Servernamen beider Exchange Server.

Und wenn es am Zertifikat liegt müsste ja auch die Verbindung von außerhalb der Domain zu Problemen führen oder täusche ich mich hier?

bearbeitet 19. Juni 2018 von Oldory

[NorbertFe 2.035]

Deswegen setzt man den Haken auch nicht, der übrigens ohne c geschrieben wird. Und wenn alles richtig wäre, dann hättest du keine Probleme. Wir können hier nicht sehen was du konfiguriert hast. Wenn du also sagst, dass alles richtig ist, was möchtest du von uns hören. Poste bitte mal die Ausgabe alle URLs und scps (von mir aus anonymisiert was die Domain angeht). Nutzt ihr intern einen proxyserver? Falls ja, ist der Exchange als lokale Ausnahme definiert? Mir fällt grad ein, letzteres dürfte wahrscheinlich stimmen, weil es ja von extern funktioniert.

bearbeitet 19. Juni 2018 von NorbertFe

[Oldory 0]

Entschuldigung für das zu viele "c".

Ich hoffe ich habe an alle Einträge gedacht: https://ibb.co/fwguzd

Sollte etwas Fehlen reiche ich das natürlich gerne nach. 

Wir nutzen keinen Proxyserver nein.

[NorbertFe 2.035]

OK, sieht erstmal gut aus. Beim Outlook Anywhere müßtest du noch die internal URL nachliefern, die gibts seit Exchange 2013 auch dafür. Ansonsten schreibt sich Prof. Farnsworth mit R. ;)

Passiert das mit neuen Profilen, oder bei der Postfachverschiebung? Bei letzterem bitte mal den IISAppPool für Autodiscover auf dem Exchange 2016 neustarten. Gibt es intern auch einen Autodiscover Eintrag?

[Oldory 0]

Der Outlook Anywhere Internal Eintrag für den 2016 Exchange ist gesetzt, den hatte ich aus versehen nicht im printout mit drinnen

Identity                           : FANSWORTH\Rpc (Default Web Site)
InternalHostname                   : mx.DOMAIN.de
InternalClientAuthenticationMethod : Ntlm
InternalClientsRequireSsl          : True

Ja das mit dem Farnsworth und fansworth ist so ein Fehler meines Kollegens. 

Ich habe ein neues Postfach erstellt sowohl ein bestehendes verschoben, bei beiden besteht der selbe Fehler.

Was meinst du mit "gibt es intern einen Autodiscover Eintrag"? Es gibt Einträge auf dem DNS Servern wenn du das meinst ja, oder muss ich es noch irgendwo bekannt machen?

 

[andreas.l 0]

Hi,

Wie wird denn intern Autodiscover gemacht? Mit einem DNS A-Record (autodiscover.externalemaildomain.de), oder einem CNAME?

Von extern wird Autodiscover via A-Record (Subdomain), oder CNAME gemacht?

Welche Outlook Clients nutzt ihr?

Grüße

 

 

[testperson 1.680]

Hi,

 

wenn intern = innerhalb der Domäne bedeutet, dann mittels SCP (Service Connection Point) aus dem Active Directory. Clients die nicht in der Domäne sind bzw. von extern nutzen DNS. Ein Umfangreiches Whitepaper findest du z.B. hier: https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-autodiscover/

 

Gruß

Jan

[andreas.l 0]

vor 23 Minuten schrieb testperson:

Hi,

 

wenn intern = innerhalb der Domäne bedeutet, dann mittels SCP (Service Connection Point) aus dem Active Directory. Clients die nicht in der Domäne sind bzw. von extern nutzen DNS. Ein Umfangreiches Whitepaper findest du z.B. hier: https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-autodiscover/

 

Gruß

Jan

Hi Jan,

bezieht sich deine Antwort auf meine Antwort? Ich kenne Franks Whitepaper schon fast auswendig, danke dennoch ;-).

Ich habe bisher bei so gut wie allen Kunden mithilfe von Split DNS gearbeitet, da sich oft der interne Domainname von der E-Mail Domain unterscheidet.

Damit dann nicht alle DNS Einträge der externen Domain intern auch gepflegt werden müssen, habe ich jeweils eine DNS Zone namens "autodiscover.domainname.de" und eine für "exchange.domainname.de" angelegt.

In diesen dann jeweils einen neuen Host A-Eintrag erstellt ohne Namen, nur mit IP Adresse. -> nie wieder Autodiscover Probleme gehabt...

Und Zugriff der Clients funktioniert extern, wie intern mit derselben URL, sofern diese auf dem Exchange exakt gleich konfiguriert wurden.

Grüße

Andreas

bearbeitet 21. Juni 2018 von andreas.l

[testperson 1.680]

vor 18 Minuten schrieb andreas.l:

bezieht sich deine Antwort auf meine Antwort?

Ja. Hatte den Rest vom Thread irgendwie gar nicht mitbekommen.

Und so wie du es machst, ist das durchaus Best Practise.

[andreas.l 0]

Super, dann hab ich die letzten Jahre ja alles richtig gemacht

Dann warten wir mal auf die Antwort des Thread Erstellers...

 

[Oldory 0]

Hallo zusammen,

wir machen kein Split DNS weil unsere Domain gleich wie unsere Mail/Web URLs heißen.

Für externe haben wir den DNS Eintrag autodiscover.DOMAIN.de für Interne einen SCP beide verweißen auf autodiscover.DOMAIN.de als A-Record.

Franks Whitepaper kenne ich durch aus, und habe mich sogar an sein HowTo Upgrade gehalten, doch leider finde ich meinen Fehler dennoch nicht. Ich werde es nochmal ausdrucken und stück für stück durchgehen.

 

Was ich als nächstes testen wollte ist mal alle "Internen" URLs direkt auf den neuen Exchange zu legen und es dann zu testen.

Sprich für

Extern dann: mx.DOMAIN.de -> A.B.C.132

Intern dann: fansworth.DOMAIN.de -> A.B.C.132

Ich werde mal Berichten ob das geholfen hat.

[NorbertFe 2.035]

Konfiguriere doch bitte mal Split-DNS für die beiden Exchangenamen (mx.domain.tld und autodiscover.domain.tld). Wäre nicht die erste Firewall/Router Kombination, die Probleme macht, wenn man über die selbe IP wieder zurück will. ;)