Die Grundlagen von Domainname, FQDN und URL-Adresse | Exchange-Infrastruktur |Teil 09#36

Der Kommunikationskanal zwischen Exchange-Client und Exchange-Server basiert auf einem einfachen Konzept, bei dem der Exchange-Client den Exchange-Server über den Exchange-Hostnamen oder, genauer gesagt, über den FQDN des Exchange-Servers anspricht.

Die Vielfalt der Dienste, die der Exchange-Server seinem Exchange-Client anbietet, angefangen bei Exchange-Webdiensten bis hin zu Diensten für den Webmail-Client wie OWA, werden vom Exchange-Client implementiert, der über eine URL-Adresse auf diesen Exchange-Dienst zugreift.

In Bezug auf die Beziehungen, die zwischen einem Exchange-Server und einem Outlook-Client bestehen, werden alle diese Informationen gepackt und über die vom Exchange-Server bereitgestellte AutoErmittlungsantwort an einen Outlook-Client gesendet.

Wie in einem früheren Artikel erwähnt, verfügt jeder öffentlich zugängliche Exchange-Server über zwei Identitäten - die private und die öffentliche Identität.

Wenn Exchange Informationen über die verfügbaren Exchange-Webdienste bereitstellt, werden die Informationen in zwei verschiedenen „Formaten“ bereitgestellt:

• Für den internen Outlook-Client relevante Informationen
• Für den externen Outlook-Client relevante Informationen

Der Hauptunterschied in den Informationen, die für den internen und den externen Outlook-Client bereitgestellt werden, ist die URL-Adresse der Exchange-Webdienste.

• Zu den für den internen Outlook-Client relevanten Informationen gehört die URL-Adresse der Exchange-Webdienste, die den internen Exchange-FQDN verwendet.
• Zu den für externe Outlook-Clients relevanten Informationen gehört die URL-Adresse der Exchange-Webdienste, die den externen Exchange-FQDN verwendet.

URL-Adresskonzept und Exchange-Webdienste

Obwohl uns das Konzept der Verwendung einer Webadresse (URL) offenbar bekannt ist, möchte ich den folgenden Abschnitt dem Thema Autodiscover und URL-Adresse widmen, da dieses Thema nicht so einfach ist, wie es scheint.

Auf unserem Weg zum „Autodiscover-Profi“ müssen wir uns damit auskennen

1. Die Struktur der URL-Adresse der Exchange-Webdienste
2. Der andere Teil, der aus der URL-Adresse des Adress-Webdienstes besteht
3. Die unterschiedliche URL-Adresse, die Exchange für einen internen E-Mail-Client im Vergleich zu einem externen E-Mail-Client bereitstellt.

Darüber hinaus können folgende Fragen auftauchen:

1. Wie legt der Exchange CAS-Server die URL-Adresse für die Webdienste fest?
2. Sollten wir in die Standardeinstellungen der URL-Adresse der Exchange-Webdienste „eingreifen“?
3. In welchen Szenarien müssen wir dieses „Eingreifen“ umsetzen?
4. Gibt es Best Practices für die URL-Adresse der Exchange-Webdienste?

Und wie immer gibt es auf diese Frage keine einfache Antwort.
Im aktuellen Artikel konzentrieren wir uns auf die „physische Struktur“ der URL-Adresse der Exchange-Webdienste

Die Struktur der URL-Adresse | Ansicht auf hoher Ebene

Beginnen wir mit einer ganz einfachen Frage:
F. Wissen Sie, wofür URL steht?

A: Nun ja ... ich werde Sie nicht mit akademischen Diskussionen langweilen, aber für diejenigen unter Ihnen, die die Antwort nicht kennen: URL steht für -uniform resources locator.

Die meisten von uns verknüpfen den Begriff „URL“ assoziativ mit Begriffen wie „Browser“, „Website“ usw.

Ein „Browser“ ist nur ein Beispiel für einen „Client“, der webbasierte Dienste nutzen kann.

Tatsächlich gibt es viele Arten von „Clients“, die webbasierte Dienste nutzen können.
Beispielsweise ist Outlook ein Client, der stark von den Exchange-Webdiensten abhängt.

Die Struktur der URL-Adresse

Eine URL-Adresse ist wie ein Puzzle, das aus vielen Teilen besteht.

Durch das „Betteln“ der URL-Adresse wird das Protokoll (die Sprache) „deklariert“, das der Client und der Server verwenden werden. In einer Exchange-basierten Umgebung werden die Webdienste mithilfe des HTTP-Protokolls und des HTTPS-Protokolls (der verschlüsselten Version des HTTP-Protokolls) bereitgestellt.

Der „mittlere Teil“ der URL-Adresse enthält Informationen über den Host oder den „Element“-Namen, der den Webdienst bereitstellt.

Meistens basieren die Namenskonventionen, die wir verwenden, um auf den Host zu „verweisen“, der die spezifischen Webdienste bereitstellt, auf der FQDN-Namenskonvention (vollqualifizierter Domänenname).

Der „letzte Teil“ oder der „rechte Teil“ der URL-Adresse enthält den Pfad für die jeweiligen Webdienste. Der „Pfad“ ist kein zwingender Bestandteil der URL-Adresse.

Wir verwenden die Option „way“, wenn der jeweilige Host mehrere Webdienste bereitgestellt hat oder wir den Client auf einen bestimmten Ordner oder eine bestimmte Datei verweisen möchten.

Beispielsweise stellt der Exchange CAS-Server viele Arten von Webdiensten bereit. Wenn Exchange-Clients einen bestimmten Webdienst vom Exchange CAS-Server benötigen, müssen die Exchange-Clients den Exchange CAS-Server über eine URL ansprechen, die den Exchange CAS-Servernamen und den Pfad des spezifischen Webdiensts enthält.

In diesem Artikel konzentrieren wir uns nur auf den „mittleren Teil“ (den Hostnamen oder den FQDN-Namen) der URL-Adresse des Exchange-Webdienstes, denn für den Fall, dass wir die URL-Adresse eines bestimmten Exchange-Webdienstes konfigurieren oder anpassen müssen, Wir werden den Teil aktualisieren oder festlegen, der sich auf den Exchange-Hostnamen bezieht.

Das Szenario, in dem wir den „Pfad“-Teil der URL-Adresse der Exchange-Webdienste aktualisieren, kommt sehr selten vor und wird nicht empfohlen.

Hostname vs. FQDN-Name

Ein Hostname ist ein logischer Name, den wir verwenden, um ein bestimmtes Netzwerk-„Element“ anzusprechen.
Wir können den Begriff Hostname als „einzelnen Namen“ oder „Ein-Wort-Name“ definieren.

Der Begriff FQDN steht für - Fully Qualified Domain Name.
Für mich klingt das Wort FQDN immer seltsam.

Der Begriff „vollständig qualifizierter Domänenname“ definiert die Namenskonvention, aber der Begriff „FQDN“ bezieht sich auf einen „vollständigen Hostnamen“ im Gegensatz zum Begriff „Host“, der sich auf einen einzelnen Hostnamen bezieht.

Ein FQDN wird mithilfe der folgenden Formel erstellt:

Um den Unterschied zwischen dem Begriff „Hostname“ und dem Begriff „FQDN-Name“ besser verstehen zu können, können wir uns auf eine standardmäßige „menschliche Adresse“ beziehen. ”

Wenn wir uns auf jemanden beziehen, der den Namen „John“ verwendet, ist dies das Äquivalent des Begriffs „Hostname“. Der Name „John“ konnte nicht als eindeutige Kennung angesehen werden.

Für den Fall, dass wir ein Paket an John senden müssen, müssen wir eine Adresse verwenden, die eine eindeutige Kennung darstellt und es uns ermöglicht, sicherzustellen, dass das Paket an den gewünschten Zielempfänger gesendet wird.

