Freigeben über

Grundlegendes zu Proxyfunktion und Umleitung

  • Artikel

 

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

Letztes Änderungsdatum des Themas: 2016-11-28

In einer Microsoft Exchange Server 2010-Organisation kann ein Clientzugriffsserver als Proxy für andere Clientzugriffsserver innerhalb dieser Organisation fungieren. Dies ist nützlich, wenn an unterschiedlichen Active Directory-Standorten in der Organisation mehrere Clientzugriffsserver vorhanden sind und mindestens einer der Standorte nicht über eine Internetverbindung verfügt.

Ein Clientzugriffsserver kann auch Umleitungen für Microsoft Office Outlook Web App-URLs und für Exchange ActiveSync-Geräte durchführen. Umleitungen sind hilfreich, wenn Benutzer eine Verbindung mit einem Clientzugriffsserver herstellen, der sich nicht am lokalen Active Directory-Standort befindet, oder wenn ein Postfach zwischen Active Directory-Standorten verschoben wurde. Sie sind ebenfalls in dem Fall hilfreich, wenn Benutzer tatsächlich eine effektivere URL verwenden. Beispiel: Benutzer sollten eine URL verwenden, die enger an den Active Directory-Standort angelehnt ist, an dem sich das Postfach befindet.

Je nach Protokoll kann die Antwort des Clientzugriffsserver anders ausfallen. Ein Clientzugriffsserver führt jedoch in der Regel folgende Aktionen aus, wenn er eine Anforderung für einen Benutzer erhält, dessen Postfach sich an einem anderen Active Directory-Standort befindet als dem, dem der Clientzugriffsserver zugeordnet ist: In diesem Fall sucht der Server im entsprechenden virtuellen Verzeichnis nach der Eigenschaft ExternalURL auf einem Clientzugriffsserver, der sich am selben Active Directory-Standort wie das Benutzerpostfach befindet. Wenn die Eigenschaft ExternalURL vorhanden ist und der Clienttyp die Umleitung unterstützt (Beispiel: Outlook Web App oder Exchange ActiveSync), gibt der Clientzugriffsserver eine Umleitung an diesen Client aus. Wenn die Eigenschaft ExternalURL nicht vorhanden ist oder wenn der Clienttyp die Umleitung nicht unterstützt (Beispiel: POP3 oder IMAP4), versucht der Clientzugriffsserver, als Proxy für die Verbindung mit dem Active Directory-Zielstandort zu fungieren.

Dieses Thema befasst sich mit Proxyfunktionen und Umleitungen, es werden die Bedingungen erläutert, wann die jeweilige Funktion verwendet wird und wie die Clientzugriffsserver für das jeweilige Szenario konfiguriert werden.

Hinweis

Wenn in Ihrer Organisation nicht mehrere Active Directory-Standorte vorhanden sind, müssen Sie Exchange 2010 nicht für die Verwendung von Proxyfunktionen oder Umleitungen konfigurieren. Sie sollten jedoch möglicherweise den Lastenausgleich für URLs konfigurieren, wie später in diesem Thema beschrieben.

Hinweis

Clientzugriffsserver ohne Internetverbindung müssen nicht über separate SSL-Zertifikate (Secure Sockets Layer) verfügen, um Proxydatenverkehr von einem anderen Clientzugriffsserver zuzulassen. Sie können standardmäßig das selbstsignierte Zertifikat verwenden, das mit Exchange 2010 installiert wird. Diese Zertifikate werden jedoch von internen Clients, z. B. Outlook Web App oder Outlook, im Allgemeinen nicht als vertrauenswürdig eingestuft, und ihre Verwendung führt zu Zertifikatwarnungen. Wenn sich interne Clients an denselben Active Directory-Standorten befinden wie Clientzugriffsserver mit selbstsignierten Zertifikaten, sollten Sie die selbstsignierten Zertifikate durch Zertifikate ersetzen, die von einer von den Clients als vertrauenswürdig eingestuften Zertifizierungsstelle ausgestellt wurden.

Inhalt

Übersicht über die Verwendung von Proxyfunktionen

Übersicht über die Umleitungsfunktion

Proxyfunktionen mit Netzwerklastenausgleich

Zusammenfassung der Clientzugriffsmethoden

Leistung und Skalierbarkeit der Proxyfunktion

Übersicht über die Verwendung von Proxyfunktionen

In Microsoft Exchange Server 2003 kommuniziert der Front-End-Server über HTTP mit dem Back-End-Server. In Exchange Server 2007 und Exchange 2010 kommuniziert der Clientzugriffsserver über RPC mit einem Exchange-Postfachserver. Es muss sich daher ein Exchange 2010-Clientzugriffsserver an jedem Active Directory-Standort befinden, der einen Exchange 2010-Postfachserver umfasst. Die Proxyfunktion wird verwendet, wenn ein Clientzugriffsserver Daten an einen anderen Clientzugriffsserver sendet. Ein Exchange 2010-Clientzugriffsserver kann Anforderungen in den folgenden Situationen per Proxy weiterleiten:

  • Zwischen Exchange 2010-Clientzugriffsservern   Werden Anforderungen zwischen zwei Exchange 2010-Clientzugriffsservern per Proxy weitergeleitet, können Organisationen mit mehreren Active Directory-Standorten einen Clientzugriffsserver als Server mit Internetverbindung definieren und dafür sorgen, dass dieser Server Anforderungen an Clientzugriffsserver an Standorten ohne Internetverbindung per Proxy weiterleitet. Der Clientzugriffsserver mit Internetverbindung leitet die Anforderung dann per Proxy an den Clientzugriffsserver weiter, der dem Postfach des Benutzers am nächsten liegt.

  • Zwischen einem Clientzugriffsserver mit Exchange 2010 und Clientzugriffsservern mit Exchange 2007   Wenn Anforderungen per Proxy zwischen einem Clientzugriffsserver mit Exchange 2010 und einem Clientzugriffsserver mit Exchange 2007 innerhalb eines Active Directory-Standorts oder zwischen Active Directory-Standorten weitergeleitet werden, können Exchange 2010 und Exchange 2007 innerhalb derselben Organisation koexistieren. Weitere Informationen zu Upgrade und Koexistenz finden Sie unter Upgrade von Exchange 2003 für den Clientzugriff und Upgrade von Exchange 2007 für den Clientzugriff.

Die Verwendung von Proxys wird für Clients unterstützt, die Outlook Web App, Exchange ActiveSync, die Exchange-Systemsteuerung, POP3, IMAP4 und Exchange-Webdienste verwenden. Proxyvorgänge von einem Clientzugriffsserver zu einem anderen Clientzugriffsserver werden unterstützt, wenn auf dem Zielclientzugriffsserver die gleiche Version von Microsoft Exchange wie auf dem Quellclientzugriffsserver oder eine frühere Version von Microsoft Exchange als auf diesem ausgeführt wird, mit Ausnahme von Instanzen, in denen eine versionsspezifische URL erforderlich ist. Weitere Informationen zu versionsspezifischen URLs und älteren Hostnamen in einer gemischten Umgebung mit Exchange 2007 und Exchange 2010 finden Sie unter Upgrade von Exchange 2007 für den Clientzugriff. Weitere Informationen zu versionsspezifischen URLs und älteren Hostnamen in einer gemischten Umgebung mit Exchange 2010 und Exchange 2013 finden Sie unter Erstellen eines Legacy-Exchange-Hostnamens.

Warnung

Wenn ein IMAP4-Client mit NTLM-Authentifizierung versucht, eine Verbindung mit einem Clientzugriffsserver an einem Active Directory-Standort herzustellen, an dem sich das Zielpostfach nicht befindet, schlägt die Verbindung fehl. Wenn ein IMAP4-Client mittels Proxyweiterleitung von einem Active Directory-Standort an einen anderen weitergeleitet werden soll, müssen Sie eine alternative Authentifizierungsmethode wählen.

Hinweis

In jeder Exchange-Organisation, die den Zugriff von internetbasierten Clients zulassen soll, muss mindestens ein Active Directory-Standort über eine Internetverbindung verfügen. Alle Active Directory-Standorte ohne Internetverbindung nutzen den oder die Clientzugriffsserver mit Internetverbindung, um alle entsprechenden Anforderungen von externen Clients per Proxy weiterzuleiten.

Clientzugriff über Proxyfunktion

In der vorstehenden Abbildung befindet sich das Postfach von Benutzer 1 auf Postfachserver 1. Das Postfach von Benutzer 2 befindet sich auf Postfachserver 2, und das Postfach von Benutzer 3 befindet sich auf Postfachserver 3. Jeder Postfachserver befindet sich an einem anderen Active Directory-Standort. Benutzer 1 kann über Clientzugriffsserver 1 ohne Verwendung eines Proxy auf das eigene Postfach zugreifen, und Benutzer 2 kann über Clientzugriffsserver 2 auf das eigene Postfach zugreifen. Wenn Benutzer 3 versucht, über Clientzugriffsserver 1 oder 2 auf das eigene Postfach zuzugreifen, leitet der jeweilige Server die Anforderung per Proxy an Clientzugriffsserver 3 weiter. Clientzugriffsserver 3 verfügt nicht über eine Internetverbindung, aber kann Anforderungen von anderen Servern innerhalb der Firewall erhalten. Die Verwendung eines Proxys ist für Benutzer nicht sichtbar.

Hinweis

Für die Kommunikation zwischen Clientzugriffsservern an unterschiedlichen Standorten wird HTTPS (Secure HTTP) verwendet. Die Clientzugriffsserver überprüfen jedoch nicht den Status des standardmäßig verwendeten Zertifikats. Das Zertifikat wird ausschließlich für die Verschlüsselung verwendet, nicht jedoch für die Authentifizierung. Daher werden nicht übereinstimmende Namen sowie Ablaufdaten und Vertrauensstatus ignoriert.

Übersicht über die Verwendung von Proxyfunktionen

Übersicht über die Umleitungsfunktion

Benutzer von Outlook Web App, die auf einen Clientzugriffsserver mit Internetverbindung zugreifen, der sich an einem anderen Active Directory-Standort als dem befindet, an dem ihr Postfach gehostet wird, können an den Clientzugriffsserver umgeleitet werden, der sich am selben Standort wie ihr Postfachserver befindet, sofern dieser Clientzugriffsserver über eine Internetverbindung verfügt. Wenn ein Outlook Web App-Benutzer versucht, die Verbindung zu einem Clientzugriffsserver außerhalb des Active Directory-Standorts herzustellen, an dem sich sein Postfachserver befindet, wird eine Webseite mit einem Link zum richtigen Clientzugriffsserver für sein Postfach angezeigt. Dies wird als manuelle Umleitung bezeichnet. In Exchange 2010 SP2 können Administratoren eine standortübergreifende automatische Umleitung konfigurieren, damit dieser Umleitungsvorgang ohne Wissen der Benutzer ausgeführt werden kann. Weitere Informationen finden Sie weiter unten in diesem Thema unter "Standortübergreifende automatische Umleitung".

Hinweis

In einer Hybridumgebung können Sie die standortübergreifende automatische Umleitung nicht verwenden, wenn dort ein lokaler Exchange Server zusammen mit Office 365 ausgeführt wird.

Exchange ActiveSync-Benutzer, die auf einen Clientzugriffsserver mit Internetverbindung an einem anderen Active Directory-Standort als dem Standort ihres Postfachs zugreifen, können an den Clientzugriffsserver am Standort ihres Postfachservers umgeleitet werden, wenn dieser Clientzugriffsserver über Internetzugriff verfügt und wenn auf dem Mobiltelefon oder Gerät, das als Client fungiert, die integrierte Umleitungslogik des Protokolls richtig implementiert ist, das bei der Kommunikation mit Exchange 2007 und Exchange 2010 verwendet wird. Die Umleitung für Benutzer von Exchange ActiveSync wird durchgeführt, indem an das Gerät ein HTTP 451-Fehlercode mit der URL gesendet wird, die das Gerät verwenden soll. Das Gerät wird dann automatisch für die Verwendung der neuen URL konfiguriert.

In der nachstehenden Abbildung wird gezeigt, wie die Umleitung in einer Organisation eingesetzt wird, die über mehrere Clientzugriffsserver an mehreren Active Directory-Standorten verfügt.

Umleitung für Exchange ActiveSync und Outlook Web App in Exchange 2010

In der vorstehenden Abbildung greift Benutzer 1 im Allgemeinen über sein Mobiltelefon auf sein Postfach am Active Directory-Standort 1 zu. Der Administrator verschiebt nun das Postfach von Benutzer 1 auf Postfachserver 2 am Active Directory-Standort 2. Bei der nächsten Synchronisierung des Geräts antwortet der Server mit einem Fehler mit Status HTTP 451. Er enthält die URL, die das Gerät jetzt für diesen Benutzer verwenden soll. In Schritt 3 der Sequenz wird das Gerät automatisch neu konfiguriert und stellt eine Verbindung mit der angegebenen URL her. Benutzer 2, dessen Postfach sich am Active Directory-Standort 2 befindet, versucht, sein Postfach mit Outlook Web App zu öffnen und stellt dazu über das Internet eine Verbindung mit Clientzugriffsserver 1 her. Bei der manuellen Umleitung zeigt der Clientzugriffsserver 1 dem Benutzer im Anschluss an dessen Authentifizierung eine Seite mit einem Link zur Outlook Web App-URL für den Clientzugriffsserver am Active Directory-Standort 2 an. Der Benutzer klickt auf den Link, wird zum Active Directory-Standort 2 umgeleitet und meldet sich erneut an, um auf sein Postfach zugreifen zu können. Bei der automatischen Umleitung wird der Benutzer im Anschluss an die Authentifizierung automatisch zur Outlook Web App-URL für den Clientzugriffsserver an Active Directory-Standort 2 umgeleitet.

Standortübergreifende automatische Umleitung

Hinweis

In einer Hybridumgebung können Sie die standortübergreifende automatische Umleitung nicht verwenden, wenn dort ein lokaler Exchange Server zusammen mit Office 365 ausgeführt wird.

Exchange 2010 SP2 ermöglicht Administratoren die Konfiguration einer standortübergreifenden automatischen Umleitung. Die standortübergreifende automatische Umleitung sorgt für eine automatische Umleitung von Clientanforderungen, die an einen Clientzugriffsserver gesendet wurden, der sich an einem anderen Active Directory-Standort in derselben Exchange-Organisation befindet. Beispielsweise wird ein Benutzer mit einem Postfach am Active Directory-Standort A, der auf die Outlook Web App-URL an Active Directory-Standort B zugreift, automatisch zur Outlook Web App-URL für Active Directory an Standort A umgeleitet.

Zur Konfiguration der standortübergreifenden automatischen Umleitung muss der Administrator den neuen Parameter CrossSiteRedirectType, der dem Cmdlet Set-OWAVirtualDirectory hinzugefügt wurde, verwenden. Der Parameter hat zwei mögliche Einstellungen. Die Standardeinstellung lautet Manual.

  • Automatisch Ist diese Einstellung konfiguriert, wird der Webbrowser eines Benutzers automatisch umgeleitet, sobald ein Clientzugriffsserver eine Outlook Web App-Anforderung an einen Clientzugriffsserver oder ein Serverarray an einem anderen Active Directory-Standort umleiten muss. Ist die formularbasierte Authentifizierung für die virtuellen OWA-Verzeichnisse des Ziel- und Quell-Clientzugriffsservers konfiguriert (SSL erforderlich), dann erfordert die automatische Umleitung auch nur ein einmaliges Anmelden. Für eine Umleitung muss das virtuelle Outlook Web App-Verzeichnis auf dem Ziel-Clientzugriffsserver mit einem ExternalURL-Wert konfiguriert sein.

  • Manuell Ist diese Einstellung konfiguriert, erhalten die Benutzer eine Benachrichtigung, dass sie auf die falsche URL zugreifen und auf einen Link klicken müssen, um auf die korrekte Outlook Web App-URL für ihr Postfach zuzugreifen. Diese Benachrichtigung wird nur angezeigt, wenn ein Clientzugriffsserver feststellt, dass er eine Outlook Web App-Anforderung an den Clientzugriffsserver oder das Serverarray an einem anderen Active Directory-Standort umleiten muss. Für eine Umleitung muss das virtuelle Outlook Web App-Verzeichnis auf dem Ziel-Clientzugriffsserver mit einem Wert ExternalURL konfiguriert sein.

