Änderungen der Konnektivität bei standortübergreifendem RPC-Clientzugriff

Veröffentlichung des Originalartikels: 30.05.2012

Vor fast zwei Jahren habe ich auf der TechEd North America 2010 einen Vortrag mit dem Thema High Availability Design Considerations gehalten. Dabei habe ich die Änderungen an der MAPI-Konnektivität im Zusammenhang mit dem Verschieben von Postfächern und standortübergreifenden *over-Datenbankereignissen beschrieben, die wir zu der Zeit am Produkt vornahmen. Leider wurde dieses Feature aufgrund der Komplexität der dafür notwendigen Änderungen und der knappen Zeit für das Testing nicht in Service Pack 1 integriert. Obwohl ich mich sehr dafür eingesetzt habe, hat es auch für Service Pack 2 nicht gereicht.

Wenn ein Feature aus dem Produkt genommen wird, kommt es immer wieder vor, dass Teile der Codeänderungen erhalten bleiben. So war es auch bei SP1. Vielleicht ist Ihnen aufgefallen, dass das Set-DatabaseAvailabilityGroup-Cmdlet eine AllowCrossSiteRPCClientAccess genannte Eigenschaft besitzt. Eine Änderung dieser booleschen Eigenschaft hat leider jedoch keinerlei Auswirkung auf das Verhalten des Produkts (ich finde dieses Bild spricht Bände):

Verhalten der Konnektivität bei standortübergreifendem RPC-Clientzugriff (RTM, SP1, SP2 bis SP2-RU2)

Aber ich schweife ab - wenden wir uns zunächst den Grundlagen zu.

Mit Exchange 2010 hat sich die Art und Weise, wie sich Clients mit postfachbezogenen Daten verbinden und auf diese zugreifen, wesentlich verändert. Clients verbinden sich nicht mehr direkt mit dem Informationsspeicher der Postfachserverrolle, um auf Postfachdaten zuzugreifen, wie dies in den vorherigen Versionen der Fall war. Vielmehr verbinden sich Clients jetzt mit einer Reihe von Diensten der Clientzugriffs-Serverrolle. Diese Dienste innerhalb der Clientzugriffs-Serverrolle greifen dann wiederum auf Postfachdaten zu und verwenden dabei MAPI/RPC des Postfachservers im Namen des sich verbindenden Benutzers. Man kann sich das Ganze als eine Art Abstraktionsebene vorstellen.

Im Wesentlichen wurde eine einfache Änderung vorgenommen, die bewirkt, dass die gesamte postfachbezogene MAPI-Konnektivität über den RPC-Clientzugriffsdienst der Clientzugriffs-Serverrolle abgewickelt wird. Um diese Abstraktionsebene zu vereinfachen, sind die Datenbankobjekte nun keine untergeordneten Objekte des Postfachservers mehr. Die neue RPCClientAccessServer-Eigenschaft wurde zur Postfachdatenbank hinzugefügt und definiert das legacyExchangeDN-Element, über das auf die entsprechende Datenbank zugegriffen wird. Diese Eigenschaft hat einen FQDN als Wert. Dieser Wert sollte der FQDN eines Clientzugriffsserver-Arrays mit Lastenausgleich sein, um eine hohe Verfügbarkeit und Fehlertoleranz bei einem Ausfall des Clientzugriffsservers zu gewährleisten. Diesen FQDN mit Lastenausgleich bezeichnen wir auch als RPC-Clientzugriffsserver-Array.

Weitere Informationen finden Sie in den Beiträgen von Brian Day zum Thema "Entmystifizieren des Clientzugriffsserver-Arrayobjekts", Teil 1 und Teil 2.

Typisches Verhalten von Outlook

Alle Versionen von Outlook verhalten sich in einem Szenario mit nur einem einzelnen Datencenter (oder einem einzelnen Active Directory-Standort) gleich. Der RPC-Endpunkt des Outlook-Profils ist das RPC-Clientzugriffsserver-Array (oder ein einzelner Clientzugriffsserver, falls Sie aus einem bestimmten Grund kein Array erstellt haben. Dies sollten Sie allerdings tun. Ich verweise hier nochmals auf die Beiträge von Brian). Wenn innerhalb der Datenbankverfügbarkeitsgruppe (Database Availability Group, DAG) ein Fehler auftritt (Datenbankfehler, Serverfehler usw.), bleibt der RPC-Endpunkt unverändert. Outlook verbindet sich also mit dem gleichen RPC-Clientzugriffsserver-Array. Wenn innerhalb des Clientzugriffsserver-Arrays ein Fehler auftritt (Fehler des Clientzugriffsservers, Lastenausgleichsfehler usw.), bleibt der RPC-Endpunkt unverändert. Outlook versucht weiterhin, sich mit dem gleichen RPC-Clientzugriffsserver-Array zu verbinden.