In diesem Fall verwenden wir die „vollständige“ oder „vollständige“ Adresse von John, einschließlich seines Familiennamens, seiner Straße, seiner Stadt usw.

Wir können sagen, dass die „vollständige Adresse“ von John mit dem Szenario identisch ist, in dem wir einen bestimmten Host mithilfe seines FQDN in der Netzwerkumgebung ansprechen.

Technisch gesehen können wir in einem internen Netzwerk einen bestimmten „Host“ nur über den Hostnamen ansprechen, aber in den meisten Fällen ist die bevorzugte Methode zur Ansprache von „Servern“ oder Hosts, die Dienste bereitstellen, die Verwendung des FQDN des Hosts.

In einer öffentlichen Netzwerkumgebung besteht die einzige Möglichkeit, Hosts anzusprechen, darin, ihren FQDN zu verwenden.

Domainname

Ein Domänenname ist auch eine Namenskonvention, die auf einer bestimmten Struktur basiert.
Ein offizieller Domänenname wird aus dem Namen einer Organisation und dem Suffix des Domänennamens gebildet.

Domänensuffix

Jeder Domainname hat ein Suffix (wie jedes Aufzählungszeichen eine Adresse hat). Der Domainname kann als privat oder öffentlich klassifiziert werden.

Privates Domainnamensuffix

Ein Suffix für einen privaten Domänennamen, das auf einem nicht öffentlichen Suffix basiert (und ja, ich weiß, dass der Satz nicht so klar ist).
Mit anderen Worten: Ein Suffix für einen privaten Domänennamen kann nicht im öffentlichen Netzwerk veröffentlicht werden. Für den Fall, dass wir ein privates Domainnamensuffix verwenden möchten, können wir technisch gesehen jeden Namen erfinden, den wir möchten.

Beispielsweise könnte eine verfügbare Option für das Suffix eines privaten Domänennamens „blab la“ sein, und der vollständige Domänenname könnte „o365info.blabla“ lauten

Suffix für öffentliche Domänennamen.

Suffix für öffentliche Domänennamen basiert auf einem öffentlichen Suffix.
Wenn wir ein Suffix für öffentliche Domänennamen verwenden möchten, müssen wir den Domänennamen von einem öffentlichen Anbieter erwerben und es gibt eine begrenzte Anzahl öffentlicher Domänennamen Suffix, aus dem wir wählen können.

Hosts mit dem Namenssuffix „Public Domain“ können Hosts in einem externen Netzwerk (und auch Hosts aus dem internen/privaten Netzwerk) veröffentlichen und darauf zugreifen.

Im folgenden Diagramm sehen wir ein Beispiel für einen Domänennamen mit einem privaten Domänennamensuffix - o365info.lcoal

Und zusätzliches Beispiel für einen Public-Domain-Namen wie - o365info.com

Active Directory-Domänenname

Jedes Active Directory muss einen Domänennamen haben.

Der Active Directory-Domänenname, der von der Person verteidigt wird, die den ersten DC-Server installiert. Active Directory-Administratoren können entscheiden, welchen Domänentyp sie als Suffix für den Active Directory-Domänennamen auswählen möchten.

Falls der Administrator die Verwendung eines privaten Domänennamens für das Active Directory vorzieht, lautet das allgemeine Domänennamensuffix - local

Das Domainnamensuffix „local“ wird nicht im öffentlichen Netzwerk veröffentlicht.

Im folgenden Diagramm sehen wir ein Beispiel der Optionen, die für den Active Directory-Administrator verfügbar sind.

Der Active Directory-Administrator kann einen „internen Namespace“ für das Active Directory verwenden, z. B. - o365info.lcoal oder einen „externen Namespace“ wie - o365info.com .
Das Suffix „com“ ist ein Public-Domain-Namenssuffix.

Active Directory-Domänenname und Exchange-Infrastruktur

Die Exchange-Infrastruktur ist in die Active Directory-Infrastruktur „integriert“ oder „verwoben“.

Die Exchange-Infrastruktur kann nicht außerhalb des Active Directory „leben“ oder mit anderen Worten; Das Active Directory dient als Plattform für die Exchange-Infrastruktur und die Exchange-Infrastruktur ist an die Grenze der Active Directory-Gesamtstruktur „gebunden“.

Standard-FQDN jedes Exchange-Servers

Der Standard-FQDN jedes Exchange-Servers, der aus dem Exchange-Hostnamen und dem lokalen Active Directory-Domänennamen besteht.

Falls wir ein privates Domänennamensuffix für die Active Directory-Domäne verwenden, „erbt“ Exchange den Active Directory-Domänennamen und das Ergebnis ist, dass alle FQDNs des Exchange-Servers das private Active Directory-Domänennamensuffix haben.

Theoretisch gibt es in diesem Szenario keinen „Schaden“, aber das Problem entsteht aufgrund der unterschiedlichen Beschaffenheit der Active Directory-Infrastruktur im Vergleich zur Exchange-Infrastruktur.

Wenn wir uns auf die Active Directory-Infrastruktur beziehen, liegt die zugrunde liegende Annahme darin, dass wir die Active Directory-Infrastruktur niemals dem öffentlichen Netzwerk zugänglich machen wollen oder müssen oder dem externen Host den Zugriff auf das interne Active Directory ermöglichen.

Im Zusammenhang mit der Exchange-Infrastruktur ist das Konzept, interne Hosts zu „verstecken“ oder den Zugriff externer Hosts auf private Hosts zu verhindern, nicht umsetzbar. In den meisten Fällen müssen wir einen Teil des Exchange-Servers (öffentlicher Exchange-Server) „offenlegen“, damit externe Hosts wie externe Exchange-Clients mit dem Exchange-Server kommunizieren können.

Um die Anforderung „Exchange-Ressourcen veröffentlichen“ erfüllen zu können, müssen wir den öffentlichen Domänennamen für die Veröffentlichung des erforderlichen Hosts verwenden.

Externe Exchange-Clients adressieren beispielsweise den öffentlich zugänglichen Exchange CAS-Server mithilfe eines FQDN wie - mail.o365info.com

Die beiden Identitäten des öffentlich zugänglichen Exchange CAS-Servers

Falls es sich bei dem Exchange CAS-Server um einen „öffentlichen Exchange-Server“ handelt und das Active Directory auf einem privaten Domänennamen basiert, lautet das Ergebnis: Der Exchange CAS-Server verfügt über zwei unterschiedliche „Identitäten“.

1. Intern - „Active Directory“-Identität
2. Öffentliche Identität

Der Begriff „Identität“ beschreibt den FQDN, den der Exchange CAS-Server verwenden wird.

• Wenn ein Exchange-Client einen Exchange-CAS-Server adressieren muss, adressiert der Exchange-Client die private oder öffentliche Identität (FQDN) des Exchange-CAS-Servers.
• Wenn Exchange-Clients einen bestimmten Exchange-Webdienst verwenden müssen, verwendet der Exchange-Client eine URL-Adresse, die die private oder öffentliche Identität (FQDN) des Exchange-Servers enthält, der den spezifischen Exchange-Webdienst bereitstellt.

Exchange-Webdienst und URL-Adresse

Exchange-Server, stellt seinen Exchange-Clients eine Vielzahl von Webdiensten zur Verfügung.

Die Art und Weise, wie der Exchange CAS-Server einen bestimmten Exchange-Webdienst „offenlegt“, ist die Verwendung einer URL-Adresse. Mit anderen Worten: Exchange-Clients greifen über eine URL-Adresse auf den Exchange-Webdienst zu.

