(0) exportieren Drucken
Alle erweitern

Grundlegendes zum RPC-Clientzugriff

Exchange 2010
 

Gilt für: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Letztes Änderungsdatum des Themas: 2014-02-10

In Microsoft Exchange Server 2007 wurde die Clientzugriffs-Serverrolle eingeführt, um eingehende Clientverbindungen für Exchange-Postfächer zu verarbeiten. Obwohl die Mehrzahl der Clientverbindungsarten zu Clientzugriffsservern hergestellt werden, wird Microsoft Office Outlook immer noch direkt mit dem Postfachserver bei der internen Ausführung mit dem MAPI-Protokoll verbunden.

Ein neuer Dienst wurde mit Exchange Server 2010 eingeführt, der ermöglicht, dass diese MAPI-Verbindungen von einem Clientzugriffsserver verarbeitet werden. Der RPC-Clientzugriffsdienst stellt Datenzugriff über einen einzelnen, gemeinsamen Pfad des Clientzugriffsservers bereit. Davon ausgenommen sind Öffentliche Ordner-Anforderungen, die immer noch direkt an den Postfachserver gestellt werden. Durch diese Änderungen wird die Geschäftslogik konsistenter auf Clients angewandt und die Vorgehensweise bei Failovern optimiert.

Inhalt

RPC-Clientzugriffsdienst und Adressbuchdienst

Vorteile des RPC-Clientzugriffsdiensts

Das Clientzugriffsserver-Array

Konfigurieren des RPC-Clientzugriffs- und des Adressbuchdiensts

Zusätzlich zum Verschieben der Verarbeitung eingehender Outlook-Postfachverbindungen zum Clientzugriffsserver wird der Verzeichniszugriff in Exchange 2010 auch vom Clientzugriffsserver verarbeitet. Weitere Informationen zum Verzeichniszugriff finden Sie unter Grundlegendes zum Adressbuchdienst.

Microsoft Outlook wird immer noch direkt mit dem Postfachserver verbunden, um auf Öffentliche Ordner-Datenbanken zuzugreifen. Wenn ein Client versucht, eine Verbindung mit einem Postfachserver für Öffentliche Ordner-Zugriff herzustellen, erhält der RPC-Endpunkt Antwort vom RPC-Clientzugriffsdienst (MsExchangeRpc). Wenn sich der Endpunkt auf einem Server befindet, auf dem eine Postfachserverrolle installiert ist, lässt der RPC-Clientzugriffsdienst nur Öffentliche Ordner-Anmeldungen zu und stellt einen Verweis auf einen Clientzugriffsserver oder ein Clientzugriffsserver-Array bereit. Wenn sich der Endpunkt auf einem Clientzugriffsserver oder einem Clientzugriffsserver-Array befindet, werden nur Öffentliche Ordner-Anmeldungen zugelassen, und es wird ein Verweis zu einem Postfachserver für Öffentliche Ordner-Zugriff bereitgestellt.

Unterschiede bei der Clientkonnektivität zwischen Exchange 2007 und Exchange 2010

Der RPC-Clientzugriffsdienst hat zahlreiche Vorteile. Während eines Postfachfailovers tritt eine kürzere Downtime von Clients auf, da alle Verbindungen über Clientzugriffsserver hergestellt werden. Wenn ein Failover in Exchange 2007 auftritt, wird die Verbindung der Outlook-Clients für eine gewisse Zeitspanne, die von der Netzwerkkonfiguration abhängt, vom Postfachserver getrennt. Wenn ein einzelner Clientzugriffsserver in Exchange 2010 in einem Clientzugriffsserver-Array fehlschlägt, wird der Client sofort an einen anderen Clientzugriffsserver im Array weitergeleitet. Wenn ein Postfachserver, der Teil einer Database Availability Group (DAG) ist, fehlschlägt, wird die Verbindung des Clients für die Zeitspanne unterbrochen, bis eine Failoverdatenbank eingebunden wurde.