Beispiel:

Set-OWAVirtualDirectory -Identity "Contoso\owa (Default Web site)" -CrossSiteRedirectType Silent

Weitere Informationen zum Cmdlet Set-OwaVirtualDirectory finden Sie unter: Set-OwaVirtualDirectory

Proxyfunktionen und Umleitungen für Exchange ActiveSync

In der folgenden Abfolge von Schritten wird gezeigt, wie eingehende Anforderungen für einen Benutzer verarbeitet werden, der mit einem Mobiltelefon die Verbindung zu einem Exchange 2010-Clientzugriffsserver mit Namen CAS-01 herstellt.

  1. Der Clientzugriffsserver führt eine Abfrage von Active Directory durch, um die Position des Postfachs des Benutzers sowie die Version von Microsoft Exchange zu ermitteln, die auf dem Postfachserver installiert ist.

  2. Befindet sich das Postfach des Benutzers auf einem Server unter Exchange 2003, wird die eingehende Anforderung per Proxy direkt an den Exchange 2003-Server weitergeleitet, der als Host für das Benutzerpostfach und das virtuelle Exchange ActiveSync-Verzeichnis fungiert. Unter Exchange 2003 war das virtuelle Exchange ActiveSync-Verzeichnis standardmäßig auf allen Postfachservern installiert. Der Active Directory-Standort des Benutzerpostfachs ist in diesem Fall nicht relevant, da Exchange 2003 keine Active Directory-Standorte zum Bestimmen der Position verwendet. Die Verbindung wird immer direkt vom Clientzugriffsserver mit Exchange 2010 zum Postfachserver mit Exchange 2003 hergestellt.

    Hinweis

    Benutzern mit Postfächern auf einem Exchange 2003-Server, die versuchen, Exchange ActiveSync über einen Exchange 2010-Clientzugriffsserver zu verwenden, wird ein Fehler angezeigt, und sie können keine Synchronisierung ausführen, wenn nicht die integrierte Windows-Authentifizierung für das virtuelle Verzeichnis "Microsoft-Server-ActiveSync" auf dem Exchange 2003-Server aktiviert ist. Die integrierte Windows-Authentifizierung ermöglicht die Kommunikation zwischen dem Clientzugriffsserver mit Exchange 2010 und den Back-End-Servern mit Exchange 2003.

  3. Wenn sich das Benutzerpostfach auf einem Postfachserver mit Exchange 2007 befindet, sucht CAS-01 einen Clientzugriffsserver mit Exchange 2007 am Active Directory-Standort mit dem Postfachserver des Benutzers. Dieser ist möglicherweise mit dem Active Directory-Standort von CAS-01 identisch. CAS-01 sendet die Exchange ActiveSync-Anforderung unabhängig von den ExternalURL-Einstellungen per Proxy an die InternalURL des Exchange 2007-Clientzugriffsservers. Die Anforderung geht an das /virtuelle Proxy-Verzeichnis, das sich unter dem virtuellen Verzeichnis in IIS Exchange ActiveSync von Microsoft Server. Standardmäßig ist für das Verzeichnis die integrierte Windows--Authentifizierung aktiviert.

  4. Wenn das Postfach des Benutzers sich auf einem Postfachserver mit Exchange 2010 am Active Directory-Standort von CAS-01 befindet, stellt CAS-01 den Zugriff auf das Postfach bereit. Wenn sich das Benutzerpostfach auf einem Postfachserver mit Exchange 2010 an einem anderen Active Directory-Standort befindet, sucht CAS-01 einen Clientzugriffsserver am Active Directory-Standort mit dem Postfachserver des Benutzers. CAS-01 bestimmt, ob für einen Clientzugriffsserver mit Exchange 2010 an diesem Active Directory-Standort die Eigenschaft ExternalURL für das virtuelle Verzeichnis von Exchange ActiveSync konfiguriert ist. In diesem Fall gibt CAS-01 an den Client einen HTTP-Fehler mit dem Code 451 aus, der den Wert für "ExternalURL" enthält, und weist den Client an, eine Umleitung an diese Position durchzuführen. Wenn kein Wert für "ExternalURL" festgelegt ist, wird die Verbindung per Proxy an den Clientzugriffsserver weitergeleitet. Hierfür wird der in der Eigenschaft InternalURL angegebene FQDN verwendet. Die Umleitung erfolgt an das virtuelle Verzeichnis "/Proxy". Dieses virtuelle Verzeichnis befindet sich in IIS unter dem virtuellen Verzeichnis von Exchange ActiveSync. Standardmäßig ist für das Verzeichnis die integrierte Windows-Authentifizierung aktiviert.

    Wichtig

    Die Proxyfunktion kann nicht zwischen virtuellen Verzeichnissen verwendet werden, bei denen die Standardauthentifizierung verwendet wird. Damit die Clientkommunikation zwischen virtuellen Verzeichnissen von Exchange ActiveSync auf unterschiedlichen Servern über die Proxyfunktion weitergeleitet werden kann, muss für das virtuelle Verzeichnis "/Proxy" die integrierte Windows-Authentifizierung verwendet werden.

Übersicht über die Verwendung von Proxyfunktionen

Proxyfunktionen und Umleitungen für Outlook Web App

In der folgenden Abfolge von Schritten wird gezeigt, wie eingehende Anforderungen für einen Benutzer verarbeitet werden, der mit Outlook Web App die Verbindung zu einem Exchange 2010-Clientzugriffsserver mit Namen CAS-01 herstellt.

  1. Der Clientzugriffsserver führt eine Abfrage von Active Directory durch, um die Position des Postfachs des Benutzers sowie die Version von Microsoft Exchange zu ermitteln, die auf dem Postfachserver installiert ist.

  2. Wenn das Postfach des Benutzers sich auf einem Server mit Exchange 2003 befindet und der Benutzer versucht, über "https://domain name/owa" auf Outlook Web App zuzugreifen, wird ein Fehler ausgegeben, weil ein Clientzugriffsserver mit Exchange 2010 den Zugriff für Outlook Web App auf ein Postfach von Exchange 2003 nicht direkt bereitstellen kann. Wenn der Administrator jedoch die Umleitung von Exchange 2010 zu Exchange 2003 konfiguriert hat, was während einer Migration von Exchange 2003 zu Exchange 2010 im Allgemeinen der Fall ist, wurde die Eigenschaft Exchange2003URL des virtuellen Verzeichnisses von Outlook Web App auf den Wert eines Servers mit Exchange 2003 festgelegt, der über eine Internetverbindung verfügt.

  3. Wenn sich das Benutzerpostfach auf einem Postfachserver mit Exchange 2007 befindet, sucht CAS-01 einen Clientzugriffsserver an dem Active Directory-Standort, an dem sich der Postfachserver des Benutzers befindet. Wenn der Postfachserver mit Exchange 2007 sich am selben Active Directory-Standort befindet wie CAS-01, wird eine von vier möglichen Aktionen durchgeführt.

    • CAS-01 sucht nach einem Clientzugriffsserver mit Exchange 2007, dessen Eigenschaft ExternalURL dieselbe ExternalAuthenticationMethods-Einstellung aufweist wie die InternalAuthenticationMethods-Einstellung auf dem Clientzugriffsserver mit Exchange 2010. Wenn die Einstellung übereinstimmt, führt CAS-01 eine Umleitung an diese externe URL durch. Wenn für den Quell- und Ziel-Clientzugriffsserver die formularbasierte Authentifizierung aktiviert ist, gibt dieser ein verborgenes Formular an den Browser zurück, das neben der Umleitungs-URL die Benutzerberechtigungen und FBA-Einstellungen enthält. Dieser Vorgang ist für den Benutzer transparent.

    • Wenn keine übereinstimmende Einstellung für ExternalURL gefunden wird, sucht CAS-01 nach einem Clientzugriffsserver mit Exchange 2007, für den die Eigenschaft ExternalURL konfiguriert ist, auch wenn keine Übereinstimmung besteht. Wenn ein solcher Server gefunden wird, führt CAS-01 eine Umleitung an diese externe URL durch. In diesem Fall wird der Benutzer zur Authentifizierung aufgefordert.

    • Wenn keine übereinstimmende Einstellung für ExternalURL gefunden wird, sucht CAS-01 nach einem Exchange 2007Clientzugriffsserver, dessen Eigenschaft InternalURL dieselbe Einstellung für InternalAuthenticationMethods aufweist wie die Einstellung "InternalAuthenticationMethods" des Exchange 2010-Clientzugriffsservers. Wenn ein solcher Server gefunden wird, führt CAS-01 eine Umleitung an diese interne URL durch. Wenn die formularbasierte Authentifizierung aktiviert ist, ist das Ergebnis eine Umleitung mit einmaliger Anmeldung.

    • Wenn keine übereinstimmende Einstellung für "InternalURL" gefunden wird, sucht CAS-01 nach einem Clientzugriffsserver mit Exchange 2007, dessen Eigenschaft "InternalURL" konfiguriert ist, unabhängig von einer Übereinstimmung. Wenn ein solcher Server gefunden wird, führt CAS-01 eine Umleitung an diese interne URL durch. In diesem Fall wird der Benutzer zur Authentifizierung aufgefordert.

    Wenn sich der Postfachserver mit Exchange 2007 an einem anderen Active Directory-Standort befindet, bestimmt CAS-01, ob die Eigenschaft "ExternalURL" an diesem Active Directory-Standort festgelegt ist. Trifft dies zu, wird die standortübergreifende automatische Umleitung nicht aktiviert, der Wert "CrossSiteRedirectType" wird auf "Manuell" festgelegt, und eine manuelle Umleitung wird initialisiert. In diesem Szenario wird dem Benutzer ein klickbarer Link als Umleitung zur angegebenen URL bereitgestellt.

    Wenn die standortübergreifende automatische Umleitung aktiviert wurde, wird der Wert "CrossSiteRedirectType" auf "Automatisch" festgelegt, und der Benutzer wird automatisch an die angegebene URL weitergeleitet. Wenn die Eigenschaft "ExternalURL" nicht vorhanden ist und die Authentifizierungsmethode für das virtuelle Verzeichnis "/OWA" auf die integrierte Windows-Authentifizierung festgelegt ist, leitet CAS-01 die Benutzeranforderung per Proxy an den Clientzugriffsserver weiter, der in der Eigenschaft "InternalURL" angegeben ist.

    Wichtig

    Wenn Sie ermöglichen möchten, dass ein Clientzugriffsserver mit Exchange 2010 als Proxy Outlook Web App-Anforderungen an einen Clientzugriffsserver mit Exchange 2007 an einem anderen Active Directory-Standort weiterleitet, müssen Sie den Ordner mit der höchsten Version von einem Clientzugriffsserver mit Exchange 2007 am Active Directory-Zielstandort aus dem Ordner "%installpath%\ClientAccess\OWA" in den gleichen Pfad auf dem Clientzugriffsserver mit Exchange 2010 kopieren, der die Proxyanforderung stellt.

    Wichtig

    Ein Clientzugriffsserver mit Exchange 2010 leitet niemals Outlook Web App-Anforderungen per Proxy an einen Clientzugriffsserver mit Exchange 2007 am gleichen Active Directory-Standort weiter. Alle Anforderungen innerhalb desselben Active Directory-Standorts werden an einen Clientzugriffsserver mit Exchange 2007 umgeleitet. Dabei wird die Eigenschaft InternalURL oder ExternalURL des Clientzugriffsservers verwendet, je nachdem, welche Eigenschaften konfiguriert sind.

  4. Wenn das Postfach des Benutzers sich auf einem Postfachserver mit Exchange 2010 am Active Directory-Standort von CAS-01 befindet, stellt CAS-01 den Zugriff auf das Postfach bereit. Wenn sich das Benutzerpostfach auf einem Postfachserver mit Exchange 2010 an einem anderen Active Directory-Standort befindet, sucht CAS-01 einen Clientzugriffsserver am Active Directory-Standort mit dem Postfachserver des Benutzers. Wenn einer gefunden wird, bestimmt Exchange 2010, ob für den Clientzugriffsserver die Eigenschaft ExternalURL an diesem Active Directory-Standort festgelegt ist. Falls dies der Fall ist und die standortübergreifende automatische Umleitung nicht aktiviert wurde, wird dem Benutzer ein klickbarer Link als Umleitung zur angegebenen URL bereitgestellt. Wenn die standortübergreifende, automatische Umleitung aktiviert wurde, wird der Benutzer automatisch zur angegebenen URL weitergeleitet. Wenn ExternalURL nicht festgelegt ist und die Authentifizierungsmethode für das virtuelle Verzeichnis auf die integrierte Windows-Authentifizierung festgelegt ist, leitet CAS-01 die Benutzeranforderung per Proxy an den Clientzugriffsserver weiter, der in der Eigenschaft InternalURL angegeben ist.

Proxyfunktionen für die Exchange-Systemsteuerung

Exchange 2010 stellt eine webbasierte Benutzeroberfläche bereit, mit der Benutzer und Organisationsadministratoren Einstellungen für ihr Postfach oder für die Organisation konfigurieren können. Sie können auf die Exchange-Systemsteuerung in Outlook Web App über das Menü "Optionen" zugreifen oder in Outlook 2010, indem Sie die Optionen für Voicemail auswählen, Überwachungsinformationen für Nachrichten anfordern oder mobile Benachrichtigungen konfigurieren. Wenn Sie in Outlook eine dieser Optionen auswählen, wird eine Webbrowsersitzung gestartet.

Das Ziel der Sitzung hängt vom aktuellen Verbindungszustand des Outlook-Clients ab. Wenn der Outlook-Client über eine Verbindung mit RPC über TCP verfügt, stellt der Client eine Verbindung anhand des Werts von "InternalURL" für das virtuelle Verzeichnis der Exchange-Systemsteuerung her. Wenn der Client über eine Verbindung mit Outlook Anywhere verfügt, startet der Outlook-Client eine Browsersitzung. Es wird versucht, von der Browsersitzung aus eine Verbindung anhand des Werts "ExternalURL" für das virtuelle Verzeichnis der Exchange-Systemsteuerung herzustellen. Die URLs werden dem Outlook-Client über den AutoErmittlungsdienst bereitgestellt.

Wenn für einen internen Client eine TCP-Verbindung besteht, wird für die Sitzung der Exchange-Systemsteuerung immer eine Verbindung mit einem Clientzugriffsserver am Active Directory-Standort des Benutzerpostfachs hergestellt. Die Proxyfunktion wird in diesem Szenario nicht verwendet. Wenn ein Client außerhalb des Unternehmensnetzwerks Verbindungen über Outlook Anywhere herstellt, öffnet der Client eine Browsersitzung mit der externen URL des virtuellen Verzeichnisses der Exchange-Systemsteuerung oder mit der externen URL eines Active Directory-Standorts mit Internetverbindung, wenn sich das Benutzerpostfach an einem Standort ohne Internetverbindung befindet.

Die Proxylogik für die Exchange-Systemsteuerung ist die gleiche wie für Outlook Web App. Wenn sich das Benutzerpostfach auf einem Postfachserver mit Exchange 2010 am Active Directory-Standort des Clientzugriffsservers befindet, der die Anforderung empfängt, stellt dieser Clientzugriffsserver den Zugriff auf das Postfach bereit. Wenn sich das Benutzerpostfach auf einem Postfachserver mit Exchange 2010 an einem anderen Active Directory-Standort befindet, sucht der Clientzugriffsserver einen Clientzugriffsserver am Active Directory-Standort mit dem Postfachserver des Benutzers. Der ursprüngliche Clientzugriffsserver leitet die Benutzeranforderung per Proxy an diesen Clientzugriffsserver weiter.

Die Exchange-Systemsteuerung führt Umleitungen durch. Dies ist jedoch selten der Fall, außer wenn der Benutzer die URL zum Zugreifen auf die Exchange-Systemsteuerung explizit eingibt. Wenn ein Benutzer über Outlook Web App auf die Exchange-Systemsteuerung zugreift, stellt Outlook Web App sicher, dass der Benutzer die richtige URL verwendet. Wenn der Benutzer Outlook 2010 verwendet, stellen Outlook und der AutoErmittlungsdienst sicher, dass der Benutzer die richtige URL für die Exchange-Systemsteuerung verwendet.

Übersicht über die Verwendung von Proxyfunktionen

Proxyfunktionen für Exchange-Webdienste

Die Exchange-Webdienste stellen eine XML-Messagingschnittstelle bereit, über die Sie Elemente im Exchange-Informationsspeicher verwalten sowie von Clientanwendungen auf Funktionen des Exchange-Servers zugreifen können. Im Hinblick auf Proxys, Umleitungen und Clients wird diese Funktionalität im Allgemeinen in einem der folgenden Kontexte verwendet:

  • Verfügbarkeitsdienstanforderungen

  • AutoErmittlungsanforderungen

  • Festlegen und Überprüfen des Status der automatischen Antworten (Abwesenheitsnachrichten)

Eine unter Verwendung der Exchange-Webdienste geschriebene Anwendung kann Proxyfunktionen für Aufgaben wie das Festlegen einer automatischen Antwort (Abwesenheitsnachricht) verwenden, die bei Bedarf per Proxy zwischen Active Directory-Standorten weitergegeben wird.

In den folgenden Schritten wird gezeigt, wie eingehende Anforderungen für einen Benutzer verarbeitet werden, der eine Verfügbarkeitsdienstanforderung an den Clientzugriffsserver CAS-01 mit Exchange 2010 stellt. Der Benutzer verwendet Outlook Web App, um die Verfügbarkeit eines anderen Benutzers in derselben Exchange-Organisation zu überprüfen.

  1. CAS-01 führt eine Abfrage von Active Directory durch, um die Position des Postfachs des Benutzers sowie die Version von Microsoft Exchange zu ermitteln, die auf dem Postfachserver installiert ist.

  2. Wenn sich das Postfach des Benutzers auf einem Server mit Exchange 2003 befindet, stellt Outlook Web App eine HTTP-Verbindung mit dem virtuellen Verzeichnis "/Public" des Servers mit Exchange 2003 her und ruft die angeforderten Informationen aus dem Systemordner für Frei-/Gebucht-Informationen ab.

  3. Befindet sich das Postfach des Benutzers auf einem Postfachserver mit Exchange 2007, wird ein Fehler an den Benutzer zurückgegeben. In jeder Exchange-Organisation, in der es Postfächer auf einem Postfachserver mit Exchange 2007 gibt, muss ein extern zugänglicher Clientzugriffsserver mit Exchange 2007 vorhanden sein. Der AutoErmittlungsdienst ist dafür zuständig, die richtige Exchange-Webdienste-URL an den Client zurückzugeben. Diese URL muss zur Version des Postfachservers passen, auf dem sich das Postfach des Benutzers befindet.

  4. Wenn das Postfach des Benutzers sich auf einem Postfachserver mit Exchange 2010 am Active Directory-Standort von CAS-01 befindet, greift CAS-01 auf das Postfach zu, um die angeforderten Informationen abzurufen. Wenn das Postfach des Benutzers sich auf einem Postfachserver mit Exchange 2010 an einem anderen Active Directory-Standort befindet, verwendet CAS-01 beim Proxyvorgang für einen Clientzugriffsserver an diesem Active Directory-Standort den FQDN, der in der Eigenschaft InternalURL des virtuellen Verzeichnisses "/EWS" angegeben ist.

    Wichtig

    Ein Exchange-Clientzugriffsserver leitet Verfügbarkeitsdienstanforderungen per Proxy von einem Server an einen anderen weiter, unabhängig davon, ob die Eigenschaft ExternalURL festgelegt ist.

    Wichtig

    Einige Anwendungen der Exchange-Webdienste verwenden Webmethoden wie GetEvents und Unsubscribe, die eine sehr starke Clientzugriffsserver-Affinität aufweisen. Wenn ein Clientzugriffsserver eine solche Anforderung per Proxy an einen anderen Active Directory-Standort weiterleiten muss, kann er die Eigenschaft InternalNLBBypassURL des Clientzugriffsservers verwenden. Diese sollte immer auf den FQDN des Hostservers festgelegt sein. So wird sichergestellt, dass der Clientzugriffsserver, der die Anforderung durchführt, die Affinität mit einem bestimmten Clientzugriffsserver am Active Directory-Zielstandort aufrechterhalten kann.

Die Exchange-Webdienste stellen keine Umleitungsfunktionalität bereit, weil der AutoErmittlungsdienst, mit dem URLs für eine Anwendung bereitgestellt werden, die zum Zugreifen auf ein bestimmtes Postfach erforderlichen URLs bereitstellt. Wenn beispielsweise ein Postfach zwischen Active Directory-Standorten verschoben wird, empfängt Outlook die aktualisierten, für den Active Directory-Standort spezifischen URLs beim Senden der nächsten Abfrage vom AutoErmittlungsdienst. Dies kann manchmal dazu führen, dass ein Client Verfügbarkeitsdienstanforderungen an einen Clientzugriffsserver stellt, der sich an einem anderen Active Directory-Standort befindet als das betreffende Postfach. Da der Verfügbarkeitsdienst die Anforderungen dennoch verarbeitet und bei Bedarf per Proxy weiterleitet, hat dies keine Auswirkungen auf den Benutzer.

Wichtig

In jeder Exchange-Organisation, in der es Postfächer auf einem Postfachserver mit Exchange 2007 gibt, muss ein extern zugänglicher Clientzugriffsserver mit Exchange 2007 vorhanden sein. Wenn der AutoErmittlungsdienst die richtige Exchange-Webdienste-URL an einen anfordernden Client zurückgibt, stimmt diese URL mit der Version des Servers überein, in dem sich das Postfach des Benutzers befindet. Für jede Exchange-Organisation, die sowohl auf Postfachservern mit Exchange 2007 als auch auf Postfachservern mit Exchange 2010 Postfächer hat, müssen zwei externe URLs für Exchange-Webdienste konfiguriert sein (eine für jede installierte Version von Exchange).

Proxyfunktionen für POP3 und IMAP4

Exchange 2010 kann Proxyfunktionen für POP3- und IMAP4-Sitzungen zwischen Clientzugriffsservern und Active Directory-Standorten ausführen.

In den folgenden Schritten wird gezeigt, wie eingehende Anforderungen für einen Benutzer verarbeitet werden, der eine Anforderung an den Clientzugriffsserver CAS-01 mit Exchange 2010 stellt und dabei einen POP3-Client verwendet.

  1. CAS-01 führt eine Abfrage von Active Directory durch, um die Position des Postfachs des Benutzers sowie die Version von Microsoft Exchange zu ermitteln, die auf dem Postfachserver installiert ist.

  2. Wenn sich das Postfach des Benutzers auf einem Exchange 2003-Server befindet, gibt CAS-01 die Verbindung per Proxy an den POP3-Dienst weiter, der auf dem Exchange 2003-Server mit dem Postfach des Benutzers ausgeführt wird.

  3. Wenn sich das Postfach des Benutzers auf einem Postfachserver mit Exchange 2007 befindet, sucht CAS-01 einen Clientzugriffsserver mit Exchange 2007 am Active Directory-Standort des Postfachservers des Benutzers. Dieser befindet sich möglicherweise am selben Active Directory-Standort wie CAS-01. CAS-01 gibt die Anforderung per Proxy an den Clientzugriffsserver weiter.

  4. Wenn das Postfach des Benutzers sich auf einem Postfachserver mit Exchange 2010 am Active Directory-Standort von CAS-01 befindet, greift CAS-01 auf das Postfach zu. Wenn das Postfach des Benutzers sich auf einem Postfachserver mit Exchange 2010 an einem anderen Active Directory-Standort befindet, verwendet CAS-01 beim Proxyvorgang für einen Clientzugriffsserver den FQDN, der in der Eigenschaft InternalConnectionSettings der POP-Konfiguration für diesen Server angegeben ist.

    Wichtig

    Es sind keine Einstellungen für "InternalURL" oder "ExternalURL" für den POP3- oder IMAP4-Dienst vorhanden, und ein Clientzugriffsserver mit Exchange 2010 leitet POP3- und IMAP4-Dienstanforderungen bei Bedarf per Proxy von einem Server an einen anderen weiter.

    Wichtig

    Clientzugriffsserver, die versuchen, Anforderungen per Proxy an einen anderen Active Directory-Standort weiterzuleiten, überprüfen nicht, ob der POP3- oder IMAP4-Dienst wirklich auf dem Remote-Clientzugriffsserver ausgeführt wird. Daher ist es wichtig, nicht nur sicherzustellen, dass die Dienste auf jedem Clientzugriffsserver am Active Directory-Remotestandort ausgeführt werden, sondern auch die Verwendung eines Lastenausgleichs für den Dienst in Erwägung zu ziehen. Möglichkeiten für den Lastenausgleich werden weiter unten in diesem Thema erläutert.

Übersicht über die Verwendung von Proxyfunktionen

Proxykonfiguration

Wenn Ihr Clientzugriffsserver über eine Internetverbindung verfügt, legen Sie die Eigenschaft ExternalURL für die virtuellen Verzeichnisse "/Microsoft-Server-ActiveSync", "/OWA", "/ECP" und "/EWS" mithilfe der Exchange-Verwaltungskonsole oder der Exchange-Verwaltungsshell (Shell) fest. Das virtuelle Verzeichnis "/EWS" kann nur mithilfe der Shell konfiguriert werden. Die Eigenschaft InternalURL wird automatisch während des ersten Setups von Exchange 2010 konfiguriert und sollte nur geändert werden, wenn Sie eine Lastenausgleichslösung verwenden möchten. Die Eigenschaft ExternalURL sollte den FQDN enthalten, der für Ihre Exchange-Organisation in DNS registriert ist.

Die folgende Tabelle enthält die geeigneten Werte für die Eigenschaften ExternalURL und InternalURL für einen Clientzugriffsserver mit Internetverbindung für eine Exchange-Organisation, die über die URL "https://mail.contoso.com" auf Outlook Web App zugreift. Die zweite Tabelle enthält die geeigneten Werte für die Eigenschaften ExternalURL und InternalURL für einen Clientzugriffsserver ohne Internetverbindung an einem zweiten Active Directory-Standort für dieselbe Organisation. Sie müssen sicherstellen, dass die Authentifizierungsmethode für alle diese virtuellen Verzeichnisse auf die integrierte Windows-Authentifizierung festgelegt ist. Proxyfunktionen werden nicht für virtuelle Verzeichnisse unterstützt, für die andere Authentifizierungsmethoden verwendet werden, mit Ausnahme von POP3 und IMAP4, für die SSL/TLS verwendet wird und die Proxyfunktionen für die Anmeldeinformationen des Benutzers für die Standardauthentifizierung ausführen.

Hinweis

Wenn neue virtuelle Verzeichnisse von Outlook Web App mithilfe der Shell erstellt werden, müssen Sie die Eigenschaft InternalURL für diese virtuellen Verzeichnisse manuell konfigurieren.

Einstellungen für "InternalURL" und "ExternalURL" für einen Clientzugriffsserver mit Internetverbindung

Exchange 2010-Dienst InternalURL-Einstellung ExternalURL-Einstellung

Outlook Web App

https://vollqualifizierterComputername/OWA

https://mail.contoso.com/OWA

Exchange ActiveSync

https://vollqualifizierterComputername/Microsoft-Server-ActiveSync

https://mail.contoso.com/Microsoft-Server-ActiveSync

Exchange-Webdienste

https://vollqualifizierterComputername/EWS/Exchange.asmx

https://mail.contoso.com/EWS/Exchange.asmx

Exchange-Systemsteuerung

https://vollqualifizierterComputername/ECP

https://mail.contoso.com/ECP

Einstellungen für "InternalURL" und "ExternalURL" für einen Clientzugriffsserver ohne Internetverbindung

Exchange 2010-Dienst InternalURL-Einstellung ExternalURL-Einstellung

Outlook Web App

https://vollqualifizierterComputername/OWA

$Null

Exchange ActiveSync

https://vollqualifizierterComputername/Microsoft-Server-ActiveSync

$Null

Exchange-Webdienste

https://vollqualifizierterComputername/EWS/Exchange.asmx

$Null

Exchange-Systemsteuerung

https://vollqualifizierterComputername/ECP

$Null

Konfigurieren der Umleitung

Wenn mehr als einer Ihrer Active Directory-Standorte über eine Internetverbindung verfügt, legen Sie die Eigenschaft ExternalURL für die virtuellen Verzeichnisse "/OWA" und "/Microsoft-Server-ActiveSync" mithilfe der Exchange-Verwaltungskonsole oder der Shell fest, um Umleitungen zwischen ihnen zu ermöglichen. Die Eigenschaft InternalURL wird automatisch während des ersten Setups von Exchange 2010 konfiguriert und sollte nur geändert werden, wenn Sie eine Lastenausgleichslösung verwenden möchten. In den folgenden beiden Tabellen werden die Einstellungen für die Eigenschaften "ExternalURL" und "InternalURL" für Clientzugriffsserver an zwei Active Directory-Standorten des Unternehmens Contoso aufgeführt. Bei diesen beiden Standorten handelt es sich um "usa.contoso.com" und "europe.contoso.com".

Hinweis

Wenn neue virtuelle Verzeichnisse von Outlook Web App mithilfe der Shell erstellt werden, müssen Sie die Eigenschaft InternalURL für diese virtuellen Verzeichnisse manuell konfigurieren.

Einstellungen der Eigenschaften "InternalURL" und "ExternalURL" für einen Clientzugriffsserver mit Internetverbindung am Standort "usa.contoso.com"

Exchange 2010-Dienst InternalURL-Einstellung ExternalURL-Einstellung

Outlook Web App

https://vollqualifizierterComputername/OWA

https://usa.contoso.com/OWA

Exchange-Systemsteuerung

https://vollqualifizierterComputername/ECP

https://usa.contoso.com/ECP

Exchange ActiveSync

https://vollqualifizierterComputername /Microsoft-Server-ActiveSync

https://usa.contoso.com/ Microsoft-Server-ActiveSync

Exchange-Webdienste

https://vollqualifizierterComputername/EWS/Exchange.asmx

https://usa.contoso.com/EWS/Exchange.asmx

Einstellungen der Eigenschaften "InternalURL" und "ExternalURL" für einen Clientzugriffsserver mit Internetverbindung am Standort "europe.contoso.com"

Exchange 2010-Dienst InternalURL-Einstellung ExternalURL-Einstellung

Outlook Web App

https://vollqualifizierterComputername/OWA

https://europe.contoso.com/OWA

Exchange-Systemsteuerung

https://vollqualifizierterComputername/ECP

https://europe.contoso.com/ECP

Exchange ActiveSync

https://vollqualifizierterComputername /Microsoft-Server-ActiveSync

https://europe.contoso.com/ Microsoft-Server-ActiveSync

Exchange-Webdienste

https://vollqualifizierterComputername/EWS/Exchange.asmx

https://europe.contoso.com/EWS/Exchange.asmx

Hinweis

Wenn die Eigenschaft ExternalURL des virtuellen Exchange ActiveSync-Verzeichnisses nicht an mindestens einem Active Directory-Standort festgelegt ist, schlägt der AutoErmittlungsdienst beim Konfigurieren von Mobiltelefonen fehl, weil der für die Eigenschaft ExternalURL festgelegte Wert während des AutoErmittlungsvorgangs an die Mobiltelefone übergeben wird.

Übersicht über die Verwendung von Proxyfunktionen

