Website-Suche

Exchange CAS-Server | Bereitstellung des Zugriffs für Exchange-Kunden auf ihr Postfach | Teil 06#36


In diesem Artikel möchte ich die geheime Romanze zwischen Exchange-Mail-Clients und „seinem“ Exchange-CAS-Server Revue passieren lassen.
Exchange-Clients haben sehr ungewöhnliche und aufregende Beziehungen zu ihrem Exchange-CAS-Server und die Autodiscover-Infrastruktur ist der Glanz, der sie vereint diese beiden Liebenden.

Fahren Sie mit unserer romantischen Metapher fort; Die Wahrheit ist, dass der Exchange-Client diese „Beziehungen“ mit jedem verfügbaren Exchange CAS-Server haben kann.

Mit einfachen Worten: Der Exchange-Client ist vollständig von einem Exchange-Server abhängig, der die CAS-Serverrolle innehat, aber der Exchange-Client ist nicht an einen bestimmten Exchange-CAS-Server „gebunden“.

Was ist das Besondere an diesen „geheimen Beziehungen“ zwischen dem Exchange-Client und dem Exchange-CAS-Server?

Im folgenden Artikel analysieren wir die Chartas dieser Beziehungen und wie Autodiscover mit diesen Beziehungen zusammenhängt oder daran beteiligt ist.

Was ist der Exchange CAS-Server?

In einer modernen Exchange-Umgebung „übt“ jeder Exchange-Server eine bestimmte Rolle (oder mehrere Exchange-Serverrollen) aus.

Wir werden nicht auf die spezifischen Chartas für jede der „Exchange-Serverrollen“ und einen Vergleich der Unterschiede zwischen der Exchange 2007-, 2010- und Exchange 2013-Umgebung eingehen, sondern stattdessen zwei der Exchange-Serverrollen hervorheben: Exchange CAS-Rolle und Exchange Mailbox Rolle.

Um die Exchange-Infrastruktur verbinden zu können, muss ein Exchange-Client einen Exchange CAS-Server finden und verbinden.

Der Exchange-Mail-Client findet „seinen Exchange-CAS-Server“ mithilfe des Autodiscover-Dienstes.

Aus diesem Grund nimmt der AutoErmittlungsprozess einen so wichtigen Teil der Exchange-Infrastruktur ein, da der Exchange-Client ohne einen ordnungsgemäßen Abschluss des AutoErmittlungsprozesses Folgendes tut:

  • Es kann kein neues Outlook-Mail-Profil erstellt werden.
  • Es kann keine Verbindung zu seinem Postfach hergestellt werden.
  • Es können keine Informationen zu verfügbaren Exchange-Webdiensten abgerufen werden.
  • Eine automatische Wiederherstellung nach Fehlern und eine automatische Reaktion auf Änderungen in der Microsoft Exchange-Umgebung ist nicht möglich.

Die Zuständigkeiten des Exchange CAS-Servers

Bevor wir auf die „Details“ oder die Beziehungen eingehen, werfen wir einen Blick auf die „Verantwortlichkeiten“ des Exchange CAS-Servers in einer übergeordneten Ansicht.

Der folgende Screenshot stammt aus dem Exchange Server 2010-Architekturposter. Im Diagramm sehen wir eine detaillierte Beschreibung der „Verantwortlichkeiten“ des Exchange 2010-Servers, der die CAS-Rolle innehat.

Der Exchange CAS-Server stellt „seinen Clients“ viele Arten von Diensten zur Verfügung.
Wir können sogar noch dramatischer sagen: Ohne den Exchange CAS-Server kann der Exchange-Client nicht mit der Exchange-Infrastruktur kommunizieren oder sich mit dieser verbinden.

Wie wir im folgenden Diagramm sehen können, können wir die „Dienste“ des Exchange CAS-Servers in vier Hauptgruppen einteilen.

Jede dieser „Gruppen“ ist für Exchange-Clients gleichermaßen wichtig, um eine Verbindung zur Exchange-Infrastruktur herstellen und diese nutzen zu können.

Das Dreieck der drei Hauptverantwortungen des Exchange CAS-Servers