Ein Lastenausgleichsarray mit Clientzugriffsservern ermöglicht das gleichmäßige Verteilen der Datenverkehrslast auf alle Clientzugriffsserver im Array.

Probleme, die durch diese neue Architektur behoben werden, sind unter anderem:

  • Einige Probleme, bei denen Nachrichten auf unterschiedlichen Clients unterschiedlich angezeigt werden.

  • Probleme beim Upload von Zertifikaten in die globale Adressliste.

  • Das Erstellen von Profilen für ausgeblendete Benutzer ist nicht möglich.

  • Inkonsistente Anwendung von Geschäftslogik auf Clients.

  • Öffentliche Ordner werden mit dem RPC-Clientzugriffsdienst auf dem Postfachserver und nicht dem Clientzugriffsserver verbunden.

Außerdem wurde der DSProxy-Dienst entfernt und der neue Adressbuchdienst ist verantwortlich für das Aktualisieren von Zertifikaten und Mitgliedern von Verteilerlisten und für das Speichern von Stellvertreterinformationen für Outlook-Clients.

In Exchange 2007 kommunizieren Outlook und andere MAPI-Clients mit dem Clientzugriffsserver für HTTPS-Verbindungen wie Exchange-Webdienste (einschließlich Verfügbarkeitsdienst und Abwesenheitseinstellungen) und Downloads von Offlineadressbüchern. Eine Kommunikation mit der MAPI-RPC-Komponente auf dem Postfachserver und dem NSPI-Endpunkt auf den globalen Katalogservern für Anfragen an den Verzeichnisdienst findet jedoch direkt statt.

In Exchange 2010 werden diese Verbindungen zum MAPI-RPC-Verbindungspunkt auf dem Clientzugriffsserver oder dem Clientzugriffsserver-Array hergestellt.

In früheren Versionen von Exchange war der Referenzdienst DSProxy, der Outlook-Clients den Speicherort des NSPI-Endpunkts (Name Service Provider Interface) mitteilte, für die Umleitung von Outlook an einen globalen Katalogserver verantwortlich. DSProxy befand sich auf dem Postfachserver. DSProxy wurde in Exchange 2010 durch den Adressbuchdienst ersetzt.

Wenn ein Outlook-Client jetzt eine Anforderung an den Clientzugriffsserver stellt, findet eine von zwei möglichen Aktionen statt.

  • Wenn sich das Benutzerpostfach auf einem Exchange 2010-Postfachserver befindet, wird die Anforderung vom Clientzugriffsserver am aktuellen Active Directory-Standort verarbeitet. Wenn sich das Benutzerpostfach an einem anderen Active Directory-Standort befindet, wird die Anforderung mittels Proxyweiterleitung zum Active Directory-Zielstandort weitergeleitet.

  • Wenn sich das Benutzerpostfach auf einem Exchange-Legacypostfachserver befindet, wird die Anforderung an den Benutzerpostfachserver verwiesen. Legacypostfachserver kommunizieren nicht direkt mit Exchange 2010-Clientzugriffsservern für Verzeichnisinformationen.

Der Adressbuchdienst stellt außerdem Informationen zu Domänencontrollern mit Schreibzugriff und Zugriff auf die globale Adressliste zur Verfügung. Weitere Informationen zum Adressbuchdienst finden Sie unter Grundlegendes zum Adressbuchdienst.

Zusätzlich zum RPC-Clientzugriffsdienst wird in Exchange 2010 eine neue logische Struktur für die Exchange-Organisation eingeführt: das Clientzugriffsserver-Array. Wenn ein Clientzugriffsserver-Array an einem Active Directory-Standort definiert ist, dient er als einziger Kontaktpunkt für alle Clientverbindungen an diesem Active Directory-Standort. Ein Clientzugriffsserver-Array kann einen oder mehrere Clientzugriffsserver enthalten.

Architektur des Clientzugriffsserver-Arrays.

Jeder Active Directory-Standort kann ein einzelnes Clientzugriffsserver-Array umfassen. Ein Clientzugriffsserver-Array bietet keinen Lastenausgleich. Eine separate Lösung für den Lastenausgleich ist weiterhin erforderlich. Weitere Informationen zum Lastenausgleich finden Sie unter Grundlegendes zum Lastenausgleich in Exchange 2010.

Es wird empfohlen, ein Clientzugriffsserver-Array zu erstellen, auch wenn Sie nur einen einzelnen Clientzugriffsserver in der Organisation verwenden. Wenn ein Clientzugriffsserver-Array erstellt wird, werden Clients über den virtuellen Namen des Clientzugriffsserver-Arrays und nicht direkt mit dem vollständig qualifizierten Domänennamen (FQDN) des einzelnen Clientzugriffsservers verbunden. Wenn ein Clientzugriffsserver an einem Active Directory-Standort ersetzt werden muss oder ein zweiter Clientzugriffsserver hinzugefügt wird, sind keine Updates der Profile auf den Clients notwendig.

Nachdem ein Clientzugriffsserver-Array an einem Active Directory-Standort definiert wurde, werden alle Clientzugriffsserver an diesem Active Directory-Standort automatisch Teil des Clientzugriffsserver-Arrays.

Zum Konfigurieren des RPC-Clientzugriffs- und des Adressbuchdiensts müssen Sie die folgenden Schritte ausführen.

  1. Erstellen eines Clientzugriffsarrays

  2. Konfigurieren des Lastenausgleichs

  3. Konfigurieren von IP-Ports

  4. Konfigurieren von RPC-Verschlüsselungseinstellungen

  5. Konfigurieren der Postfachdatenbanken

  6. Sicherstellen niedriger Latenzzeiten und ausreichender Netzwerkgeschwindigkeit

Sie können ein Clientzugriffsarray an dem Active Directory-Standort mithilfe des folgenden Befehls erstellen.

New-ClientAccessArray -Name name -Site site_name -FQDN internal_only_CAS_Array_FQDN
HinweisAnmerkung:
Nach dem Erstellen eines Clientzugriffsarrays müssen Sie die Adresse auch in DNS erstellen und sie der virtuellen IP-Adresse zuordnen, die für das Clientzugriffsarray verwendet wird.

Es ist wichtig, dass der im Befehl angegebene vollqualifizierte Domänenname (FQDN) nur intern auflösbar ist. Wenn der Name auch extern aufgelöst werden kann, werden diese Clients versuchen, eine Verbindung mit dem Array über TCP und nicht über HTTPS herzustellen.

Der Lastenausgleich wird für Hochverfügbarkeit, Failover und das Verteilen der Datenverkehrslast auf mehrere Server für eine bessere Leistung verwendet. Bei der Auswahl einer Lastenausgleichslösung sollte Folgendes beachtet werden:

  • Der Windows-Netzwerklastenausgleich wird nicht auf Windows-Failoverclusterservern unterstützt.

  • Ein Clientzugriffsarray kann nicht an mehreren Active Directory-Standorten verwendet werden. Erstellen Sie stattdessen zwei Clientzugriffsarrays und führen Sie den Lastenausgleich separat an den Standorten aus.

  • Der Hardwarelastenausgleich überwacht normalerweise den zurückkommenden Datenverkehr, die Port- oder Dienstverfügbarkeit, um sicherzustellen, dass Server, die Clientanforderungen nicht beantworten können, keine Netzwerkverbindung erhalten.

  • Einige Lastenausgleichlösungen, z. B. ISA 2006 oder TMG 2010, können keinen RPC-Lastenausgleich ausführen oder RPC-Dienste überwachen. Diese Lösungen werden nur empfohlen, wenn alle Clients über Outlook Anywhere eine Verbindung herstellen und der Datenverkehr in HTTP verkapselt ist.

Weitere Informationen zum Lastenausgleich finden Sie unter Grundlegendes zum Lastenausgleich in Exchange 2010.