Proxyfunktionen mit Netzwerklastenausgleich

In einer Organisation mit mehreren Active Directory-Standorten und mehreren Clientzugriffsservern an jedem Standort können Sie NLB (Network Load Balancing, Netzwerklastenausgleich) für Benutzer verwenden, die direkt auf diese Server zugreifen, und um den per Proxy zwischen den Clientzugriffsservern an jedem Standort weitergeleiteten Datenverkehr zu verteilen. Die reine Bereitstellung einer Lastenausgleichsfunktion ist nicht ausreichend, um Datenverkehr effektiv zu verteilen. Außerdem müssen Sie einige zusätzliche Konfigurationsschritte für die Eigenschaften InternalURL und ExternalURL ausführen. Es empfiehlt sich, nur Clientzugriffsserver innerhalb desselben Active Directory-Standorts in ein Lastenausgleichsarray aufzunehmen. Sie können den Netzwerklastenausgleich an einem Active Directory-Standort mit Internetverbindung und an einem Active Directory-Standort ohne Internetverbindung bereitstellen.

In der folgenden Tabelle sind die Einstellungen aufgeführt, die Sie für die virtuellen Verzeichnisse auf den Clientzugriffsservern an Standorten mit und ohne Internetverbindung konfigurieren sollten. Der FQDN des Netzwerklastenausgleichs sollte im DNS konfiguriert werden, damit das Gerät oder der Dienst für den Lastenausgleich aufgelöst werden kann. Die Lastenausgleichslösung leitet dann den Datenverkehr an die geeigneten Clientzugriffsserver weiter.

Einstellungen der virtuellen Verzeichnisse für Clientzugriffsserver in einer Organisation, die den Netzwerklastenausgleich verwendet

Virtuelles Verzeichnis/Dienst InternalURL ExternalURL (Active Directory-Standort mit Internetverbindung) ExternalURL (Active Directory-Standort ohne Internetverbindung)

/OWA

NLB-FQDN (siehe die folgenden Richtlinien)

NLB-FQDN

$null

/ECP

NLB-FQDN (siehe die folgenden Richtlinien)

NLB-FQDN

$null

/Microsoft-Server-ActiveSync

NLB-FQDN

NLB-FQDN

$null

/OAB

NLB-FQDN

NLB-FQDN

$null

/EWS

NLB-FQDN

NLB-FQDN

$null

POP/IMAP

(InternalConnectionsSettings)

NLB-FQDN

Nicht zutreffend

Nicht zutreffend

Es wird empfohlen, bei der Einrichtung der Eigenschaft "InternalURL" die folgenden Richtlinien zu befolgen:

  • Die Eigenschaft "InternalURL" für die virtuellen Verzeichnisse "/OWA" und "/ECP" auf allen Clientzugriffsservern an einem Active Directory-Standort kann auf den NLB-FQDN der Server an diesem Standort festgelegt werden, falls interne Outlook 2010-Benutzer vorhanden sind.

  • Wenn ein Clientzugriffsserver an einem Active Directory-Standort das Ziel einer Outlook Web App- oder ECP-Proxyanforderung von einem Clientzugriffsserver an einem beliebigen anderen Active Directory-Standort ist, müssen Sie Ihre Lastenausgleichsfunktion so konfigurieren, dass die Affinität gewahrt bleibt. Grund dafür ist, dass der Clientzugriffsserver an dem mit dem Internet verbundenen Standort nicht für jede Anforderung einen Server auswählen und die eigene Affinität wahren kann.

In der folgenden Tabelle werden die unterschiedlichen Authentifizierungseinstellungen aufgelistet, die für virtuelle Verzeichnisse in einer Organisation mit Netzwerklastenausgleich erforderlich sind. In einer Organisation mit Netzwerklastenausgleich wird die Netzwerklastenausgleichs-URL statt einer spezifischen Clientzugriffsserver-URL für Clientverbindungen verwendet.

Authentifizierungseinstellungen für virtuelle Verzeichnisse für Clientzugriffsserver in einer Organisation, die Netzwerklastenausgleichs-URLs für Fehlertoleranz und Lastenausgleich verwendet

Virtuelles Verzeichnis/Dienst Active Directory-Standort mit Internetverbindung Active Directory-Standort ohne Internetverbindung

/OWA

Wenn Microsoft Forefront Threat Management Gateway 2010 (Forefront TMG) oder Microsoft Forefront Unified Access Gateway 2010 (Forefront UAG) verwendet werden und die formularbasierte Authentifizierung aktiviert ist, verwenden Sie die Standardauthentifizierung oder die integrierte Windows-Authentifizierung, je nach den Firewalleinstellungen für die Regeldelegierung.

Wenn Datenverkehr aus dem Internet ohne vorherige Authentifizierung an den Clientzugriffsserver übergeben wird, verwenden Sie die formularbasierte Authentifizierung.

Dieselbe Authentifizierungsmethode sollte für die virtuellen Verzeichnisse "/OWA" und "/ECP" aktiviert sein.

Integrierte Windows-Authentifizierung

/ECP

Wenn Forefront TMG oder Forefront UAFG verwendet werden und die formularbasierte Authentifizierung aktiviert ist, verwenden Sie die Standardauthentifizierung oder die integrierte Windows-Authentifizierung, je nach den Firewalleinstellungen für die Regeldelegierung.

Wenn Datenverkehr aus dem Internet ohne vorherige Authentifizierung an den Clientzugriffsserver übergeben wird, verwenden Sie die formularbasierte Authentifizierung.

Dieselbe Authentifizierungsmethode sollte für die virtuellen Verzeichnisse "/OWA" und "/ECP" aktiviert sein.

Integrierte Windows-Authentifizierung

/Microsoft-Server-ActiveSync

Standardauthentifizierung.

Standardauthentifizierung (Proxyfunktionen werden über das virtuelle Unterverzeichnis "/Proxy" ausgeführt).

/OAB

Standardauthentifizierung oder integrierte Windows-Authentifizierung, je nach den Firewalleinstellungen für die Regeldelegierung.

Die Standardauthentifizierung oder die integrierte Windows-Authentifizierung, je nach den Firewalleinstellungen für die Regeldelegierung (OAB-Anforderungen werden niemals per Proxy zwischen Active Directory-Standorten weitergeleitet. Dieses virtuelle Verzeichnis wird nur von Outlook-Clients verwendet.)

/EWS

Standardauthentifizierung (optional – je nach den Firewalleinstellungen für die Regeldelegierung).

Integrierte Windows-Authentifizierung erforderlich.

Integrierte Windows-Authentifizierung

POP/IMAP

Wie für die Clientverbindungsmethode erforderlich.

Wie für die Clientverbindungsmethode erforderlich.

Übersicht über die Verwendung von Proxyfunktionen

Von Clientzugriffsservern bei Proxyvorgängen zwischen Active Directory-Standorten verwendete Lastenausgleichslogik

Wenn am Zielstandort eines Proxyversuchs mehrere Clientzugriffsserver vorhanden sind und der Server, auf dem sich das Postfach des Benutzers befindet, zugleich Clientzugriffsserver und Postfachserver ist, wählt der Clientzugriffsserver am Active Directory-Quellstandort immer diesen kombinierten Clientzugriffsserver und Postfachserver als Ziel des Proxyversuchs aus.

Outlook Web App, die Exchange-Systemsteuerung und die Exchange-Webdienste verarbeiten den Lastenausgleich anders als der Verfügbarkeitsdienst und Exchange ActiveSync. Outlook Web App, die Exchange-Systemsteuerung und die Exchange-Webdienste implementieren ihren eigenen Lastenausgleich, wenn sie auf mehreren Clientzugriffsservern am selben Active Directory-Standort bereitgestellt werden. Wenn ein Benutzer versucht, über "https://mail.contoso.com/owa" auf Outlook Web App zuzugreifen, und per Proxy an CAS-01 weitergeleitet wird, wird dieser Benutzer beim nächsten Zugriff auf Outlook Web App ebenfalls an CAS-01 weitergeleitet. Dies passiert selbst dann, wenn CAS-02 weniger gleichzeitige Verbindungen aufweist. So wird sichergestellt, dass lang andauernde Transaktionen ohne erneute Authentifizierung oder erneutes Anfordern von Daten abgeschlossen werden können. Dies wird als Affinität bezeichnet. Wenn CAS-01 nicht verfügbar ist, wird der Benutzer per Proxy an CAS-02 weitergeleitet und muss möglicherweise die Authentifizierung erneut durchführen.