In diesem Abschnitt möchte ich mich auf einen ganz bestimmten Teil der URL-Adresse konzentrieren, die wir für Exchange-Webdienste verwenden - den FQDN.

Im vorherigen Abschnitt diskutieren wir ein Szenario, in dem Active Directory auf einem privaten Domänennamen basiert, und wir diskutieren auch die Notwendigkeit der Verwendung eines zusätzlichen Domänennamens: eines öffentlichen Domänennamens, der von einem öffentlich zugänglichen Exchange-Server verwendet wird, der kommunizieren muss mit externen Exchange-Clients.

In diesem Szenario müssen wir ein Szenario implementieren, das ich als „zwei verschiedene Identitäten“ beschreibe, die dem öffentlichen Exchange-Server zugewiesen werden. Die äußere Identität und die innere Identität.

Beispiel 1 - Outlook-Client sucht nach Exchange CAS-Server

Wenn der Outlook-Client versucht, einen verfügbaren Exchange CAS-Server zu finden, wird der folgende Prozess implementiert.

• Ein interner Outlook-Client (Outlook-Client im internen Firmennetzwerk) spricht den Exchange CAS-Server über seinen „privaten FQDN“ an.
• Ein externer Outlook-Client (Outlook-Client im internen Firmennetzwerk) wird den Exchange CAS-Server über seinen „öffentlichen FQDN“ ansprechen.

Beispiel 2 - Veröffentlichung von Informationen über den Exchange-Webdienst

Wenn der Exchange CAS-Server auf eine AutoErmittlungsanforderung antwortet, enthält die AutoErmittlungsantwort zwei Arten von Informationen über Exchange-Webdienste:

• Informationen für interne AutoErmittlungs-Clients, die auf der URL-Adresse basieren und den privaten FQDN des Exchange-Servers enthalten, der den jeweiligen Exchange-Webdienst bereitstellt.
• Informationen für externe AutoErmittlungs-Clients, die auf der URL-Adresse basieren und den öffentlichen FQDN des Exchange-Servers enthalten, der den jeweiligen Exchange-Webdienst bereitstellt.

Exchange-Webdienste und URL-Adressstruktur

Exchange-Server bieten eine Vielzahl webbasierter Dienste. Jeder der verschiedenen Exchange-Webdienste wird durch eine dedizierte URL-Adresse „repräsentiert“.

Obwohl wir eine dedizierte URL der verschiedenen Exchange-Webdienste verwenden, basiert die von uns verwendete URL-Adresse auf einer Grundstruktur, die in allen URL-Adressen der Exchange-Webdienste verwendet wird.

Eine „standardmäßige“ Exchange-Webdienst-URL-Adresse besteht aus vier Teilen:

1. Protokollname

Der erste Teil der URL-Adresse ist der Protokollname.
Exchange-Webdienste werden mithilfe des HTTP- oder HTTPS-Protokolls implementiert.
Meistens wird die Kommunikation zwischen dem Exchange-Server und seinen Clients mithilfe von durchgeführt HTTPS-Protokoll.

2. FQDN-Name

Der FQDN-Name ist der „vollständige Hostname“, der den Hostnamen und den Domänennamen umfasst.

Für den Fall, dass der Exchange-Server keinem öffentlichen Netzwerk ausgesetzt ist, wird der FQDN des Exchange-CAS-Servers aus dem „richtigen Servernamen“ (dem NetBIOS-Namen des Servers) und dem internen Active Directory-Domänennamen erstellt.

Für den Fall, dass der Exchange CAS-Server als „öffentlicher Exchange-Server“ konfiguriert ist, „entlarvt“ sich der Exchange CAS-Server durch die Verwendung eines öffentlichen FQDN und kann und wird darüber hinaus meistens mehrere FQDN-Namen haben.

Die Notwendigkeit von mehr als einem „öffentlichen FQDN“ hängt von den Diensten ab, die der „öffentliche Exchange-Server“ bereitstellt.

3. Ordnername

