Split-DNS einführen

[NorbertFe 1.799]

vor 2 Minuten schrieb roccomarcy:

dass das Zertifikat ein Multidomain und kein SAN-Zertifikat ist.

Wo is denn da der Unterschied? ;)

[roccomarcy 12]

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

[cj_berlin 1.133]

vor einer Stunde schrieb roccomarcy:

Ich glaube, dass das Zertifikat ein Multidomain und kein SAN-Zertifikat ist.

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.

[testperson 1.527]

Hi,

 

vor 1 Stunde schrieb roccomarcy:

Wir haben ca. 10 unterschiedliche E-Maildomänen, die den einzelnen Anwendern als primäre SMTP-Adresse zugeordnet ist.

 

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

[NorbertFe 1.799]

vor 1 Stunde schrieb roccomarcy:

Gibt es einen Unterschied?

Weiß nicht, du meintest doch es gibt einen. ;)

vor 1 Stunde 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.

Dann brauchst du 11 Namen (10x autodiscover plus einmal generischer Name vermutlich in einer der zehn Domains) alternativ 2 Namen und 9x http Redirect.

[roccomarcy 12]

vor 13 Minuten schrieb NorbertFe:

Weiß nicht, du meintest doch es gibt einen. ;)

 

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. :)

 

vor 27 Minuten 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

 

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

[NorbertFe 1.799]

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

[cj_berlin 1.133]

vor 5 Minuten schrieb NorbertFe:

ausserdem fehlt noch die Konfiguration vom mapi Virtual Directory.

Auf Exchange 2010?

[roccomarcy 12]

vor 12 Minuten schrieb NorbertFe:

Dein scp zeigt auf den internen Namen. Das musst du ändern. Set-clientaccessservice -AutoDiscoverServiceInternalUri

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.

 

 

vor 6 Minuten schrieb cj_berlin:

Auf Exchange 2010?

Nee, das Verzeichnis hab ich ja (noch) nicht. :)

bearbeitet 20. Oktober 2021 von roccomarcy

[NorbertFe 1.799]

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?

[roccomarcy 12]

vor 1 Minute 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?

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. :|

[NorbertFe 1.799]

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.

[roccomarcy 12]

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. :|

[cj_berlin 1.133]

vor 1 Minute schrieb NorbertFe:

Hab schon lustige Dinge mit verdrehten Buchstaben oder trailing space gehabt.

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.

[NorbertFe 1.799]

vor 7 Minuten schrieb cj_berlin:

Das würde aber nicht dazu führen, dass statt des Namespaces der (korrekte) FQDN des Servers angesprochen wird, oder?

Korrekt.