Über einen IP-Port können Informationen vom Ursprungs- zum Zielcomputer geleitet werden. Standardmäßig beträgt der dynamische Portbereich für ausgehende Verbindungen auf Windows Server 2008 R2 49152 bis 65535. Exchange 2010-Clientzugriff ändert diesen Bereich auf 6005 bis 65535. Der Bereich wurde erweitert, um ausreichende Skalierungsmöglichkeiten für große Bereitstellungen zu ermöglichen. Das ist ein großer Bereich an Ports, die von Ihrer Firewall zwischen dem Client und den Clientzugriffsservern oder -Arrays zugelassen und ausgeglichen werden müssen.

Wenn MAPI- und Verzeichnisendpunkte korrigiert werden, kann die Anzahl der Ports, für die ein Lastenausgleich notwendig ist, erheblich reduziert werden. Der MAPI-Endpunkt kann in der Registrierung statistisch konfiguriert und der Verzeichnisendpunkt kann in einer Konfigurationsdatei korrigiert werden.

Um den MAPI-Endpunkt zu korrigieren, verwenden Sie die folgende Einstellung in der Registrierung.

Der Wert für den zu verwendenden IP-Port lautet HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem\TCP/IP Port [DWORD].

Um den Verzeichnisdienste-Endpunkt zu korrigieren, müssen Sie den RpcTcpPort-Wert in der Registrierung ändern.

HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeAB\Parameters\RpcTcpPort [String] ist der Wert für den zu verwendenden IP-Port.

HinweisAnmerkung:
Es wird nicht empfohlen, den Standardwert für Outlook Anywhere-Ports zu ändern.

In der RTM-Version von Exchange 2010 ist der RPC-Endpunkt standardmäßig verschlüsselt. Allerdings erzwingt Outlook 2003 keine verschlüsselten MAPI-Verbindungen. Wird in einer Organisation ein Upgrade auf die RTM-Version von Exchange 2010 durchgeführt, sind Clients mit Outlook 2007 oder einer höheren Version automatisch mit der Änderung auf den RPC-Clientzugriff kompatibel, da sie die RPC-Verschlüsselung standardmäßig unterstützen. In Outlook 2003 wird die RPC-Verschlüsselung jedoch nicht verwendet, für den RPC-Clientzugriff ist sie jedoch standardmäßig erforderlich. Wenn Sie die RPC-Verschlüsselung nicht deaktiviert haben, was nicht empfohlen wird, müssen die Benutzer Outlook 2003 für die RPC-Verschlüsselung konfigurieren oder Sie müssen eine Gruppenrichtlinie verwenden, um die Verwendung der RPC-Verschlüsselung durch Outlook 2003 zu erzwingen.

Zu den möglichen Symptomen für dieses Problem gehören folgende Fehlermeldungen:

  • Microsoft Office Outlook kann nicht gestartet werden. Das Office-Fenster kann nicht geöffnet werden. Die Ordnergruppe konnte nicht geöffnet werden.

  • Die Standard-E-Mail-Ordner können nicht geöffnet werden. Der Informationsspeicher konnte nicht geöffnet werden.

Wenn Benutzer den Exchange-Cachemodus verwenden, zeigt Office keinen Fehler an, wird jedoch im getrennten Modus gestartet.

Standardmäßig wird der RPC-Endpunkt durch Exchange 2010 Service Pack 1 (SP1) nicht verschlüsselt. Wenn Sie die Installation von Exchange 2010 SP1 in Ihrer Organisation abgeschlossen haben, können Outlook 2003-Clients Verbindungen mit dem Exchange-Server herstellen, ohne dass eine weitere Konfiguration erforderlich ist.

Weitere Informationen zu diesem Problem sowie Problemumgehungen finden Sie unter Outlook-Verbindungsprobleme mit Exchange 2010-Postfächern.

Gehen Sie folgendermaßen vor, um Outlook 2003 für die Verwendung der RPC-Verschlüsselung zu konfigurieren.

  1. Klicken Sie auf Extras > E-Mail-Konten > Vorhandene E-Mail Konten anzeigen oder ändern.

  2. Wählen Sie das Konto aus, und klicken Sie auf Weitere Einstellungen.

  3. Klicken Sie auf die Registerkarte Sicherheit.

  4. Wählen Sie Daten zwischen Microsoft Office Outlook und Microsoft Exchange verschlüsseln.

  5. Klicken Sie auf OK.