Für jeden der von Exchange bereitgestellten Webdienste gibt es einen „dedizierten virtuellen Ordner“.

Beispielsweise wird der Autodiscover-Dienst des Exchange-Servers mithilfe eines dedizierten Ordners namens „Autodiscover“ implementiert.

Wenn Exchange-Clients einen bestimmten Dienst benötigen, muss der Exchange-Client die URL-Adresse kennen und verwenden, die einen bestimmten „Ordnernamen“ enthält, der die spezifischen Dienste darstellt, die er benötigt.

4. Der Dateiname

Der letzte Teil der URL-Adresse kann einen Dateinamen enthalten. Beispielsweise enthält im Szenario von AutoErmittlungsdiensten die URL-Adresse, die der AutoErmittlungs-Client verwendet, den Namen der bestimmten Datei, die der Client vom Server anfordert.
Der AutoErmittlungs-Client fordert eine Datei mit dem Namen „autodiscover.xml

Beispiel für interne vs. externe Autodiscover-URL-Adresse

Um das Konzept der „doppelten Identität“ des Exchange CAS-Servers zu demonstrieren, überprüfen wir die Autodiscover-URL-Adresse, die von internen Exchange-Clients verwendet wird, im Vergleich zur Autodiscover-URL-Adresse, die von externen Exchange-Clients verwendet wird.

Szenario-Charter:

Eine Organisation verwendet einen privaten Domänennamen als Active Directory-Domänennamen.
Der Active Directory-Domänenname lautet - o365info.local

Der organisierende öffentliche Domainname lautet - o365info.com

Der Name des Exchange CAS-Servers lautet - exo1

In einem Szenario bedient der Exchange CAS-Server interne Exchange-Clients und unterstützt auch öffentliche oder externe Exchange-Clients.

Im folgenden Diagramm sehen wir die Grundstruktur der Autodiscover-Webdienst-URL-Adresse.

Autodiscover-URL-Adresse | interne Exchange-Clients

In unserem Beispiel registriert sich der Exchange CAS-Server automatisch beim SCP des Active Directory, indem er den folgenden Hostnamen verwendet: ex01.o365info.local

Wenn wir genauer sein wollen, registriert der Exchange CAS-Server die Autodiscover-URL-Adresse im SCP des Active Directory unter Verwendung der folgenden URL:
https://ex01.o365info.local /autodiscover/autodiscover.xml

Wenn der interne Outlook-Client den AutoErmittlungsprozess startet, ruft der Outlook-Client vom lokalen Active Directory die URL-Adresse des Exchange-AutoErmittlungsdienstes ab und „extrahiert“ aus der URL-Adresse den Hostnamen des Exchange CAS-Servers - ex01.o365info.local und fragen Sie den internen DNS nach diesem Hostnamen ab.
Die DNS-Antwort enthält die interne/private IP-Adresse des Exchange CAS-Servers.

Autodiscover-URL-Adresse | externe Exchange-Clients

Wenn in unserem Beispiel ein externer E-Mail-Client wie Outlook ein neues Outlook-E-Mail-Profil für John@o365info.com erstellen muss, geht Outlook davon aus, dass die Autodiscover-URL-Adresse wie folgt lautet Folgen Sie: https://autodiscover.o365info.com/autodiscover/autodiscover.xml

Um eine Verbindung zum öffentlich zugänglichen Exchange-Server herstellen zu können, „extrahiert“ Outlook den FQDN-Namen des Exchange-Servers aus der öffentlichen AutoErmittlungsadresse.

In unserem Szenario - autodiscover.o365info.com

Der Outlook-Client wendet sich an den öffentlichen DNS-Server und sendet eine Abfrage mit der Suche nach Informationen über die öffentliche IP-Adresse dieses Hosts.

Doppelte Identität austauschen | mit identischem oder unterschiedlichem FQDN?

Eine der grundlegendsten und wichtigsten Entscheidungen, die wir als Exchange-Administrator treffen müssen, ist die Entscheidung über die Exchange-Namespace-Infrastruktur.

Unsere Grundannahme ist, dass ein Teil der Exchange-Infrastruktur als öffentlich zugänglich konfiguriert wird und aus diesem Grund die Exchange interne und externe Exchange-Clients bedienen muss.

Mit anderen Worten: Der öffentlich zugängliche Exchange-Server verfügt über zwei verschiedene Schnittstellen.

Option 1 - Verwendung eines separaten Namespace

In diesem Fall verwendet jeder der öffentlich zugänglichen Exchange-Server einen anderen Namensraum für jede seiner „Identitäten“.

Um dieses Konzept zu demonstrieren, verwenden wir das folgende Szenario:

• Der interne Active Directory-Domänenname lautet - o365info.local
• Der öffentliche Domainname der Organisation lautet - o365info.com

Zum Beispiel

• Die „interne Identität“ des Exchange-Servers wird durch den Hostnamen dargestellt - ex01.o365info.local
• Die „externe Identität“ des Exchange-Servers wird durch den Hostnamen dargestellt - mail.o365info.com und autodiscover.o365info.com

Ein interner Exchange-Client, der den Exchange-Server ansprechen muss und nach einer Autodiscover-Infrastruktur sucht, adressiert den Exchange-Server unter Verwendung des Hostnamens - ex01.o365info.local

Ein externer Exchange-Client, der den Exchange-Server ansprechen muss und nach Autodiscover-Infrastruktur sucht, wird den Exchange-Server über den Hostnamen ansprechen - autodiscover.o365info.com

Option 2 - Verwendung eines einheitlichen Namespace

In diesem Fall verwenden wir für jede der „Identitäten“ des Exchange-Servers den identischen Namespace.

Um dieses Konzept zu demonstrieren, verwenden wir das folgende Szenario:

• Der interne Active Directory-Domänenname lautet - o365info.local
• Der öffentliche Domainname der Organisation lautet - o365info.com

Der Hauptunterschied besteht darin, dass wir in diesem Szenario den lokalen Active Directory-Domänennamen nicht als Teil des Exchange-Hostnamens verwenden.

In dem Szenario, das ich als einheitlichen Namespace beschreibe, wird der Exchange-Server für den internen und externen Exchange-Client „veröffentlicht“, indem der öffentliche Domänen-Namespace verwendet wird.

• Die „interne Identität“ des Exchange-Servers wird durch die Hostnamen dargestellt - mail.o365info.com und autodiscover.o365info.com
• Die „externe Identität“ des Exchange-Servers wird durch die Hostnamen dargestellt - mail.o365info.com und autodiscover.o365info.com

Ein interner Exchange-Client, der den Exchange-Server ansprechen muss und nach Autodiscover-Infrastruktur sucht, wird den Exchange-Server über den Hostnamen ansprechen - autodiscover.o365info.com

Ein externer Exchange-Client, der den Exchange-Server ansprechen muss und nach Autodiscover-Infrastruktur sucht, wird den Exchange-Server über den Hostnamen ansprechen - autodiscover.o365info.com

In der Vergangenheit bestand der „Trend“ darin, den Unterschied zwischen den „internen Exchange-Umgebungen“ und der „externen Exchange-Umgebung“ hervorzuheben. ”

Der Grund für diesen Trend liegt in der Annahme, dass die Verwendung eines getrennten Namespaces sicherer ist, da die „Trennung“ die interne Exchange-Infrastruktur vor unerwünschten Zugriffen externer Hosts schützt.

Meiner Meinung nach schützt die „logische Trennung“ nicht wirklich die interne Exchange-Infrastruktur, da der Schutz und die Trennung in Wirklichkeit durch unterschiedliche Lösungen umgesetzt werden.

Die Verwendung des Konzepts eines getrennten Namespace wird das Leben des Exchange-Administrators komplizierter machen und die Benutzer verwirren.