Exchange-Webdienste können die Affinität beibehalten, wenn sie per Proxy zwischen Active Directory-Standorten weitergeleitet werden, auch wenn die Eigenschaft InternalURL des Zielservers mit einer Netzwerklastenausgleichs-URL konfiguriert ist. Der Grund ist, dass der Clientzugriffsserver, der die Proxyanforderung für eine Anwendung mit Affinitätserfordernis ausführt, die Eigenschaft InternalNLBBypassURL auf dem Zielserver verwendet. Die Eigenschaft InternalNLBBypassURL wird mit dem FQDN des Zielservers konfiguriert und verwendet standardmäßig die Windows-Authentifizierung.

Hinweis

Für Outlook Web App, für die Exchange-Systemsteuerung und für die Exchange-Webdienste sollte die Firewall für auf Cookies basierende Affinität oder IP-Affinität konfiguriert sein. So wird sichergestellt, dass eine bestimmte Clientanwendung immer eine Verbindung zum selben Server herstellt. Dies ist erforderlich, damit die SSL-Aushandlung nicht wiederholt für jede Anforderung ausgeführt werden muss. Es ist wichtig, die Affinität von der Clientanwendung bis zum letzten an der Transaktion beteiligten Clientzugriffsserver durchgehend zu wahren.

Hinweis

Sie sollten den Wert der Eigenschaft InternalNLBBypassURL auf einem Clientzugriffsserver nicht ändern. Wenn Sie ihn ändern, unterbricht dies per Proxy weitergeleitete Exchange-Webdienstanforderungen.

Bei Exchange ActiveSync ist das Verfahren ein anderes. Wenn ein Clientzugriffsserver mit Internetverbindung eine Anforderung per Proxy an einen Clientzugriffsserver ohne Internetverbindung weiterleitet, sucht der anfordernde Clientzugriffsserver nach einem Clientzugriffsserver am Zielstandort und versucht mithilfe des Werts, der in der Eigenschaft InternalURL konfiguriert ist, eine Verbindung mit ihm herzustellen. Wenn der Server nicht antwortet, schlägt die Anforderung fehl, und ein Fehler wird an den Client zurückgegeben. Es wird empfohlen, den Roundrobin-Lastenausgleich in einem Netzwerklastenausgleichs-Array (NLB-Array) zu implementieren und die Eigenschaft InternalURL auf einen Wert für den Netzwerklastenausgleich festzulegen.

Außerdem wird ein Lastenausgleich für den Verfügbarkeitsdienst empfohlen. Bei Anforderungen des Verfügbarkeitsdiensts muss der Verbindungszustand nicht beibehalten werden. Anders ausgedrückt: Zwei aufeinander folgende Anforderungen des Verfügbarkeitsdiensts vom gleichen Client können über den Proxy an zwei unterschiedliche Clientzugriffsserver am Active Directory-Zielstandort weitergeleitet werden, ohne dass die Leistung beeinträchtigt wird, und es treten keine Authentifizierungsprobleme auf, wenn die Eigenschaft InternalURL auf einen Wert für den Lastenausgleich festgelegt wird. Außerdem hat das Festlegen der Eigenschaft InternalURL auf einen Wert für den Lastenausgleich intern Vorteile für alle Clients mit Outlook 2007 oder Outlook 2010, da der AutoErmittlungsdienst diesen Clients den Wert für den Lastenausgleich bereitstellt, der in der Eigenschaft InternalURL festgelegt ist, damit sie ihre Verfügbarkeitsdienstanforderungen abschließen können.

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

Hinweis

In vielen Bereitstellungen sind die Clientzugriffs- und Hub-Transport-Serverrolle auf demselben Computer installiert. In dieser Topologie kann der Netzwerklastenausgleich für die Clientzugriffs-Serverrolle getrennt von der Hub-Transport-Serverrolle konfiguriert werden. Zurzeit wird der Netzwerklastenausgleich für die Hub-Transport-Serverrolle nicht unterstützt. Für die Clientzugriffs-Serverrolle wird er jedoch unterstützt. Zum Konfigurieren des Netzwerklastenausgleichs für die Clientzugriffs-Serverrolle, nicht jedoch für die Hub-Transport-Serverrolle, konfigurieren Sie die Ports 80 und 443 für den Clientzugriff. Die Hub-Transport-Serverrolle implementiert eigene Hochverfügbarkeitseigenschaften innerhalb der Software.

Übersicht über die Verwendung von Proxyfunktionen

Zusammenfassung der Clientzugriffsmethoden

In der folgenden Tabelle werden die Protokolle zusammengefasst, die für den Zugriff auf Exchange 2010 verwendet werden. Darüber hinaus wird erläutert, wie diese Protokolle für die Proxy- und Umleitungsfunktion verwendet werden.

Clientzugriffsprotokolle für Umleitungs- und Proxyfunktion

Protokoll/Anwendung Umleitung zwischen Clientzugriffsservern unterstützt Proxyfunktion zwischen Clientzugriffsservern unterstützt Kommentare

Outlook Web App

Ja

Ja

Setzt für die Verwendung von Outlook Web App einen Clientzugriffsserver an jedem Active Directory-Standort voraus.

Exchange-Systemsteuerung

Ja

Ja

Setzt für die Verwendung der Exchange-Systemsteuerung einen Clientzugriffsserver an jedem Active Directory-Standort voraus.

Exchange ActiveSync

Ja

Ja

Setzt für die Verwendung von Exchange ActiveSync einen Clientzugriffsserver an jedem Active Directory-Standort voraus.

Exchange-Webdienste

Nein (der AutoErmittlungsdienst stellt den richtigen ExternalURL-Wert für die Anwendung bereit).

Ja

Setzt für die Verwendung der Exchange-Webdienste einen Clientzugriffsserver an jedem Active Directory-Standort voraus.

Verfügbarkeitsdienst

Nein (der AutoErmittlungsdienst stellt den richtigen ExternalURL-Wert für die Anwendung bereit).

Ja

Setzt für die Verwendung des Verfügbarkeitsdiensts einen Clientzugriffsserver an jedem Active Directory-Standort voraus.

POP3 und IMAP4

Nein

Ja

Setzt für die Verwendung des Verfügbarkeitsdiensts einen Clientzugriffsserver an jedem Active Directory-Standort voraus.

Leistung und Skalierbarkeit der Proxyfunktion

In einer Exchange 2010-Proxyumgebung kommt es häufig zu Leistungsverschlechterungen, wenn die Clientzugriffsserver viele gleichzeitige Anforderungen empfangen. Dieses Problem wird häufig von einem Mangel an Threads und verfügbaren Verbindungen aufgrund von Webdienstanforderungen von ASP.NET verursacht. Dies kann dazu führen, dass die Clientzugriffsserver Anforderungen zurückweisen oder dass es beim Verarbeiten von Anforderungen zu einer hohen Latenz kommt.

Zur Lösung dieser Probleme können Sie eine Reihe von ASP.NET-Parametern konfigurieren, indem Sie die Datei "Machine.config" auf den Clientzugriffsservern bearbeiten. Weitere Informationen zum Konfigurieren dieser Parameter finden Sie im Microsoft Knowledge Base-Artikel 821268 Konflikte, Leistungsabfälle und Blockaden bei Webdienstanforderungen von ASP.NET-Anwendungen.

Zwei der Parameter, die im Knowledge Base-Artikel 821268 erörtert werden, müssen in einer Exchange 2010-Proxyumgebung anders festgelegt werden. Es empfiehlt sich, 36 Threads pro Prozessor zuzulassen und den Wert von maxconnections auf 2.000 festzulegen.

Weitere Informationen zur Serverleistung finden Sie im Webcast Verwalten von .NET Framework unter Windows Server 2003.

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.