Jede Postfachdatenbank enthält einen RPCClientAccessServer-Wert. Dieser Wert wird bei der Erstellung der Datenbank eingerichtet und bestimmt den Clientzugriffsserver oder das Clientzugriffsserver-Array, das die Clients mit Postfächern auf dem Postfachserver verwenden werden. Dieser Wert gibt auch den Speicherort des RPC-Endpunkts an. Für Outlook 2007- und Outlook 2010-Clients wird dieser Wert aus dem AutoErmittlungsdienst abgerufen.

Der Standardwert für RPCClientAccessServer wird gemäß den folgenden Regeln bestimmt:

  • Wenn Sie ein Clientzugriffsserver-Array am Active Directory-Standort konfiguriert haben, wird die Adresse dieses Arrays verwendet.

  • Wenn kein Array am Active Directory-Standort existiert und sowohl Clientzugriffs- als auch Postfachserverrollen auf demselben physischen Server vorhanden sind, ist der Wert der Eigenschaft RPCClientAccessServer für einen bestimmten Postfachserver derselbe wie für den Postfachserver.

  • Andernfalls wird der Wert der Eigenschaft RPCClientAccessServer für einen bestimmten Postfachserver auf einen zufälligen Clientzugriffsserver am Active Directory-Standort festgelegt.

    HinweisAnmerkung:
    Es wird nicht empfohlen, die Serverrollen auf einem einzelnen Computer, der ebenfalls ein Domänencontroller ist, zu installieren. Obwohl diese Konfiguration unterstützt wird, wird sie nicht empfohlen.
  • Wenn Sie eine Postfachdatenbank vor der Erstellung eines Clientzugriffsarrays erstellt oder einen Clientzugriffsserver am Active Directory-Standort installiert haben, müssen Sie den Wert der Eigenschaft RPCClientAccessServer neu konfigurieren. Wenn kein Clientzugriffsserver am Active Directory-Standort beim Erstellen der Postfachdatenbank vorhanden ist, wird der Wert der Eigenschaft RPCClientAccessServer auf den FQDN des Postfachservers festgelegt. Verwenden Sie den folgenden Befehl, um den Wert der Eigenschaft RPCClientAccessServer zu konfigurieren.

    Set-MailboxDatabase <name> -RPCClientAccessServer <internal_only_CAS_Array_FQDN>
    

Bei Benutzern, die Outlook ohne Exchange-Cachemodus verwenden, beeinflussen hohe Wartezeiten zwischen Client und Server direkt, wie oft Outlook nicht reagiert. Im Allgemeinen führt eine Wartezeit von mehr als 200 Millisekunden (ms) zum Stamm-Postfachserver zu schlechter Client-Leistung.

Da die Wartezeit zwischen Clientzugriffsserver und Postfach weniger als 10 ms betragen soll, wird empfohlen, den Wert der Eigenschaft RPCClientAccessServer immer auf ein Clientzugriffsarray am Standort der aktiven Postfachdatenbank zu konfigurieren.

HinweisAnmerkung:
Eine Änderung des Werts der Eigenschaft RPCClientAccessServer erzwingt die erneute Verbindung aller Clients.

Der Adressbuchdienst wird über die Datei "Microsoft.Exchange.AddressBook.Service.config" konfiguriert. Mithilfe dieser Datei können Sie Folgendes konfigurieren:

  • Die Anzahl der gleichzeitigen Verbindungen pro Benutzer (der Standardgrenzwert ist 50).

  • Deaktivieren oder Aktivieren der Protokollierung.

  • Speicherort, Größe und Aufbewahrungsdauer der Protokolldateien.

Verwenden Sie den folgenden Wert, um die Protokollierung zu aktivieren:

< add key="ProtocolLoggingEnabled" value="true" />
 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.
Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft