Clientzugriffsdienste

[Dieses Thema gehört zur Vorabdokumentation und kann in künftigen Versionen geändert werden. Leere Themen wurden als Platzhalter hinzugefügt. Wenn Sie Feedback dazu haben, freuen wir uns über Ihre Nachricht. Senden Sie uns eine E-Mail an: ExchangeHelpFeedback@microsoft.com.]  

Gilt für:Exchange Server 2016

Überblick über Clientzugriffsdienste auf Postfachservern in Exchange 2016

In Exchange Server 2016 stellen die Clientzugriffsdienste auf Postfachservern Authentifizierungs- und Proxydienste für interne und externe Clientverbindungen bereit. Die Clientzugriffsdienste sind zustandslos, sodass keine Daten in die Warteschlange eingereiht oder gespeichert werden. In Exchange 2016 sind die Clientzugriffsdienste Teil des Postfachservers, sodass sich anders als in früheren Versionen von Exchange kein eigenständiger Clientzugriffsserver mehr konfigurieren lässt. Weitere Informationen finden Sie unter Client access protocol architecture.

Clientverbindungen in Exchange 2016 sind ähnlich wie in Exchange 2013, weichen jedoch von Exchange 2010 ab:

  • Outlook-Clients verwenden MAPI über HTTP oder Outlook Anywhere (RPC über HTTP). In Exchange 2016 ist MAPI über HTTP standardmäßig aktiviert.

  • In Exchange 2016 sind weniger Namespaces für die standortflexible Lösungen als in Exchange 2010 erforderlich. Weitere Informationen finden Sie unter Namespaceplanung in Exchange 2016.

Die Clientzugriffsdienste in Exchange 2016 übernehmen gewissermaßen die Funktion einer Eingangstür, durch die alle Clientanforderungen eingelassen und an die richtige Postfachdatenbank weitergeleitet werden. Die Clientzugriffsdienste bieten Netzwerksicherheit wie z. B. TLS-Verschlüsselung (Transport Layer Security) und verwalten Clientverbindungen über Umleitung und Proxyfunktionen. Die Clientzugriffsdienste authentifizieren Clientverbindungen und führen in der Regel eine Proxyweiterleitung für eine Verbindungsanforderung an den Postfachserver durch, auf dem die aktive Kopie des Benutzerpostfachs enthalten ist. In manchen Fällen können die Clientzugriffsdienste die Anforderung an die Clientzugriffsdienste auf einem anderen Exchange-Server weiterleiten, der sich entweder an einem anderen Standort befindet oder eine aktuellere Version von Exchange ausführt.

Die Clientzugriffsdienste besitzen folgende Merkmale:

  • Zustandslose Dienste In vorherigen Versionen von Exchange war für viele Clientzugriffsprotokolle Sitzungsaffinität erforderlich. Beispielsweise verlangte Outlook Web App in Exchange 2010, dass alle Anforderungen eines bestimmten Clients von einem bestimmten Clientzugriffsserver innerhalb eines Lastenausgleichsarrays von Clientzugriffsservern verarbeitet wurden. In Exchange 2016 sind die Clientzugriffsdienste zustandslos. Mit anderen Worten: Da die gesamte Verarbeitung für das Postfach in den Sicherungsdiensten auf dem Postfachserver stattfindet, spielt es keine Rolle, welche Instanz eines Clientzugriffsdiensts in einem Array von Clientzugriffsdiensten die einzelnen Clientanforderungen erhält. Dies hat zur Folge, dass auf Lastenausgleichsebene keine Sitzungsaffinität mehr erforderlich ist. Hierdurch können eingehende Verbindungen mit Clientzugriffsdiensten anhand einfacher Lastenausgleichstechniken wie DNS-Roundrobin ausgeglichen werden. Außerdem können Hardware-Lastenausgleichsgeräte erheblich mehr gleichzeitige Verbindungen unterstützen. Weitere Informationen finden Sie unter Lastenausgleich in Exchange 2016.

  • Verbindungspooling   Die Clientzugriffsdienste verarbeiten die Clientauthentifizierung und senden die AuthN-Daten an die Sicherungsdienste auf dem Postfachserver. Bei dem Konto, das von den Clientzugriffsdiensten für die Verbindung mit den Sicherungsdiensten auf den Postfachservern verwendet wird, handelt es sich um ein privilegiertes Konto, das Mitglied der Gruppe „Exchange-Server“ ist. Auf diese Weise können die Clientzugriffsdienste Verbindungen mit den Sicherungsdiensten auf den Postfachservern effektiv in Pools zusammenfassen. Ein Array mit Clientzugriffsdiensten kann Millionen Clientverbindungen aus dem Internet verarbeiten; es werden jedoch wesentlich weniger Verbindungen zur Umleitung der Anforderungen an die Sicherungsdienste auf den Postfachservern als Exchange 2010 verwendet. Dies verbessert die Verarbeitungseffizienz und die End-to-End-Latenz.

noteHinweis:
Verwechseln Sie ein Array von Clientzugriffsdiensten nicht mit einem Array von RPC-Clientzugriffsservern, das für RPC über TCP-Clientverbindungen in Exchange 2010 verwendet wurde. In Exchange 2016 handelt es sich bei einem Array von Clientzugriffsdiensten einfach um eine Gruppe von Clientzugriffsdiensten mit Lastenausgleich auf Exchange 2016-Servern.

 
Anzeigen: