Moin Moin,
ich bastle gerade an einer Testumgebeung. Ein DC, ein WIN 10 Rechner und ein Exchange2016.
Soweit ist alles eingerichtet. Das einzige ich habe nur ein selbstsigniertes Zertifikat eingebunden.
Nun ist es so, dass Outlook 2016 auf der Win 10 Maschine den Ex nicht findet. Siehe Bild.
nslookup auf autodiscover und mail funktioniert.
Ich habe noch ein paar Bilder vom Test-OutlookWebServices beigelegt. Ich hoffe Ihr habt ne Idee und könnt mir helfen. Die gesamte Testumgebung ist noch nicht online und läuft in einem internen Netz.
Danke
Hallo Denzel,
schau mal hier in das Whitepaper, da dürftest du die Lösung finden:
https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-autodiscover/
Gruß,
Frank
Hallo Frank,
eigentlich bin ich genau danach vorgegangen.
Ich habe das Whitepaper schon dreimal durchgearbeitet. Werde es Heute aber nochmal machen. Irgendwie scheine ich etwas zu übersehen.
Wenn ich über den Browser die Adresse: https://autodiscover.XXXXX.de/autodiscover/autodiscover.xml eingebe wird diese aufgelöst.
Es gibt auf alle Fälle eine Rückmeldung wie es ausgegangen ist. Vielleicht hast Du oder die ANderen ja noch ein paar Tips, falls ich es nicht finde.
Danke Denzel
Servus,
die beiden DNS-Timeouts aus den Screenshots sind auf jeden Fall schon mal nicht normal. Im letzten Test (SRV) ist zudem der falsche Host hinterlegt, hier müsste mail... stehen. Das selbstsignierte Zertifikat muss dann am Client importiert werden, die Namen auf dem Zertifikat müssen natürlich trotzdem zu den konfigurierten URLs passen.
Gruß,
Frank
Hallo Frank,
danke für die Rückmeldung.
Ich bin Heute leider nicht dazu gekommen weiter zu machen.
Aber wenn ich das im Whitepaper richtig verstanden habe, dann sollte der SRV Eintrag auf den Exchangeserver bzw. den Host A Eintrag für den Exchangeserver zeigen. Das habe ich so eingerichtet. Oder habe ich da was falsch verstanden?
Gruß Denzel
Hallo Frank,
ich habe nochmal alles kontrolliert. Outlook will einfach den Server nicht finden.
Nehme ich allerdings den Windows internen Mail-Client und gebe die Zugangsdaten ein funktioniert es sofort.
Vielleicht hilft Dir das ja mir vielleicht noch helfen zu können.
Gruß Denzel
Hi @andreas,
du hast autodiscover richtig engestellt und mail-Zugriffs-Adresse richtig eingestellt?
Dh der Exchange weiß, dass er unter mail.deinedomain.de erreichbar ist und das funktioniert auch mit OWA-Login?
autodiscover.deinedomain.de zeigt ebenfalls auf den Exchange Server?
Dann Srv-Eintrag löschen, der kommt bei Outlook-Abfrage sowieso ganz zum Schluss (nach bis zu 1 Minute erst). Outlook fragt zuerst den A/Cname-Record von autodiscover nach. Wenn dort der Exchange ist, muss es funktionieren.
Lets-Encrypt Zertifikat am Exchange noch einbinden mit mail+autodiscover-Hostnamen und im Exchange einbinden. Dann funktionierts.
Was anderes ist das SPN für Outlook in einer active-directory-Umgebung, dh ein Client, der als Computer in AD-Netzwerk ist und Zugriff auf AD-Datenbank hat. Dann liest Outlook die Email-Daten zu dem eingeloggten User per sog. SPN im AD nach und zeigt dir schon Anzeigename+Emailadresse. Wenn das nicht funktioniert, ist vielleicht der Benutzername ungleich der Email-Adresse oder dem Alias? Manchmal sucht Outlook dieses SPN nach und kanns dem Benutzer nicht zuordnen und hat einen Fehler.
Dann einfach händisch Email-Adresse+Passwort eingeben.
Falls du Email-Adresse mit .de als Loginnamen haben willst, musst du die deinedomain.de nur im Activedirectory als weitere Domäne angeben.
Oder hast du das Problem schon gelöst?
lg Roman
Hallo Roman,
danke für Deine Rückmeldung. Ich möchte Dir auf Deine Fragen bzw. Antworten mit Bildern Antworten. Siehe die Anhänge.
Hier einmal die Owa Abfrage:
Hier die DNS Einträge:
Hier das Zertifikat:
Und hier einmal autodiscover/owa und der Versuch Outlook zu bewegen sich vom Client an den Server anzumelden:
Vieleicht fällt Dir ja noch ein Fehler auf. Das Zertifikat ist übrigens nur selbstsigniert und alles läuft nur in eine Testumgebung ohne Internetansbindung.
Danke Denzel
Hi Denzel,
danke für die tollen Bilder!
Mir fällt nur beim letzten Bild auf, dass der Mailserver auch autodiscover.domain.de in der URL hat. Dh dem Mailserver seine Client-Zugriffe passieren auch über autodiscover.domain und nicht über mail.domain.
Theoretisch kann autodiscover für autodiscover und email zugleich genutzt werden, glaub ich. Insofern eventuell kein Problem. Aber komisch. Im 1. Bild von dir zeigst du das mit mail.domain an. Worauf ändert der IIS die URL wenn du zum Exchange-Server gehst?
Zertifikat ist als sicher eingestuft, also kanns kein Zertifikatsproblem sein. Egal ob internes Zertifikat oder öffentlich gültiges.
Kommt beim letzten Foto der letzte Punkt sofort mit der Meldung, dass es nicht geht oder kommt Punkt1+2 sofort und bei Punkt3 dauert es etwas und dann kommt die Meldung?
Falls die Meldung sofort kommt, muss Outlook sofort wissen, dass die Verbindung nicht möglich ist und sucht oder probiert gar nicht. Hier muss irgendwas einfaches übersehen werden.
Hast du die Exchange URLs mithilfe von Franks Script gemacht?
https://www.frankysweb.de/exchange-2016-urls-und-hostnamen-per-powershell-konfigurieren/
Troubleshooting Script https://www.frankysweb.de/?p=2576
eine simple Firewall-Portfreigabe am Exchange Server kanns nicht sein? Firewall ist deaktiviert?
Lg Roman
Übrigens die Fotos aus Beitrag1 deuten auch auf einen autodiscover-Problem hin. Eventuell nicht Dns-mäßig, sondern vielleicht exchange-seitig? Urls falsch geschrieben oder ähnliches?
Da heißt es immer, Autoermittlung fehlgeschlagen oder übersprungen. Hört sich mehr nach Exchange-Seite an, als Dns-Seite.
Hallo Roman,
hier das Ergebnis des Scripts. Erstellt wurden Exchange URL´s mit Frankys Script:
Beim Client findet Outlook sofort die Netzwerkverbindung, dann dauert es einen Augenblick bis der Benutzer erkannt wird der Fehler das der Server nicht gefunden wird kommt unmittelbar danach.
IIS muß ich noch prüfen
Hier die Ergebnisse des IIS. Sowohl Front wie Backend geben ein Zertifikatfehler aus.
FrontEnd löst wie folgt auf
BackEnd mit dieser Fehlermeldung
Hi Denzel,
danke für deine Screenshots. Ich sehe, dass hier auch steht, dass die web.config nicht gestartet werden konnte, weil kein Zugriff gegeben ist.
Ich würde selbst jetzt an dem Thema weitermachen, den Zugriff herzubekommen, aber andererseits könnte das mittlerweile auch nur mehr eine Nebeneffekt von dem richtigen Fehler sein.
Vielleicht sind wir hier zu weit im Thema: Verstehe ich das richtig, dass du einen neuen Server2016 erstellt hast. Dieser hat AD-Rolle bekommen und hat soweit funktioniert. Danach kam zusätzlich ein Exchange drauf und jetzt ist einfach das Thema gegeben? Oder Exch und AD getrennt voneinander aber immer Server2016?
Zertifikatsfehler erachte ich hier immer noch als nicht wichtig. Im Zertifikat ist vermutlich der Hostname des Exchange-Srv hinterlegt und du greifst auf localhost zu, also kein echtes Problem. Noch dazu hat die Zugriffsverweigerung nix mit Zertifikat zu tun.
Hab ein wenig gegooglet und es kam dazu (keine relevanten quellzeilen) ein Beitrag bei Frankysweb auf - https://www.frankysweb.de/exchange-2016-owa-funktioniert-nicht-asp-net-event-1310/
Taucht der Fehler auch im Eventlog auf?
Habe auch das hier zu gefunden, aber ich glaube, das kann nicht dein Problem sein https://www.tutorials.de/threads/konfigurationsfehler-kein-zugriff-auf-web-config.278354/ (Leerstellen in der web.config? Da hast du nie was verändert oder?)
Du hast geschrieben, das ganze ist eine interne Testumgebung - kann ich da einen Blick reinwerfen? Teamviewer oder Remotedesktop? Bei einer Testumgebung sollte ich nichts relevantes kaputt machen. Aber wenn das mit dem Exchange so weitergeht und du ständig nur bei Problemlösung als Verwendung bist, würde ich eher zu eine Neuinstallation von Exchange raten als dauernd Fehler suchen.
ADSI-Editor -> Exchange Infos alle hardcore rauslöschen und erneut den Exchange installieren auf dem Server.
Prerequisites laut Frankysweb installieren und abarbeiten und dann kanns die Fehler hier nicht mehr geben.
Das Ergebnis meines Checks würde ich im Forum anschließend schreiben. Bitte per private-message Daten schicken oder per Email (werom.at)
Vielleicht schaut @Franky hier auch vorbei und kennt sofort das Problem und die Lösung.
Hallo Roman,
ich das WE unterwegs deswegen erst so spät eine Rückmeldung.
Wenn es Dir recht ist melde ich mich Heute Abend noch zu Wort.
Gruß Denzel
Hallo,
so es hat doch etwas länger gedauert mit der Rückmeldung.
Nachdem ich eine zweite Testumgebung aufgebaut hatte und auch das nicht funktionierte habe ich überlegt, was bei den Testumgebungen nichtz geändert wurde.
Ich hatte einen Win19 Client, der schon vor der Erzeugung der Testumgebung als virtueller Testrechner auch dem Host lag genutzt um mit Outlook auf die Exchangeumgebung zuzugreifen.
Diesen habe ich nach diesen Überlegungen links liegen gelassen und einen neuen Client virtualisiert. Mit dem neuen Win10 Client funktionierte der Zugriff über Outlook auf den Exchangeserver dann problemlos.
Ursache war also ein irgendwo defekter Client!!!!!!!!!!!!!!!!!!!!!!!
Herzlichen Dank für Eure Rückmeldungen und die Unterstützung
Denzel
Hi Denzel! Danke für die Rückmeldung!
Aber wieso funktionierte dann die OWA/ECP Webseite auch nicht? Das kann nix mit dem Client zu tun haben?
Freut mich dass es jetzt funktioniert,
lg Roman