none
Exchange Zertifikate: interne Servernamen (FQDNs) vermeiden RRS feed

  • Frage

  • Hallo,

    ich wollte nur mal nachfragen, wie ihr das so mit den internen FQDNs der Exchange Server auf dem Exchange Zertifikat handhabt. Meiner Ansicht nach gehören die nicht mit ins Exchange Zertifikat, da ich die interne Domäne und den internen Servernamen nicht veröffentlichen will.

    Jedoch habe ich einen Fall, wo Outlook 2013 auf ein Exchange 2010 Postfach zugreift und einen Zertifikatsfehler anzeigt (Name stimmt nicht überein Servername.interneDomaene.de mit Zertifikat *.Domain.com).

    Wenn mit Outlook 2010 auf das selbe Postfach zugegriffen wird, erschein kein Zertifikatsfehler.

    Wir setzen hier in allen Einstellungen der virtuellen Verzeichnisse und bei den Clientaccess Einstellungen auf einen einheitlichen Namensraum (mail.Domain.com). Die Umgebung ist eine Koexistenzumgebung mit Exchange 2010 / Exchange 2013. Der Exchange 2010 wird in den virtuellen Verzeichnissen mit legacy.Domain.com angesprochen.

    Es ist in keiner Einstellung mehr der interne FQDN des Exchange 2010 Servers erwähnt.

    Trotzdem scheint Outlook 2013 hier den Exchange Server zu ermitteln, auf dem das Postfach liegt, und diesen per internem FQDN anzusprechen. Die Clientaccess Einstellungen (die Autoermittlungsuri + die EXPR + die EXCH Settings) sind richtig gesetzt und zeigen auch auf mail.Domain.com.

    An welcher Stelle könnte ich also noch etwas übersehen haben oder ist es in bestimmten Fällen immer notwendig, dass ich im Exchange Zertifikat den internen FQDN mit angebe?

    Eine letzte Bemerkung noch: In der o.g. Umgebung ist der Exchange 2010 recht verbogen. Der wird bald deinstalliert und es spielt hier keine Rolle mehr. Ich muss jedoch bald eine Exchange 2007 Umgebung auf 2013 (2x 2007 Server, je in eigenem Standort) umstellen. Dort besteht dann die Koexistenzumgebung länger und deshalb benötigte ich ein Zertifikat, dass auf allen Exchange Servern funktioniert und keine Warnungen am Outlook Client hervorruft.

    Vielen Dank schon einmal vorab.

    Gruß,
    Karl-Heinz

    Donnerstag, 21. Januar 2016 16:46

Antworten

  • > ich wollte nur mal nachfragen, wie ihr das so mit den internen FQDNs der Exchange Server auf dem Exchange Zertifikat handhabt.

    Ist nicht erforderlich und auch nicht empfohlen. Das Stichwort lautet "Split DNS".

    > Jedoch habe ich einen Fall, wo Outlook 2013 auf ein Exchange 2010 Postfach zugreift und einen Zertifikatsfehler anzeigt (Name stimmt nicht überein Servername.interneDomaene.de mit Zertifikat *.Domain.com).

    Dann ist eine der vielen URLs vermutlich falsch konfiguriert. SCP, OAB, EWS, Outlook Anywhere und MAPI vDir. Der einzige Name, der unterschiedlich sein sollte, ist der Name des CAS-Arrays in 2010 und der sollte dann auch als CAS-Server in der 2010-Datenbanken eingestellt sein. Für 2013 ist die Einstellung nicht mehr notwendig, da wird immer Outlook Anywhere benutzt. Daher spielt der Name in einer Co-Existenz Umgebung auch keine Rolle mehr.

    > Wir setzen hier in allen Einstellungen der virtuellen Verzeichnisse und bei den Clientaccess Einstellungen auf einen einheitlichen Namensraum (mail.Domain.com). Die Umgebung ist eine Koexistenzumgebung mit Exchange 2010 / Exchange 2013. Der Exchange 2010 wird in den virtuellen Verzeichnissen mit legacy.Domain.com angesprochen.

    Warum? Es gibt genau EINEN Namen für HTTPS und die Verbindung geht über den 2013-CAS (oder über einen Load Balancer, aber immer an 2013). Alle vDir sind identisch konfiguriert, einzig die DNS-Auflösung gibt das korrekt Ziel vor, den 2013 Server.

    > An welcher Stelle könnte ich also noch etwas übersehen haben oder ist es in bestimmten Fällen immer notwendig, dass ich im Exchange Zertifikat den internen FQDN mit angebe?

    Interne Name sind nicht notwendig, andere Punkte habe ich genannt. Und zum gehfühlt 100x Mal in dieser Woche den Link zum Co-Existenz-Blog:
    http://blogs.technet.com/b/exchange/archive/2014/03/12/client-connectivity-in-an-exchange-2013-coexistence-environment.aspx

    > Eine letzte Bemerkung noch: In der o.g. Umgebung ist der Exchange 2010 recht verbogen. Der wird bald deinstalliert und es spielt hier keine Rolle mehr. Ich muss jedoch bald eine Exchange 2007 Umgebung auf 2013 (2x 2007 Server, je in eigenem Standort) umstellen. Dort besteht dann die Koexistenzumgebung länger und deshalb benötigte ich ein Zertifikat, dass auf allen Exchange Servern funktioniert und keine Warnungen am Outlook Client hervorruft.

    Na dann mach doch. ;)

    Auch 2007 ist in dem Link beschrieben.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)


    Donnerstag, 21. Januar 2016 17:26
  • Am 21.01.2016 schrieb Mr. Fuchs:
    Hi,

    ich wollte nur mal nachfragen, wie ihr das so mit den internen FQDNs der Exchange Server auf dem Exchange Zertifikat handhabt. Meiner Ansicht nach gehören die nicht mit ins Exchange Zertifikat, da ich die interne Domäne und den internen Servernamen nicht veröffentlichen will.

    die haben darin nichts zu suchen und wenn deine Domain ein "interner Namensraum ist, der nicht auf dich öffentliche registriert ist, bekommst du auch keine Zertifikate von externen CAs dafür.

    Jedoch habe ich einen Fall, wo Outlook 2013 auf ein Exchange 2010 Postfach zugreift und einen Zertifikatsfehler anzeigt (Name stimmt nicht überein Servername.interneDomaene.de mit Zertifikat *.Domain.com).


    Trotzdem scheint Outlook 2013 hier den Exchange Server zu ermitteln, auf dem das Postfach liegt, und diesen per internem FQDN anzusprechen. Die Clientaccess Einstellungen (die Autoermittlungsuri + die EXPR + die EXCH Settings) sind richtig gesetzt und zeigen auch auf mail.Domain.com.

    An welcher Stelle könnte ich also noch etwas übersehen haben oder ist es in bestimmten Fällen immer notwendig, dass ich im Exchange Zertifikat den internen FQDN mit angebe?

    Alle URLs ausgeben lassen und jemand anderes prüfen lassen. Manchmal sinds "Leerzeichen am Ende" oder Vertipper usw., die man aufgrund von Betriebsblindheit gar nicht sieht. ;)

    Eine letzte Bemerkung noch: In der o.g. Umgebung ist der Exchange 2010 recht verbogen. Der wird bald deinstalliert und es spielt hier keine Rolle mehr. Ich muss jedoch bald eine Exchange 2007 Umgebung auf 2013 (2x 2007 Server, je in eigenem Standort) umstellen. Dort besteht dann die Koexistenzumgebung länger und deshalb benötigte ich ein Zertifikat, dass auf allen Exchange Servern funktioniert und keine Warnungen am Outlook Client hervorruft.

    Aha. :)

    Bye
    Norbert

    Donnerstag, 21. Januar 2016 22:06
  • In meiner Antwort ist der Link untergegangen:

    blogs.technet.com/b/exchange/archive/2014/03/12/client-connectivity-in-an-exchange-2013-coexistence-environment.aspx


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Freitag, 22. Januar 2016 09:03

Alle Antworten

  • > ich wollte nur mal nachfragen, wie ihr das so mit den internen FQDNs der Exchange Server auf dem Exchange Zertifikat handhabt.

    Ist nicht erforderlich und auch nicht empfohlen. Das Stichwort lautet "Split DNS".

    > Jedoch habe ich einen Fall, wo Outlook 2013 auf ein Exchange 2010 Postfach zugreift und einen Zertifikatsfehler anzeigt (Name stimmt nicht überein Servername.interneDomaene.de mit Zertifikat *.Domain.com).

    Dann ist eine der vielen URLs vermutlich falsch konfiguriert. SCP, OAB, EWS, Outlook Anywhere und MAPI vDir. Der einzige Name, der unterschiedlich sein sollte, ist der Name des CAS-Arrays in 2010 und der sollte dann auch als CAS-Server in der 2010-Datenbanken eingestellt sein. Für 2013 ist die Einstellung nicht mehr notwendig, da wird immer Outlook Anywhere benutzt. Daher spielt der Name in einer Co-Existenz Umgebung auch keine Rolle mehr.

    > Wir setzen hier in allen Einstellungen der virtuellen Verzeichnisse und bei den Clientaccess Einstellungen auf einen einheitlichen Namensraum (mail.Domain.com). Die Umgebung ist eine Koexistenzumgebung mit Exchange 2010 / Exchange 2013. Der Exchange 2010 wird in den virtuellen Verzeichnissen mit legacy.Domain.com angesprochen.

    Warum? Es gibt genau EINEN Namen für HTTPS und die Verbindung geht über den 2013-CAS (oder über einen Load Balancer, aber immer an 2013). Alle vDir sind identisch konfiguriert, einzig die DNS-Auflösung gibt das korrekt Ziel vor, den 2013 Server.

    > An welcher Stelle könnte ich also noch etwas übersehen haben oder ist es in bestimmten Fällen immer notwendig, dass ich im Exchange Zertifikat den internen FQDN mit angebe?

    Interne Name sind nicht notwendig, andere Punkte habe ich genannt. Und zum gehfühlt 100x Mal in dieser Woche den Link zum Co-Existenz-Blog:
    http://blogs.technet.com/b/exchange/archive/2014/03/12/client-connectivity-in-an-exchange-2013-coexistence-environment.aspx

    > Eine letzte Bemerkung noch: In der o.g. Umgebung ist der Exchange 2010 recht verbogen. Der wird bald deinstalliert und es spielt hier keine Rolle mehr. Ich muss jedoch bald eine Exchange 2007 Umgebung auf 2013 (2x 2007 Server, je in eigenem Standort) umstellen. Dort besteht dann die Koexistenzumgebung länger und deshalb benötigte ich ein Zertifikat, dass auf allen Exchange Servern funktioniert und keine Warnungen am Outlook Client hervorruft.

    Na dann mach doch. ;)

    Auch 2007 ist in dem Link beschrieben.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)


    Donnerstag, 21. Januar 2016 17:26
  • Am 21.01.2016 schrieb Mr. Fuchs:
    Hi,

    ich wollte nur mal nachfragen, wie ihr das so mit den internen FQDNs der Exchange Server auf dem Exchange Zertifikat handhabt. Meiner Ansicht nach gehören die nicht mit ins Exchange Zertifikat, da ich die interne Domäne und den internen Servernamen nicht veröffentlichen will.

    die haben darin nichts zu suchen und wenn deine Domain ein "interner Namensraum ist, der nicht auf dich öffentliche registriert ist, bekommst du auch keine Zertifikate von externen CAs dafür.

    Jedoch habe ich einen Fall, wo Outlook 2013 auf ein Exchange 2010 Postfach zugreift und einen Zertifikatsfehler anzeigt (Name stimmt nicht überein Servername.interneDomaene.de mit Zertifikat *.Domain.com).


    Trotzdem scheint Outlook 2013 hier den Exchange Server zu ermitteln, auf dem das Postfach liegt, und diesen per internem FQDN anzusprechen. Die Clientaccess Einstellungen (die Autoermittlungsuri + die EXPR + die EXCH Settings) sind richtig gesetzt und zeigen auch auf mail.Domain.com.

    An welcher Stelle könnte ich also noch etwas übersehen haben oder ist es in bestimmten Fällen immer notwendig, dass ich im Exchange Zertifikat den internen FQDN mit angebe?

    Alle URLs ausgeben lassen und jemand anderes prüfen lassen. Manchmal sinds "Leerzeichen am Ende" oder Vertipper usw., die man aufgrund von Betriebsblindheit gar nicht sieht. ;)

    Eine letzte Bemerkung noch: In der o.g. Umgebung ist der Exchange 2010 recht verbogen. Der wird bald deinstalliert und es spielt hier keine Rolle mehr. Ich muss jedoch bald eine Exchange 2007 Umgebung auf 2013 (2x 2007 Server, je in eigenem Standort) umstellen. Dort besteht dann die Koexistenzumgebung länger und deshalb benötigte ich ein Zertifikat, dass auf allen Exchange Servern funktioniert und keine Warnungen am Outlook Client hervorruft.

    Aha. :)

    Bye
    Norbert

    Donnerstag, 21. Januar 2016 22:06
  • In meiner Antwort ist der Link untergegangen:

    blogs.technet.com/b/exchange/archive/2014/03/12/client-connectivity-in-an-exchange-2013-coexistence-environment.aspx


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Freitag, 22. Januar 2016 09:03
  • Hallo,

    ich bin wirklich dankbar für die bereitgestellte Hilfe. Aber mit dem Link

    blogs.technet.com/b/exchange/archive/2014/03/12/client-connectivity-in-an-exchange-2013-coexistence-environment.aspx

    kann ich in dem Migrationsszenario 2007 -> 2013 (2x 2007er Exchange, jeweils in eigener AD Site) nicht alles raus lesen (hab' ich bestimmt schon x-mal durch). Zumal auch nicht beschrieben ist, wie die internen Pfade zu konfigurieren sind.

    Sorry - vielleicht bin ich auch nur blind oder hab' ein Brett vorm Kopf.

    Ich habe nun die aktuelle Umgebung (Exchange 2007) und die geplante Umgebung (2013) in dem beigefügten Bild zusammen gefasst.

    Stimmen die geplanten Pfade der virtual Directories so?

    Vielen Dank & Gruß,

    Karl-Heinz

    Freitag, 22. Januar 2016 10:14