Der Exchange-CAS-Server ist für die drei Hauptaufgaben verantwortlich:

  1. Bereitstellung des Zugriffs auf ihre Postfächer für Exchange-Kunden.
  2. Bereitstellung von Webdiensten\Zugriff auf Webdienste für Exchange-Clients.
  3. Bereitstellung von Informationen (Autodiscover-Informationen) für Exchange-Clients.

Der Rest des aktuellen Artikels ist der beschriebenen Aufgabe gewidmet:

  • Bereitstellung des Zugriffs für Exchange-Kunden auf ihr Postfach.

Der nächste Artikel - Exchange CAS-Server als Informations- + Webdienstanbieter | Teil 07 Nr. 36 ist den Aufgaben des Exchange CAS-Servers gewidmet, die wie folgt beschrieben werden:

  1. Bereitstellung von Webdiensten\Zugriff auf Webdienste für Exchange-Clients.
  2. Bereitstellung von Informationen (Autodiscover-Informationen) für Exchange-Clients.

Bereitstellung des Zugriffs für Exchange-Kunden auf ihr Postfach

In diesem Abschnitt konzentrieren wir uns auf die Aufgabe des Exchange CAS-Servers, als „Proxy“ oder „Vermittler“ zwischen dem Exchange-Client und seinem Postfach zu fungieren, das auf dem Exchange-Server gehostet wird, der die Postfachrolle innehat.

In einer modernen Exchange-Umgebung kann der Exchange-Client sein Postfach nur über den Exchange CAS-Server verbinden.

Exchange-Clients wie der Outlook-Client können nicht direkt auf ihr Postfach zugreifen, das auf einem Exchange-Server gehostet wird, der die Rolle des Exchange-Postfachservers hat.

Der Outlook-Client greift auf das Benutzerpostfach über den Exchange-Server zu, der die CAS-Rolle hat.

Klassifizierung des Exchange-Mail-Clients

Im folgenden Abschnitt beschreiben wir den Ablauf, der für Autodiscover-Clients verwendet wird. Aus diesem Grund ist es wichtig, dass wir eine allgemeine Klassifizierung verwenden, die sich auf die Exchange-Clients bezieht.

Das bekannteste Beispiel für den Autodiscover-Client ist der Outlook-Client. ActiveSync-Client und OWA-Client können auch als „Autodiscover-Client“ betrachtet werden, dieser Client war jedoch nicht so stark von den Autodiscover-Diensten abhängig.

Eine zusätzliche Klassifizierung, die wir verwenden sollten, ist der unterschiedliche Ablauf, der von Outlook-Clients implementiert wird, die sich im internen privaten Netzwerk befinden (Zugriff auf Active Directory), im Vergleich zum AutoErmittlungsablauf, der vom Outlook-Client ausgeführt wird, der sich in einem öffentlichen Netzwerk befindet oder in einem Netzwerk, in dem sie keinen Zugriff auf das Active Directory haben.

Der Exchange-CAS-Server und das Transparenzkonzept | Verschiedene Proxy-Szenarien

Eines der grundlegendsten Konzepte der Beziehungen zwischen Exchange-Client und dem Exchange-CAS-Server ist das „Transparenzkonzept“.

Der Exchange-Client muss sich der komplexen Exchange-Infrastruktur nicht bewusst sein, die eine große Anzahl von Servern, Dutzende oder sogar Hunderte von Servern umfassen kann. Stattdessen müssen sie nur einen Exchange CAS-Server finden.

Der Exchange CAS-Server ist das Element, das „in der Mitte“ steht und zwischen dem Exchange-Client und dem Exchange-Postfachserver trennt, der das Benutzerpostfach hostet.

Die Exchange-Clients müssen nicht wissen:

1. Der Name des Exchange-Postfachservers, der sein Postfach hostet
2. Der physische Standort des Exchange-Postfachservers, der sein Postfach hostet

Der wesentliche Vorteil der Verwendung des Konzepts des „Mann in der Mitte“ (auch bekannt als Exchange CAS-Server) besteht darin, dass die „Aufgabe“, den Exchange-Postfachserver zu finden und zu verbinden, der das Benutzerpostfach hostet, den Exchange-Clients verborgen bleibt.

Dieses Konzept der „Transparenz“ ermöglicht es der Exchange-Infrastruktur, viele Arten von Diensten und Lösungen bereitzustellen.

Zum Beispiel:

Szenario 1: externer E-Mail-Client

In einem Szenario, in dem ein externer E-Mail-Client Zugriff auf sein Postfach benötigt, besteht keine Notwendigkeit, den internen Exchange-Postfachserver, der die Postfächer des Benutzers hostet, „offenzulegen“.

Stattdessen müssen wir lediglich mindestens einen Exchange CAS-Server als öffentlich zugänglichen Exchange CAS-Server konfigurieren.

Die vom öffentlichen Exchange CAS-Server akzeptierte externe Exchange-Mail-Client-Anfrage und der Exchange CAS-Server „wissen“, wie der jeweilige interne Exchange-Postfachserver, der das Benutzerpostfach hostet, lokalisiert und verbunden wird.

Szenario 2: Redundanz des Exchange-Postfachservers

Für den Fall, dass die Organisation einen Clustering-Mechanismus implementiert, bei dem die Postfachdatenbank des Benutzers auf den anderen Exchange-Standort repliziert wird, für den Fall, dass das „Original Wenn der (aktive) Exchange-Postfachserver nicht verfügbar ist, „weiß“ der Exchange-CAS-Server, wie er die Exchange-Clients mit dem „anderen“ Exchange-Postfachspeicher verbindet.

Im folgenden Diagramm sehen wir ein Beispiel für verschiedene mögliche Szenarien, in denen der Exchange CAS-Server die Anfrage von Exchange-Clients „bedienen“ muss.

Externer vs. interner Outlook-Client | Verwendung unterschiedlicher Autodiscover-Mechanismen

Wenn Outlook-Clients versuchen, seinen Exchange CAS-Server zu finden und eine Verbindung herzustellen, unterscheidet sich der vom internen Outlook-Client implementierte AutoErmittlungsprozess vom AutoErmittlungsprozess, der von externen Outlook-Clients implementiert wird.

Außerdem unterscheiden sich die AutoErmittlungsinformationen, die der Exchange CAS-Server dem internen Outlook-Client bereitstellt, von den Informationen, die der Exchange CAS-Server externen Outlook-Mail-Clients usw. bereitstellt.

Im folgenden Abschnitt werden wir einige der häufigsten Autodiscover-Szenarien und die unterschiedlichen Charaktere der „Beziehungen“ untersuchen, die zwischen Exchange-Clients und ihrem Exchange CAS-Server realisiert werden.

Um die Beschreibung zu vereinfachen, gehen wir von einem Szenario aus, bei dem der Mail-Client Outlook ist.

Szenario 1: Interner Outlook Exchange-Client | Exchange-Postfachserver am selben Active Directory-Standort

Die Chartas dieses Szenarios lauten wie folgt:

Ein Benutzer im internen Netzwerk versucht, ein neues Outlook-Mailprofil zu erstellen.

Wenn der Benutzer den Assistenten für neue Outlook-E-Mail-Profile aktiviert, wird der folgende Ablauf implementiert:

  1. Outlook findet den Namen der verfügbaren Exchange CAS-Server, indem es das lokale Active Directory abfragt.
  2. Active Directory antwortet mit einer Liste der verfügbaren Exchange CAS-Server unter Verwendung des privaten oder „internen Namens“ der vorhandenen Exchange CAS-Server.
  3. Anhand der in der Liste angezeigten Exchange CAS-Servernamen wählt Outlook zufällig einen der Namen aus und versucht, eine Verbindungsanfrage an den Exchange CAS-Server zu senden.
  4. Der Exchange CAS-Server fragt das Active Directory ab und sucht nach dem Namen des Exchange-Postfachservers, der das bestimmte Benutzerpostfach hostet.
  5. Der Exchange CAS-Server erkennt zwei Eigenschaften des „Exchange-Clients“ (des Outlook-Mail-Clients):
    Dass der Mail-Client ein - MAPI-Mail-Client ist + dass der Mail-Client ein „interner Mail-Client“ ist.
  6. Der CAS-Exchange-Server generiert eine Autodiscover-Antwort, die Informationen enthält, die für Outlook-Mail-Clients relevant sind, und „Informationsabschnitte“.
    Die bereitgestellten Informationen umfassen die URL-Adresse der verfügbaren Exchange-Webdienste. Die in der AutoErmittlungsantwort aufgeführte URL-Adresse umfasst:
    Interne Hostnamen + externe Hostnamen (innere und äußere URL-Adresse). Interne URL-Adressen werden keinem Host aus dem öffentlichen Netzwerk angezeigt und können nur vom internen E-Mail-Client verwendet werden.
  7. Der Exchange CAS-Server verbindet den „Ziel-Exchange-Postfachserver“ und startet den Prozess der „Proxy“-Verteilung der Informationen vom Exchange-Postfachserver (Postfachinhalt) an den internen Outlook-Mail-Client und umgekehrt.

Szenario 2: Externer Exchange Outlook-Client

Wenn sich der Exchange-Mail-Client in einem öffentlichen Netzwerk befindet, kann der externe Mail-Client sein „internes Postfach“ (die interne Exchange-Infrastruktur) nur über den Exchange CAS-Server erreichen, der als öffentlich zugänglicher Exchange CAS konfiguriert ist Server.

In diesem Szenario wird der Exchange CAS-Server unter Verwendung eines bekannten Namens und einer öffentlichen IP-Adresse veröffentlicht. Um die erforderlichen Dienste erhalten zu können, muss der Exchange-Mail-Client einen verschlüsselten Kommunikationskanal (sicheren Kanal) mit dem „öffentlichen Exchange CAS-Server“ identifizieren und erstellen. ”

Die Anforderungen des Exchange-Clients, auf sein „internes Postfach“ zuzugreifen, das sich auf dem internen Exchange-Postfachserver befindet, können nur durch die Vermittlung des „öffentlich zugänglichen Exchange CAS-Servers“ umgesetzt werden.

Der Exchange CAS-Server akzeptiert Exchange-Client-Anfragen und implementiert einen „Proxy-Mechanismus“, bei dem sich der Exchange CAS-Server den internen Exchange-Servern als der Mail-Client „präsentiert“, den er „repräsentiert“. ”

Wenn der Exchange CAS-Server die erforderlichen Daten aus dem Benutzerpostfach erhält, sendet der Exchange CAS-Server die Daten an den externen E-Mail-Client zurück.

Hinweis: In vielen Szenarien leitet der Exchange-CAS-Server nicht „offenbar“ an externe Clients weiter, sondern stattdessen dient ein Firewall-Server wie ISA\TMG als „öffentliche Einheit“, die externe Clients akzeptiert Exchange-Client-Kommunikationsanfragen und „leiten“ diese Anfragen an den Exchange CAS-Server weiter.

Wenn der Benutzer den Assistenten für neue Outlook-E-Mail-Profile aktiviert, wird der folgende Ablauf implementiert:

  1. Outlook findet den Namen der verfügbaren Exchange CAS-Server, indem es den Namen des Exchange CAS-Servers „generiert“. Outlook verwendet den SMTP-Domänennamen der E-Mail-Adresse des Empfängers als „möglichen Namen“ des Exchange CAS-Servers (des öffentlich zugänglichen Exchange CAS-Servers).
  2. Outlook versucht, eine Verbindungsanforderung an den Autodiscover-Endpunkt zu senden, d. h. an den öffentlich zugänglichen Exchange CAS-Server.
  3. Der öffentlich zugängliche Exchange CAS-Server fragt das Active Directory ab und sucht nach dem Namen des Exchange-Postfachservers, der das bestimmte Benutzerpostfach hostet.
  4. Der Exchange CAS-Server erkennt zwei Eigenschaften des „Exchange-Clients“ (des Outlook-Mail-Clients):
    Dass der Mail-Client ein - MAPI-Mail-Client ist + dass der Mail-Client ein „externer Mail-Client“ ist
  5. Der Exchange CAS-Server generiert eine Autodiscover-Antwort, die Informationen enthält, die für Outlook-Mail-Clients relevant sind, und „Informationsabschnitte“.
    Die bereitgestellten Informationen umfassen - die öffentliche URL-Adresse der verfügbaren Exchange-Webdienste. Die in der AutoErmittlungsantwort aufgeführte URL-Adresse enthält:
    nur externe/öffentliche Hostnamen.
  6. Der öffentlich zugängliche Exchange CAS-Server verbindet den „Ziel-Exchange-Postfachserver“ und startet den Prozess der Weiterleitung der Informationen vom Exchange-Postfachserver (Postfachinhalt) an den externen Outlook-Mail-Client und umgekehrt.

