Exchange 2010 - Autodiscover Fehler HTTP 500
Guten Morgen,
und herzliche Grüße vom Greenhorn an die fleißigen Helferlein. Ich bitte um Nachsicht, aber ich bin Exchange Quereinstiger um kam zum Exchange / SBS wie die Jungfrau zum Kind. Ich denke genug zu verstehen, dass ich den Sever am Laufen halten und sogar installieren kann, aber immer wieder fehlen mir Zusammenhänge. Von daher bitte ich um entsprechende Antworten und nicht gerade so a la "beim IIS den Haken SSL erzwingen rausnehmen... " - wobei diese Lösung das Problem nicht wirklich löst.
Aber von vorn:
Router mit geöffnetem Port 443 und 25 - beide zeigen auf den einzigen Server im Netz (für etwa 10 Clients, wovon 5 davon in der Domäne sind und die andere 5 von außen nur auf de Exchange zugreifen. Die stecken in einer eigenen - behelfsmäßig eingerichteten - SAMBA-Domain um wenigstens Datensicherung und servergespeicherte Profile benutzen zu können. Router hat DYNDNS mit eigener Domain: daheim.domain.tld
Server: SBS2011 mit EX2010SP3 mit gekauftem Zertifikat für daheim.domain.tld --> OWA funktioniert klaglos und ohne Zertifikatswarnung.
Bisherige Clients OL2013 und jünger machen kein Problem. Einfach beim Einrichten Server und Benutzername eingeben und auf auflösen klicken. Danach den Proxy eingetragen https://daheim.domain.tld und die Clients können auch von außerhalb auf den Exchange zugreifen.
OL2016 - der erste Client soll nun so ausgestattet werden - kann aber nur Autodiscover. Da bisher nicht wirklich benötigt, habe ich mich darum auch nicht gekümmert.
4 Tage googeln und Microsoft Connectivity Analyser brachte mich darauf den DNS von Domain.tld soweit zu verbiegen, dass _autodiscover._tcp@domain.tld auf daheim.domain.tld zeigt (und somit auch auf ein gültiges Zertifikat) - nur die Antwort vom Autodiscover ist nicht wie gewünscht. Alle anderen Ansätze wie Autodiscover.domain.tld sind unerwünscht, da das Zertifikat noch knapp 3 Jahre gültig ist und nicht geändert werden sollte (kostet ja auch!).
Hier nun ein Auszug vom Connectity Analyser:
Die Microsoft-Verbindungsuntersuchung versucht, eine XML-Antwort des AutoErmittlungsdiensts von URL https://daheim.domain.tld:443/Autodiscover/Autodiscover.xml für Benutzer email@domain.tld abzurufen.
Die Microsoft-Verbindungsuntersuchung konnte keine XML-Antwort von der AutoErmittlung abrufen.
Weitere Details
Die Antwort „HTTP 500“ wurde von Unknown zurückgegeben.
HTTP-Antwortkopfzeilen:
Content-Length: 0
Cache-Control: private
Date: Sun, 25 Oct 2015 08:02:26 GMT
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Verstrichene Zeit: 434 ms.
ausführlicher und in Farbe Bericht als PDF
Wie Ihr sehen könnt sind die Lösungsansätze, die man so im Internet findet alle nicht passend, denn ich komme ja bis am Zertifikat vorbei auf den Exchange, finde aber "nur" nicht die richtige Antwort, demnach muss lokal irgendwas verbogen sein.
Es wäre schön, wenn dem ein oder anderen was passendes einfallen würde, denn den Client kann ich auch noch mit Outlook 2013 installieren, aber langfristig sollen alle auf Win10pro und Office 2016 umgestellt werden...
Im Voraus bereits besten Dank an alle, die sich mit mir den Kopf zerbrechen.
Viele Grüße vom Schottenrock
P.S. Ich habe nur ein einziges Produktivsystem - das schließt Trial & Error von vorn herein aus, vor Allem, da sich die Datensicherung "nur" auf die Daten selbst und auf exportierte PST-Dateien bezieht - d.h. im Fall der Fälle müsste ich den kompletten Server neu aufsetzten und die gesicherten Daten ins neue System zurückspeichern. Das ist einem begrenzten Budget geschuldet - denn professionelle Backup-Lösungen verschlingen doch vierstellige Beträge und die Windows Backup Lösung kann nicht mehr als 2 TB.
und herzliche Grüße vom Greenhorn an die fleißigen Helferlein. Ich bitte um Nachsicht, aber ich bin Exchange Quereinstiger um kam zum Exchange / SBS wie die Jungfrau zum Kind. Ich denke genug zu verstehen, dass ich den Sever am Laufen halten und sogar installieren kann, aber immer wieder fehlen mir Zusammenhänge. Von daher bitte ich um entsprechende Antworten und nicht gerade so a la "beim IIS den Haken SSL erzwingen rausnehmen... " - wobei diese Lösung das Problem nicht wirklich löst.
Aber von vorn:
Router mit geöffnetem Port 443 und 25 - beide zeigen auf den einzigen Server im Netz (für etwa 10 Clients, wovon 5 davon in der Domäne sind und die andere 5 von außen nur auf de Exchange zugreifen. Die stecken in einer eigenen - behelfsmäßig eingerichteten - SAMBA-Domain um wenigstens Datensicherung und servergespeicherte Profile benutzen zu können. Router hat DYNDNS mit eigener Domain: daheim.domain.tld
Server: SBS2011 mit EX2010SP3 mit gekauftem Zertifikat für daheim.domain.tld --> OWA funktioniert klaglos und ohne Zertifikatswarnung.
Bisherige Clients OL2013 und jünger machen kein Problem. Einfach beim Einrichten Server und Benutzername eingeben und auf auflösen klicken. Danach den Proxy eingetragen https://daheim.domain.tld und die Clients können auch von außerhalb auf den Exchange zugreifen.
OL2016 - der erste Client soll nun so ausgestattet werden - kann aber nur Autodiscover. Da bisher nicht wirklich benötigt, habe ich mich darum auch nicht gekümmert.
4 Tage googeln und Microsoft Connectivity Analyser brachte mich darauf den DNS von Domain.tld soweit zu verbiegen, dass _autodiscover._tcp@domain.tld auf daheim.domain.tld zeigt (und somit auch auf ein gültiges Zertifikat) - nur die Antwort vom Autodiscover ist nicht wie gewünscht. Alle anderen Ansätze wie Autodiscover.domain.tld sind unerwünscht, da das Zertifikat noch knapp 3 Jahre gültig ist und nicht geändert werden sollte (kostet ja auch!).
Hier nun ein Auszug vom Connectity Analyser:
Die Microsoft-Verbindungsuntersuchung versucht, eine XML-Antwort des AutoErmittlungsdiensts von URL https://daheim.domain.tld:443/Autodiscover/Autodiscover.xml für Benutzer email@domain.tld abzurufen.
Die Microsoft-Verbindungsuntersuchung konnte keine XML-Antwort von der AutoErmittlung abrufen.
Weitere Details
Die Antwort „HTTP 500“ wurde von Unknown zurückgegeben.
HTTP-Antwortkopfzeilen:
Content-Length: 0
Cache-Control: private
Date: Sun, 25 Oct 2015 08:02:26 GMT
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Verstrichene Zeit: 434 ms.
ausführlicher und in Farbe Bericht als PDF
Wie Ihr sehen könnt sind die Lösungsansätze, die man so im Internet findet alle nicht passend, denn ich komme ja bis am Zertifikat vorbei auf den Exchange, finde aber "nur" nicht die richtige Antwort, demnach muss lokal irgendwas verbogen sein.
Es wäre schön, wenn dem ein oder anderen was passendes einfallen würde, denn den Client kann ich auch noch mit Outlook 2013 installieren, aber langfristig sollen alle auf Win10pro und Office 2016 umgestellt werden...
Im Voraus bereits besten Dank an alle, die sich mit mir den Kopf zerbrechen.
Viele Grüße vom Schottenrock
P.S. Ich habe nur ein einziges Produktivsystem - das schließt Trial & Error von vorn herein aus, vor Allem, da sich die Datensicherung "nur" auf die Daten selbst und auf exportierte PST-Dateien bezieht - d.h. im Fall der Fälle müsste ich den kompletten Server neu aufsetzten und die gesicherten Daten ins neue System zurückspeichern. Das ist einem begrenzten Budget geschuldet - denn professionelle Backup-Lösungen verschlingen doch vierstellige Beträge und die Windows Backup Lösung kann nicht mehr als 2 TB.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 286663
Url: https://administrator.de/contentid/286663
Ausgedruckt am: 22.11.2024 um 00:11 Uhr
12 Kommentare
Neuester Kommentar
Hallo Schottenrock,
erstmal toll, dass Du eine ausführliche Beschreibung des Problems aufgestellt hast.
Was passiert den, wenn Du von extern per Browser https://daheim.domain.tld:443/Autodiscover/Autodiscover.xml aufrufst. Es sollte eine User-Anmeldemaske aufgehen gefolgt von <Autodiscover><Response>... Werten in XML. Klingt so, als wenn er bei dir da aber gar keine Antwort bekommt. Content-Length: 0
:443 in bei https auch irgendwie doppelt-gemoppelt. Aber vermutlich egal.
Ansonsten kontrollier doch mal in der Exchange-console mit: Get-OwaVirtualDirectory |fl den Wert von externalURL.
Gruß
BBfreak
erstmal toll, dass Du eine ausführliche Beschreibung des Problems aufgestellt hast.
Was passiert den, wenn Du von extern per Browser https://daheim.domain.tld:443/Autodiscover/Autodiscover.xml aufrufst. Es sollte eine User-Anmeldemaske aufgehen gefolgt von <Autodiscover><Response>... Werten in XML. Klingt so, als wenn er bei dir da aber gar keine Antwort bekommt. Content-Length: 0
:443 in bei https auch irgendwie doppelt-gemoppelt. Aber vermutlich egal.
Ansonsten kontrollier doch mal in der Exchange-console mit: Get-OwaVirtualDirectory |fl den Wert von externalURL.
Gruß
BBfreak
Hallo Schottenrock,
ich vergleich die Daten nun einfach mal mit meinem laufenden Exchange 2010.
get-owavirtualdirectory |fl - internal und externalURL enden bei mir mit OWA ohne / am Ende...
Im IIS-Manager. Berechtigungen für AutoDiscover. Ist Auth-Benutzer (lesen), System und Administratoren (beide Vollzugriff)?
Die Bindung von Defaul Web Site hat https und das Zertifikat? Das den richtigen Namen hat?
Gruß
BBfreak
ich vergleich die Daten nun einfach mal mit meinem laufenden Exchange 2010.
get-owavirtualdirectory |fl - internal und externalURL enden bei mir mit OWA ohne / am Ende...
Im IIS-Manager. Berechtigungen für AutoDiscover. Ist Auth-Benutzer (lesen), System und Administratoren (beide Vollzugriff)?
Die Bindung von Defaul Web Site hat https und das Zertifikat? Das den richtigen Namen hat?
Gruß
BBfreak