RC<-->RC 0 Geschrieben 8. März 2018 Melden Teilen Geschrieben 8. März 2018 Hallo Liebe Gemeinde, wie im Thema leicht angedeutet, hier die Konkrete Fehlermeldung: Es ist dabei völlig egal ob ich es mit Outlook 2010 oder 2016 teste. Es betrifft vereinzelte Locationen, was heißt, das es an Rechnern eines Standortes nicht auftritt, aber dafür an einem anderen Standort Das Testpostfach liegt dazu auf dem Exchange 2016 welcher auf einem Strato Root liegt ! Die Fehlermeldung klickt man weg, und alles läuft wie gewohnt, bis zum neustarten von Outlook. Das Zertifikat des Exchange welches selbst signiert ist, wird per GPO ausgerollt, natürlich an alle Standorte! Habe an den Rechnern an denen es auftritt mit den Rechnern wo es nicht auftrifft verglichen. Die Zertifikate sind die selben (Vertrauenswürdige Stammzertifizierungsstellen) was Fingerabdruck und Namen usw. betrifft. Wenn ich die OWA öffne und mir das Zertifikat anschaue, ist das auch das selbe was ausgerollt wird ! Das *Name.dyndns.org* welches in der Fehlermeldung steht, ist im Zertifikat unter Alternativer Antragstellernamen eingetragen. Über Dyndns.org gehen die Rechner zum Exchange nicht mehr (rührt aus alten Zeiten, und wird anderweitig noch gebraucht) da er ja direkt mit fester IP Ansprechbar ist. Sollte ich das aus dem Zertifikat heraus nehmen ? Ist das der Fehler ? Könnt ihr mir einen Tipp geben ? In Foren les ich, das dass Zertifikat nicht im Zertifikatsspeicher des Rechners liegt. Das ist es aber, und das richtige dazu. Wie gesagt, in manchen Standorten funktioniert ist regelkonform. Die Zertifikate werden in jeden Standort ausgerollt. Die Rechner bei denen es nicht funktioniert haben die Zertifikate, wie auch die, bei denen es funktioniert ! Vielen dank. Rolf ! Zitieren Link zu diesem Kommentar
testperson 1.680 Geschrieben 8. März 2018 Melden Teilen Geschrieben 8. März 2018 Hi, wie sind denn die virtuellen Verzeichnisse und die AutoDiscoverServiceInternalUri konfiguriert? Wie sind die Outlook Anywhere Hostnames konfiguriert? Was ergibt ein "Get-OutlookProvider"? Und warum installiert man einen Exchange auf einem Root Server bei Strato? Ist der auch DC? Gruß Jan Zitieren Link zu diesem Kommentar
Nobbyaushb 1.471 Geschrieben 8. März 2018 Melden Teilen Geschrieben 8. März 2018 Und Zertifikate mit dyndns drin sind mit absoluter Sicherheit selber ausgestellt und primär nicht vertrauenswürdig. Schreibe doch mal mehr Details zu der Umgebung. Zitieren Link zu diesem Kommentar
RC<-->RC 0 Geschrieben 8. März 2018 Autor Melden Teilen Geschrieben 8. März 2018 Die sind auf die externe Subdomain eingestellt, mit verwais auf die Externe IP des Exchange. https://Subdomainname/Autodiscover/Autodiscover.xml" Get-OutlookProvider ist mit keinem Zertifikat hinterlegt ! Outlook-Anywhere auch Name der Subdomain mit dem Verwais auf die öffentliche IP des Exchange Warum, weil wir unseren Exchange gern über eine Öffentliche IP erreichbar machen wollten. Zur Umgebung. 5 Standorte, bisher in jedem ein Exchange, die dann abgelöst werden sollen. Der öffentliche Exchange ist per OWA/ECP usw richtig konfiguriert. Er ist per VPN an unsere Domäne angebunden und kein DC ! Was mir aufgefallen ist, bei den Standorten bei denen der Fehler mit dem Dyndns nicht kommt, zeigt er im Outlook unten rechts (Verbunden mit Exchange an und in den Kontoeinstellungen unter anzeige des Servers MailboxID@domain.de) an Bei den Standorten wo es nicht funktioniert, steht (Online mit Exchange) und unter den Kontoeinstellungen unter anzeige des Servers (Subdomain/mapi/emsmdb/MailboxID@domain.de) Beide Seiten mit jeweilis Outlook 2010 probiert ! Die scheinen unterschiedliche wege zum Postfach zu gehen oder seh ich das Falsch ?! Hoffe ich habe mich halbwegs klar ausgedruckt . Grüße, Rolf ! Zitieren Link zu diesem Kommentar
testperson 1.680 Geschrieben 9. März 2018 Melden Teilen Geschrieben 9. März 2018 Und was steht im Client in den Microsoft Exchange-Proxyeinstellungen (Outlook Konoteinstellungen -> Ändern -> Weitere Einstellungen -> Verbindung -> Verbindungen... HTTP herstellen)? Zitieren Link zu diesem Kommentar
RC<-->RC 0 Geschrieben 10. März 2018 Autor Melden Teilen Geschrieben 10. März 2018 (bearbeitet) Moin Moin. Dort steht im Prinzip das was dort stehen soll. Also unter HTTP Proxyserver steht (https://subdomain.de --> nicht *.dyndns.org) wie im Fehler zu sehen ist Das interessante, unter Outlook 2010 in einem anderen Standort steht genau das selbe, dort kommt aber nichts von der Fehlermeldung *.dnydns.org ! Zum anderen, da der Exchange sowohl intern über VPN als auch extern über die Subdomain mit seiner externen IP erreichbar ist, würde ich gern das die Clients in den Standorten wie bei Outlook 2010 zu sehen vorrangig über HTTP/HTTPS gehen, also über die Subdomain. Wenn ich mir bei Outlook 2016 aber den Verbindungsstatus ansehe, wird mir dort der Lokale Domänen Pfad zum Exchange angezeigt, und nicht wie bei Outlook 2010 die Subdomain ?! Kann mir das jemand erklären ?Geht er bei Outlook 2016 bevorzugt den internen, bzw den schnelleren Weg, und warum ist das bei Outlook 2010 nicht so ? Was mir noch auffiel: unter dem Verbindungsstatus bei Outlook 2010 sowohl an den standorten wo der Fehler kommt und dort wo er nicht kommt, steht als Servername (Lange-Zahl-mit-Buchstaben@domainname.de) DNS Auflösung bisschen falsch ? Noch etwas: Wenn ich : Get-WebServicesVirtualDirectory -server servername| fl *url* eingebe Ist die Interne URL : https://Servername.Domäne.local Ist die externe URL: https://ÖffentlicherServername.Domäne.de Wenn ich die interne URL = externe URL ändere, würden doch alle Clients nicht mehr über den internen Weg gehen (Outlook2016) sondern nur noch den öffentlichen Weg oder ? Viele Grüsse, Rolf ! bearbeitet 10. März 2018 von RC<-->RC Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.