Szenario 3: Externer Exchange-Client | zwei Exchange-Standorte
zwei öffentlich zugängliche Exchange CAS-Server

Ein weiterer interessanter Dienst, den der Exchange CAS-Server bereitstellen kann, wird als Umleitung beschrieben.

In einer Exchange-Unternehmensumgebung, beispielsweise einem großen Unternehmen mit mehreren Standorten weltweit, ist ein typisches Szenario die Situation mit mehreren Exchange-Standorten.

Bei mehreren Exchange-Standorten kann die Organisation entscheiden, eine der folgenden Situationen zu implementieren:

Option 1: Nur einen bestimmten Exchange-CAS-Server „offenlegen“, der als „Brennpunkt“ oder Gateway für alle Exchange-Clients weltweit dient (dies ist das Szenario, das im vorherigen Abschnitt beschrieben wurde). - Proxy-Dienste)

Option 2: Veröffentlichen Sie mehr als einen öffentlich zugänglichen Exchange CAS-Server oder einen öffentlich zugänglichen Exchange CAS-Server für jeden Unternehmensstandort.

In einem Szenario mit mehreren Exchange-Standorten und verschiedenen öffentlich zugänglichen Exchange CAS-Servern gibt es zwei Hauptszenarien für die Verwaltung der Art und Weise, wie der externe E-Mail-Client den erforderlichen Exchange CAS-Server findet.

Die Konfiguration eines einzelnen öffentlichen Exchange CAS-Servers steht im Mittelpunkt.

Obwohl die Exchange-Infrastruktur in diesem Szenario mehr als einen „öffentlich zugänglichen Exchange CAS-Server“ umfasst, wird den Autodiscover-Datensätzen für den öffentlichen Domänennamen nur ein „öffentlich zugänglicher Exchange CAS-Server“ zugeordnet.

In unserem Beispiel haben wir zwei physische Active Directory- und Exchange-Standorte: den Standort New York und den Standort Los Angel.

Der öffentliche Domänenname lautet o365info.com und der Autodiscover-Eintrag - autodiscover.o365info.com ist der öffentlichen IP-Adresse zugeordnet des „New York Public Facing Exchange CAS Servers“ unter Verwendung der öffentlichen IP-Adresse: 212.25.80.239

In unserem Szenario muss ein Benutzer namens Bob, der die E-Mail-Adresse Bob@o365info.com verwendet, sein Exchange-Postfach verbinden, das auf dem Exchange-Postfachserver im Los gehostet wird Engelsseite.

Wenn der Outlook-Client den AutoErmittlungsprozess startet, findet er den öffentlich zugänglichen Exchange CAS-Server „New Yorker Standort“ und verbindet ihn. ”

Das weiß der „New Yorker Standort öffentlich zugänglicher Exchange CAS-Server“.

  • Bobs Postfach befindet sich auf einer anderen Exchange-Site (Los Angels Site)
  • Dass es auf der Website von Los Angeles einen öffentlich zugänglichen Exchange CAS-Server gibt, der eine externe E-Mail-Client-Anfrage bearbeiten könnte.

Aufgrund dieser Informationen bedient der „öffentlich zugängliche Exchange CAS-Server des New Yorker Standorts“ den Exchange-Client nicht selbst und sendet stattdessen Umleitungsanweisungen an den externen Outlook Exchange-Client.

Die Umleitungsanweisungen enthalten den Namen (FQDN) des „Los Angeles Site Public Faces Exchange CAS Servers“.

Die externen Exchange-Clients beginnen den Prozess noch einmal, aber dieses Mal versucht der Exchange Outlook-Client, eine Verbindung zum „Öffentlich zugänglichen Exchange CAS-Server des Standorts Los Angeles“ herzustellen.

Vorausgesetzt, dass der Benutzer die richtigen Anmeldeinformationen bereitstellt und der „Öffentlich zugängliche Exchange CAS-Server des Standorts Los Angeles“ über das erforderliche öffentliche Zertifikat verfügt, findet der „Öffentlich zugängliche Exchange CAS-Server des Standorts Los Angeles“ den Exchange-Postfachserver, der Bobs Postfach hostet Stellt die Verbindungsanforderung zwischen dem internen Los Angeles Exchange-Postfachserver und dem externen Exchange-Client (Bob) hin und her.

Verwandte Artikel