Alle Versionen von Outlook verhalten sich in einem Szenario für einen Datencenterswitchover ebenfalls gleich, jedenfalls wenn Sie unserer Anleitung folgen. Warum? Weil sich bei einem Datencenterswitchover die IP-Adresse des DNS-Eintrags für das primäre RPC-Clientzugriffsserver-Array im Datencenter so ändert, dass sie nun auf die des RPC-Clientzugriffsserver-Arrays im Standbydatencenter verweist. Per AutoErmittlung wird weiterhin das primäre RPC-Clientzugriffsserver-Array als der RPC-Endpunkt übergeben. Vorhandene Outlook-Clients bedürfen keiner Rekonfiguration. Sobald der DNS-Cache auf dem Client aktualisiert wird, verbindet sich der Client einfach mit dem Endpunkt im Standbydatencenter. Dies funktioniert, da weder der Client noch der Clientzugriffsserver vom tatsächlichen Standort des Clientzugriffsservers abhängig sind. Beide gehen davon aus, dass sie eine Verbindung herstellen können und dass der Clientzugriffsserver, mit dem der Client verbunden ist, Zugriff auf das Postfach gewähren kann.

Verhalten bei einem standortübergreifenden *over-Datenbankereignis

Grundlage für das Verständnis dieses Szenario ist die Tatsache, dass beim Konfigurieren einer Datenbankverfügbarkeitsgruppe mit mehreren Standorten die RPCClientAccessServer-Eigenschaft für eine bestimmte Datenbank normalerweise mit dem RPC-Clientzugriffsserver-Array verknüpft wird, das an dem AD-Standort vorhanden ist, der über die Kopie der Postfachdatenbank mit der niedrigsten Aktivierungseinstellungsnummer verfügt. Beispiel:

Abbildung 1: Die Datenbankverfügbarkeitsgruppe erstreckt sich über zwei Active Directory-Standorte

Für den Fall, dass eine Kopie der Datenbank im Standbydatencenter aktiviert ist, verwendet der Benutzer weiterhin das RPC-Clientzugriffsserver-Array des AD-Standorts, an dem die Postfachdatenbank mit der niedrigsten Aktivierungseinstellungsnummer als Verbindungsendpunkt vorhanden ist.

Abbildung 2: MDB1-Datenbank wurde am AD-Standbystandort aktiviert

Wenn Sie sich das Protokoll des RPC-Clientzugriffsdienstes des RPC-Quellclientzugriffsserver-Arrays ansehen, finden Sie Folgendes:

2012-05-06T15:44:29.001Z,67,112,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SFPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,0,00:00:00.0468822,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 5/6/2012 3:43:23 PM, currently Mounted; LogonId: 5",

Bei einem Ereignis, bei dem das RPC-Clientzugriffsserver-Array des AD-Standorts ausfällt, der die Postfachdatenbank mit der niedrigsten Aktivierungseinstellungsnummer für den Zugriff durch den Benutzer enthält, sind Outlook-Clients nicht mehr in der Lage, sich mit den entsprechenden Postfächern im zugeordneten Datencenter zu verbinden. Anders ausgedrückt, ein Datencenterausfall macht das Durchführen eines Datencenterswitchover-Vorgangs notwendig.

Einfacher gesagt, Outlook verbindet sich immer mit dem konfigurierten RPC-Endpunkt (falls erreichbar) und zwar unabhängig vom Wert der RPCClientAccessServer-Eigenschaft der Datenbank.

Kann das System den Wert für RPCClientAccessServer automatisch ändern?

Das System ändert den Wert für RPCClientAccessServer in der Datenbank nur dann, wenn der Administrator die ActivationPreference-Nummer für die aktivierte Datenbankkopie so ändert, dass diese nun über den niedrigsten Wert verfügt (also zur bevorzugten Kopie wird). Siehe Abbildung 3.

Abbildung 3: Die MDB1-Datenbank wurde am AD-Standbystandort aktiviert und die RPCClientAccessServer-Eigenschaft wurde geändert

Outlook-Clients mit vorhandenem Outlook-Profil werden weiterhin den alten RPC-Endpunkt anstelle des neuen RPC-Endpunkts verwenden (selbst dann, wenn AutoErmittlung die Änderung bemerkt hat). Das liegt daran, dass der alte RPC-Endpunkt keine ecWrongServer-Antwort an den Client zurückgibt. Der RPC-Endpunkt akzeptiert die Verbindung, deshalb ignoriert Outlook die AutoErmittlung-Antwort, da eine funktionierende Verbindung besteht. Sollte der alte RPC-Endpunkt nicht mehr verfügbar sein, aktualisiert Outlook 2007/2010 die Einstellungen (Outlook 2003 würde dies nicht tun, da es AutoErmittlung nicht verwendet). Es ist jederzeit möglich, die Verwendung eines neuen RPC-Endpunkts zu erzwingen, indem eine Profilreparatur erzwungen wird.

Was passiert, wenn der Administrator den RPCClientAccessServer-Wert nach einem standortübergreifenden *over-Datenbankereignis manuell ändert?

Schauen wir uns noch einmal Abbildung 2 an: Wenn der Administrator den Wert für RPCClientAccessServer manuell ändern würde, so dass er, nachdem die Kopie der Postfachdatenbank auf MBX-C aktiviert wurde (für die der ActivationPreference-Wert größer als 1 ist), auf cas-sec.contoso.com für MDB1 verweist, dann verwenden Outlook-Clients mit einem vorhandenen Profil weiterhin den alten RPC-Endpunkt anstelle des neuen. Dies gilt so lange, bis der alte RPC-Endpunkt nicht mehr verfügbar ist (Profilreparaturen korrigieren diesen Fehler). Outlook-Profile, die nach der Änderung des RPCClientAccessServer-Wertes erstellt wurden, würden direkt den neuen RPC-Endpunkt verwenden.

Verschieben von Postfächern zwischen Active Directory-Standorten

Vor Exchange 2010 wurde der RPC-Endpunkt für Outlook aktualisiert, um auf den Postfachserver zu verweisen (oder einer Instanz eines Postfachserverclusters), der als Host für die Postfachdatenbank dient, falls Postfächer über Server hinweg verschoben wurden. Nach dem Verschieben der Postfächer wurde Benutzern des Outlook-Clients die Meldung “Der Microsoft Exchange-Administrator hat eine Änderung durchgeführt, die einen Neustart von Outlook erfordert” angezeigt. Nach einem Neustart stellte Outlook dann eine Verbindung mit dem neuen RPC-Endpunkt her.

Vielleicht ist Ihnen bei Exchange 2010 aufgefallen, dass Benutzern diese Meldung nicht angezeigt wird, wenn Sie Postfächer zwischen AD-Standorten verschieben. Zudem haben Sie möglicherweise festgestellt, dass auch der RPC-Endpunkt für Benutzer nicht aktualisiert wurde, um das RPC-Clientzugriffsserver-Array zu verwenden, das der am AD-Standort des Postfachs ausgeführten Postfachdatenbank zugeordnet ist. Das liegt daran, dass der alte RPC-Endpunkt keine ecWrongServer-Antwort an den Client sendet. Der RPC-Endpunkt akzeptiert die Verbindung, deshalb ignoriert Outlook die AutoErmittlung-Antwort, da eine funktionierende Verbindung besteht. Sollte der alte RPC-Endpunkt nicht mehr verfügbar sein, aktualisiert Outlook die Einstellungen (Outlook 2003 würde dies nicht tun, da es AutoErmittlung nicht verwendet). Es ist jederzeit möglich, die Verwendung eines neuen RPC-Endpunkts zu erzwingen, indem eine Profilreparatur erzwungen wird.

Jetzt kann ich mir sicher sein, dass Sie das LOLCat-Bild am Anfang des Beitrags verstehen.

Was bringt die Zukunft…SP2 RU3 und danach

Ich habe die Hoffnung nie aufgegeben, dass wir dieses Problem in den Griff bekommen. Ein paar von uns haben Wunden davon getragen, aber das Entwicklungsteam für den RPC-Clientzugriff, das Exchange Servicing-Team und ich haben unermüdlich daran gearbeitet, die beiden erforderlichen Änderungen in das Produkt zu integrieren. Bei der ersten Änderung geht es darum, das Problem mit dem Outlook-Profil zu beheben, wenn ein Postfach einfach zwischen Datenbanken an unterschiedlichen AD-Standorten verschoben wird. Die zweite Änderung betrifft das Szenario, in dem ein standortübergreifendes *over-Datenbankereignis dazu führt, dass Outlook einen Clientzugriffsserver verwendet, der nicht die optimale Wahl in Bezug auf den Standort der gerade aktivierten Datenbank darstellt.

Verschieben von Postfächern

