NorbertFe 2.217 Geschrieben 20. Oktober 2021 Melden Geschrieben 20. Oktober 2021 Am 20.10.2021 um 16:46 schrieb roccomarcy: dass das Zertifikat ein Multidomain und kein SAN-Zertifikat ist. Mehr Wo is denn da der Unterschied? ;) Zitieren
roccomarcy 20 Geschrieben 20. Oktober 2021 Autor Melden Geschrieben 20. Oktober 2021 (bearbeitet) Gibt es einen Unterschied? Ich bin nur die Seite des Anbieters für unsere Zertifikate überflogen und da wurde zwischen Multidomain und SAN-Zertifikaten unterschieden. Habe mir aber das Zertifikat noch einmal angeschaut, dort wird unter Alternativer Antragsstellername beide Adressen (mail. und autodiscover.) aufgelistet. //Edit: Brauche ich in dem Zertifikat eigtl. alle Namen der Domänen, die verarbeitet werden? Wir haben ca. 10 unterschiedliche E-Maildomänen, die den einzelnen Anwendern als primäre SMTP-Adresse zugeordnet ist. bearbeitet 20. Oktober 2021 von roccomarcy Zitieren
cj_berlin 1.447 Geschrieben 20. Oktober 2021 Melden Geschrieben 20. Oktober 2021 Am 20.10.2021 um 16:46 schrieb roccomarcy: Ich glaube, dass das Zertifikat ein Multidomain und kein SAN-Zertifikat ist. Mehr Was wäre denn der Unterschied? Ein SSL-Zertifikat hat einen Namen im Subject und einen oder mehrere Namen im SAN. "Multidomain" ist ein Marketing-Begriff und bedeutet nur, dass die SANs aus unterschiedlichen DNS-Domains stammen können. Die Frage ist: Stehen die beiden Namen, die Dein Server hat (mail.... und autodiscover...) im SAN? Falls ja, alles gut. Du kannst aber auch das Zertifikat zurücktauschen und das Vorherige verwenden. Zitieren
testperson 1.804 Geschrieben 20. Oktober 2021 Melden Geschrieben 20. Oktober 2021 Hi, Am 20.10.2021 um 16:56 schrieb roccomarcy: Wir haben ca. 10 unterschiedliche E-Maildomänen, die den einzelnen Anwendern als primäre SMTP-Adresse zugeordnet ist. Mehr kommt drauf an. ;) Bei Let's Encrypt würde ich die weiteren Domains einfach mit ins Zertifikat packen. Bei kostenpflichtigen Anbietern kann man sicherlich überlegen und das bspw. der http-Redirect lösen. Gruß Jan Zitieren
NorbertFe 2.217 Geschrieben 20. Oktober 2021 Melden Geschrieben 20. Oktober 2021 Am 20.10.2021 um 16:56 schrieb roccomarcy: Gibt es einen Unterschied? Mehr Weiß nicht, du meintest doch es gibt einen. ;) Am 20.10.2021 um 16:56 schrieb roccomarcy: Brauche ich in dem Zertifikat eigtl. alle Namen der Domänen, die verarbeitet werden? Wir haben ca. 10 unterschiedliche E-Maildomänen, die den einzelnen Anwendern als primäre SMTP-Adresse zugeordnet ist. Mehr Dann brauchst du 11 Namen (10x autodiscover plus einmal generischer Name vermutlich in einer der zehn Domains) alternativ 2 Namen und 9x http Redirect. Zitieren
roccomarcy 20 Geschrieben 20. Oktober 2021 Autor Melden Geschrieben 20. Oktober 2021 (bearbeitet) Am 20.10.2021 um 18:49 schrieb NorbertFe: Weiß nicht, du meintest doch es gibt einen. ;) Mehr Ich denke nicht, habe mich zwischendurch auch fix schlaugelesen. Wie oben schon geschrieben, war nur etwas verwirrt, weil es auf der Seite unseres Anbieters für die Zertifikate so positioniert wurde. cj_berlin hat es ja auch noch einmal aufgegriffen. :) Am 20.10.2021 um 18:35 schrieb testperson: Hi, kommt drauf an. ;) Bei Let's Encrypt würde ich die weiteren Domains einfach mit ins Zertifikat packen. Bei kostenpflichtigen Anbietern kann man sicherlich überlegen und das bspw. der http-Redirect lösen. Gruß Jan Mehr Okay, den http-redirect könnte ich ja von außen lösen. Habe vor dem Exchange einen Reverse-Proxy, der das abfackeln könnte. Aber für die internen Anfragen? Bekomme beim Starten von Outlook auch noch eine Zertifikatsfehlermeldung. Hinter dem geschwärzten steht der interne FQDN des Exchange-Servers. Das Zertifikat ist allerdings für die neue Adresse. Habe mir dann via den folgenden Befehlen noch einmal alle URLs ausgeben lassen, aber das passt soweit. Es steht eigtl. überall nur noch die externe Adresse drin (mail.firma.de) und unter ClientAccessServer ist die autodiscover.firma.de-Adresse konfiguriert. Get-OwaVirtualDirectory -Server exch | fl *url* Get-EcpVirtualDirectory -Server exch | fl *url* Get-OABVirtualDirectory -Server exch | fl *url* Get-ActiveSyncVirtualDirectory -Server exch | fl *url* Get-WEbServicesVirtualDirectory -Server exch | fl *url* Get-ClientAccessServer -Identity exch | fl autodiscover* Get-OutlookAnywhere -Server exch | fl *hostname IIS hatte ich auch neugestartet. Habe dort durch Zufall noch gefunden, dass in der Default Web Site eine HTTP-Umleitung auf https://mail.firma.de/owa/ hinterlegt war. Die habe ich auch entfernt. Dennoch keine Besserung, o.g. Fehlermeldung kommt weiterhin - könnte damit auch leben bis zur Migration, allerdings bleibt die Funktion vom Abwesenheitsassistenten und der Anzeige von freigegebenen Kalendern unverändert. Wie Norbert schon meinte, scheint irgendwas am Autodiscover zu klemmen. Das Cmdlet Test-OutlookWebServices habe ich auch einmal durchlaufen lassen, bis auf folgender Eintrag war alles erfolgreich. Inhaltlich gleich wie die o.g. Fehlermeldung unter Outlook. Gibt es noch einen Punkt wo ich mehr Logs generieren oder was ich überprüfen könnte? Habe jetzt erstmal die alte Konfiguration wiederhergestellt, das geht ja dank PowerShell recht zügig und die Funktion ist nicht eingeschränkt. bearbeitet 20. Oktober 2021 von roccomarcy Zitieren
NorbertFe 2.217 Geschrieben 20. Oktober 2021 Melden Geschrieben 20. Oktober 2021 (bearbeitet) Dein scp zeigt auf den internen Namen. Das musst du ändern. Set-clientaccessservice -AutoDiscoverServiceInternalUri ausserdem fehlt noch die Konfiguration vom mapi Virtual Directory. bearbeitet 20. Oktober 2021 von NorbertFe Zitieren
cj_berlin 1.447 Geschrieben 20. Oktober 2021 Melden Geschrieben 20. Oktober 2021 Am 20.10.2021 um 19:20 schrieb NorbertFe: ausserdem fehlt noch die Konfiguration vom mapi Virtual Directory. Mehr Auf Exchange 2010? Zitieren
roccomarcy 20 Geschrieben 20. Oktober 2021 Autor Melden Geschrieben 20. Oktober 2021 (bearbeitet) Am 20.10.2021 um 19:20 schrieb NorbertFe: Dein scp zeigt auf den internen Namen. Das musst du ändern. Set-clientaccessservice -AutoDiscoverServiceInternalUri Mehr Habe ich auch durchgeführt, ist in meiner Befehlsfolge hinterlegt. Get-OwaVirtualDirectory -Server exch | Set-OwaVirtualDirectory -InternalUrl 'https://mail.firma.de/owa' Get-EcpVirtualDirectory -Server exch | Set-EcpVirtualDirectory -InternalUrl 'https://mail.firma.de/ecp' Get-OABVirtualDirectory -Server exch | Set-OABVirtualDirectory -InternalURL 'https://mail.firma.de/OAB' Get-ActiveSyncVirtualDirectory -Server exch | Set-ActiveSyncVirtualDirectory -InternalURL 'https://mail.firma.de/Microsoft-Server-ActiveSync' Get-WEbServicesVirtualDirectory -Server exch | Set-WEbServicesVirtualDirectory -InternalURL 'https://mail.firma.de/EWS/Exchange.asmx'Get-ClientAccessServer -Identity exch | Set-ClientAccessServer -AutodiscoverServiceInternalUri 'https://autodiscover.firma.de/autodiscover/autodiscover.xml' Get-OutlookAnywhere -Server exch | Set-OutlookAnywhere -ExternalHostname mail.firma.de Get-WEbServicesVirtualDirectory -Server exch | Set-WEbServicesVirtualDirectory -InternalURL 'https://mail.firma.de/EWS/Exchange.asmx' -InternalNLBBypassUrl 'https://mail.firma.de/EWS/Exchange.asmx' Enable-ExchangeCertificate -Thumbprint Abcd1234 -Service IIS, IMAP, SMTP, POP Die externen URLs habe ich nicht angefasst, die standen ja bereits auf der korrekten Adresse. Am 20.10.2021 um 19:26 schrieb cj_berlin: Auf Exchange 2010? Mehr Nee, das Verzeichnis hab ich ja (noch) nicht. :) bearbeitet 20. Oktober 2021 von roccomarcy Zitieren
NorbertFe 2.217 Geschrieben 20. Oktober 2021 Melden Geschrieben 20. Oktober 2021 Achso wer hat denn noch so uralte Sch… ;) warum setzt du den ecp auf autodiscover? Dann muss man ja nochmal zu Mail Switchen, dann kannst auch gleich Mail reinschreiben. ansonsten sieht das soweit ok aus. Kommt der Fehler auch bei einem neuen Profil? Zitieren
roccomarcy 20 Geschrieben 20. Oktober 2021 Autor Melden Geschrieben 20. Oktober 2021 Am 20.10.2021 um 19:37 schrieb NorbertFe: Achso wer hat denn noch so uralte Sch… ;) warum setzt du den ecp auf autodiscover? Dann muss man ja nochmal zu Mail Switchen, dann kannst auch gleich Mail reinschreiben. ansonsten sieht das soweit ok aus. Kommt der Fehler auch bei einem neuen Profil? Mehr Ja, Ja, ich weiß. Der muss ja jetzt auch langsam mal weg. :) Keine Sorge. Hu? Den ecp habe ich doch auf mail.firma.de setzen lassen? Oder habe ich was überlesen? Get-EcpVirtualDirectory -Server exch | Set-EcpVirtualDirectory -InternalUrl 'https://mail.firma.de/ecp' Ja, leider auch bei einem neuen Profil. Teste hier mit zwei Maschinen und bei beiden kam der Fehler, auch nach neuem Profil. Leider. :| Zitieren
NorbertFe 2.217 Geschrieben 20. Oktober 2021 Melden Geschrieben 20. Oktober 2021 Schonmal iisreset durchgeführt? Ansonsten nochmal genau prüfen, dass die Namen korrekt in der config stehen. Hab schon lustige Dinge mit verdrehten Buchstaben oder trailing space gehabt. Zitieren
roccomarcy 20 Geschrieben 20. Oktober 2021 Autor Melden Geschrieben 20. Oktober 2021 Ja, IISReset habe ich schon durchgeführt. Siehe mein Einwand von oben. In der config? Du meinst bei den Befehlen? Habe ich schon einmal alle neugeschrieben und abgefeuert. :| Zitieren
cj_berlin 1.447 Geschrieben 20. Oktober 2021 Melden Geschrieben 20. Oktober 2021 Am 20.10.2021 um 19:43 schrieb NorbertFe: Hab schon lustige Dinge mit verdrehten Buchstaben oder trailing space gehabt. Mehr Das würde aber nicht dazu führen, dass statt des Namespaces der (korrekte) FQDN des Servers angesprochen wird, oder? Es wird ja im Endeffekt der Exchange angefahren und präsentiert auch das neue Zertifikat... Wenn im SCP --> Im AD kontrollieren!!! der richtige Name steht, und es keine CNAME-Einträge im DNS --> dort kontrollieren!! gibt, die auf den Server-FQDN verweisen, kann es ja nur entweder was gecachetes sein oder eine HTTP-Redirection. Bei Redirection wüsstest Du inzwischen, dass es sie gibt, den Autodiscover-Cache kannst Du zur Probe löschen. Bei Clients, die in der Domäne oder anderswie gemanagt sind, könntest Du die Zeit bis zur Migration mit einer lokalen XML-Datei und einer entsprechenden GPO überbrücken. Aber spätestens zur Migration muss das gerade gezogen sein, sonst hast Du andere Effekte. 1 Zitieren
NorbertFe 2.217 Geschrieben 20. Oktober 2021 Melden Geschrieben 20. Oktober 2021 Am 20.10.2021 um 19:51 schrieb cj_berlin: Das würde aber nicht dazu führen, dass statt des Namespaces der (korrekte) FQDN des Servers angesprochen wird, oder? Mehr Korrekt. Zitieren
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.