Sobald Sie SP2 RU3 installiert haben, wird beim Verschieben von Postfächern zwischen AD-Standorten in allen Outlook-Versionen die Aufforderung zum Neustart angezeigt, und der RPC-Endpunkt für das Outlook-Profil wird aktualisiert.

Wenn Sie sich die Protokolle des RPC-Clientzugriffsdienstes des RPC-Quellclientzugriffsserver-Arrays ansehen, finden Sie Folgendes:

2012-05-06T14:43:03.875Z,37,1,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156267,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb2 last mounted on MBX-C.contoso.com at 5/5/2012 9:44:05 PM, currently Mounted; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:

Beachten Sie, dass der RPC-Vorgang (ROP) WrongServer lautet (auch als ecWrongServer bekannt). Dies zwingt den Outlook-Client zu einer Profilermittlung und einer Aktualisierung des Profils anhand der neuen Informationen im Verzeichnis. Das Profil wird aktualisiert, und der Client stellt nach dem Neustart eine Verbindung mit dem neuen RPC-Endpunkt her.

Und um der Frage zuvorzukommen - welche weiteren Bedingungen führen zum Anzeigen der Meldung “Der Microsoft Exchange-Administrator hat eine Änderung durchgeführt, die einen Neustart von Outlook erfordert”?

1. Wenn Sie für New-MoveRequest die DoNotPreserveMailboxSignature-Eigenschaft festlegen.
2. Wenn sich die Speicher für die Ordnerhierarchie der öffentlichen Ordner der Postfachdatenbank an Quelle und Ziel unterscheiden.
3. Wenn Sie Ihre Postfächer aus einer Vorversion von Exchange zu Exchange 2010 verschieben.

Standortübergreifendes *over-Datenbankereignis

Das Verhalten bei einem standortübergreifenden *over-Datenbankereignis hängt vom Wert der DAG-Eigenschaft AllowCrossSiteRPCClientAccess ab.  Setzen Sie den Wert für die AllowCrossSiteRPCClientAccess-Eigenschaft auf $true, ist das im vorherigen Abschnitt beschriebene Verhalten der Standard. Tritt der Fall ein, dass die Datenbank im Standbydatencenter aktiviert wird, verwendet der Benutzer weiterhin das RPC-Clientzugriffsserver-Array an dem AD-Standort mit der Postfachdatenbank mit der niedrigsten Aktivierungseinstellungsnummer als Verbindungsendpunkt.

Setzen Sie den Wert für die AllowCrossSiteRPCClientAccess-Eigenschaft auf $false (dies ist der Standard), wird der RPC-Endpunkt des Outlook-Profils aktualisiert und verwendet das RPC-Clientzugriffsserver-Array, das sich am gleichen AD-Standort befindet, an dem die Datenbank aktiviert und eingebunden ist. Beachten Sie, dass die RPCClientAccessServer-Eigenschaft nicht aktualisiert wird, da diese den bevorzugten Standort festlegt.

Abbildung 4: Die MDB1-Datenbank wurde am AD-Standbystandort aktiviert, und das Outlook-Profil wurde automatisch aktualisiert

Wenn Sie sich das Protokoll des RPC-Clientzugriffsdiensts des RPC-Quellclientzugriffsserver-Arrays ansehen, finden Sie Folgendes:

2012-05-06T15:12:42.958Z,47,7,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156262,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 3/6/2012 2:59:30 PM, currently InTransitSameSite; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:

Wie schon beim Verschieben von Postfächern zwingt der RPC-Vorgang (ROP) WrongServer den Outlook-Client zu einer Profilermittlung und einer Aktualisierung des Profils anhand der neuen Informationen im Verzeichnis. Das Profil wird aktualisiert, und der Client stellt nach dem Neustart eine Verbindung mit dem neuen RPC-Endpunkt her.

Schlussfolgerung

Wir haben also erreicht, was wir wollten! Mit SP2 RU3 (oder höher) können Sie sicherstellen, dass beim Verschieben von Postfächern zwischen AD-Standorten die Profile richtig aktualisiert werden. Zudem können Sie bei einem standortübergreifenden *-over-Datenbankereignis steuern, ob Sie eine standortübergreifende RPC-Konnektivität zulassen möchten oder die Outlook-Clients zwingen möchten, das RPC-Clientzugriffsserver-Array am gleichen AD-Standort zu verwenden, an dem auch die aktive und eingebundene Datenbank vorhanden ist (Standard). Es ist also nur folgerichtig, mit einem Bild abzuschließen:

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter RPC Client Access Cross-Site Connectivity Changes