Share via

RPC クライアント アクセス クロスサイト接続の変更

  • Article

原文の記事の投稿日: 2012 年 5 月 30 日 (水曜日)

2 年ほど前、私は TechEd North America 2010 で「High Availability Design Considerations (英語)」というタイトルのセッションを行いました。その中で、メールボックスの移動およびクロスサイト データベース移行イベントの後での MAPI 接続の実現方法に関する変更について説明しました。残念なことに、プレゼンテーションを行った後で、この機能はカットされました。理由は、導入する必要のある変更が複雑であったことと、Service Pack 1 のリリースまでにテストを行う時間がなかったことです。そして、この作業の優先順位を上げようとがんばったのですが、Service Pack 2 にもこれらの変更は組み込まれませんでした。

悲しいことに、すべての機能カットを外科的方法で実行できるわけではなく、SP1 にはコード変更の名残が実際に存在していました。たとえば、Set-DatabaseAvailabilityGroup コマンドレットには AllowCrossSiteRPCClientAccess というプロパティがあります。この Boolean プロパティをどれほど設定してみても、製品の動作には何の影響もありません (たしかに … これこそが私が次の写真に奇妙な親近感を感じる理由です)。

タイトルなし

クロスサイト RPC クライアント アクセス接続の動作 (RTM、SP1、SP2 から SP2-RU2 まで)

話が逸れてしましました。まず最初に、基本的なことを抑えておきます。

Exchange 2010 では、クライアントがメールボックス関連のデータに接続してアクセスする方法に大きな変更が加えられました。それまでのバージョンとは異なり、クライアントはメールボックスのデータにアクセスするためにメールボックス サーバーの役割の情報ストアに直接接続しなくなりました。代わりに、クライアントはクライアント アクセス サーバー (CAS) の役割にある一連のサービスに接続し、CAS の役割内のサービスが、接続しているユーザーに代わって、MAPI/RPC を使用してメールボックスのデータにアクセスします。これは抽象化レイヤーと考えることができます。

基本的には、すべてのメールボックス関連の MAPI 接続がクライアント アクセス サーバーの役割の RPC Client Access サービスを経由するという、簡単な変更が行われました。この抽象化レイヤーを容易にするための変更により、データベース オブジェクトはメールボックス サーバーの子オブジェクトではなくなりました。そして、新しいプロパティ RPCClientAccessServer がメールボックス データベースに追加されました。このプロパティでは、特定のデータベースにアクセスするために使用する必要のある legacyExchangeDN が定義されています。このプロパティの値は FQDN です。高可用性および CAS 障害時のフォールト トレランスを保証するため、この値は負荷分散された CAS アレイの FQDN である必要があります。この負荷分散された FQDN は、RPC Client Access Server アレイと呼ばれます。

詳細については、Brian Day の投稿「Demystifying the CAS Array Object」の「Part 1」および「Part 2」を参照してください。

標準的な Outlook 環境

単一データセンター (または単一 Active Directory サイト) のシナリオでは、Outlook のすべてのバージョンの動作に一貫性があります。Outlook プロファイルの RPC エンドポイントは、RPC Client Access Server アレイです (または、何らかの理由でアレイを作成しなかった場合は特定の CAS。ただし、アレイを使用するようにしてください。繰り返して強調する理由がわからなければ、Brian の投稿をお読みください)。DAG 内で障害 (データベース障害、サーバー障害など) が発生しても、RPC エンドポイントは変わらないので、Outlook は引き続き同じ RPC Client Access Server アレイに接続します。CAS アレイ内で障害 (CAS 障害、負荷分散機能の障害など) が発生しても、RPC エンドポイントは変わらないので、Outlook は引き続き RPC Client Access Server アレイへの接続を試みます。

データセンター切り替えのシナリオでも、ガイダンスに従っている限り、Outlook のすべてのバージョンの動作は一貫しています。なぜでしょうか。データセンターの切り替えでは、プライマリ データセンターの RPC Client Access Server アレイの DNS エントリの IP アドレスを、スタンバイ データセンターの RPC Client Access Server アレイを指すように変更します。自動検出では、引き続き、RPC エンドポイントとして、プライマリ データセンターの RPC Client Access Server アレイが配布されます。既存の Outlook クライアントではいかなる構成も必要ありません。クライアントの DNS キャッシュが更新されると、クライアントはスタンバイ データセンターに存在するようになっているエンドポイントに接続します。このようなしくみをよく理解するには、クライアントも CAS も CAS が存在しているサイトのことは実際には問題ではないということを理解する必要があります。どちらも、接続できること、そしてクライアントの接続先の CAS がメールボックスへのアクセスを提供できるということを、受け入れているだけです。

クロスサイト データベース移行の動作

このシナリオを理解するには、マルチサイトの DAG を構成するときに、通常は、特定のデータベースの RPCClientAccessServer プロパティを、最低のアクティブ化優先番号を持つメールボックス データベースのコピーと同じ AD サイトに存在する RPC Client Access Server アレイと関連付けることを理解しておくことが重要です。次に示すのはその例です。

クロスサイト DAG-1

図 1: 2 つの Active Directory サイトを含むデータベース可用性グループ

         

データベースのコピーがスタンバイ データセンターでアクティブ化された場合、ユーザーは、最低のアクティブ化優先値を持つメールボックス データベースが存在している AD サイトの RPC Client Access Server アレイを、接続エンドポイントとして引き続き利用します。

クロスサイト DAG-2

図 2: スタンバイ Active Directory サイトで MDB1 データベースがアクティブ化されています

ソースの RPC Client Access Server アレイの RPC Client Access のログを確認すると、以下のようになっているでしょう。

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",

最低のアクティブ化優先値を持つメールボックス データベースが存在している AD サイトの RPC Client Access Server アレイにユーザーがアクセスできなくなった場合、Outlook クライアントは反対側のデータセンターに存在するメールボックスに接続できなくなります。つまり、データセンター停止イベントが発生し、データセンター切り替えプロセスを実行する必要があります。

このような動作を認識するもっと簡単な方法は、データベースの RPCClientAccessServer プロパティの値に関係なく、Outlook が構成されている RPC エンドポイント (到達可能であるものとします) に常に接続することです。

システムは RPCClientAccessServer の値を自動的に変更できるか?

図 3 で示されているように、システムがデータベースの RPCClientAccessServer の値を変更するのは、管理者がアクティブ化されたデータベース コピーの ActivationPreference の値を最低の値になるように (優先コピーになることを意味します) 変更する場合だけです。

クロスサイト DAG-3

図 3: MDB1 データベースがスタンバイ Active Directory サイトでアクティブ化され、RPCClientAccessServer プロパティが変更されています

しかし、既存の Outlook プロファイルを使用する Outlook クライアントは、(自動検出が変更を検出した場合であっても) 新しい RPC エンドポイントではなく、古い RPC エンドポイントを使用し続けます。これは、古い RPC エンドポイントが ecWrongServer 応答をクライアントに返さないためです。RPC エンドポイントは接続を受け付けます。したがって、Outlook は接続が動作しているので自動検出の応答を無視します。古い RPC エンドポイントにアクセスできなくなると、Outlook 2007/2010 は設定を更新します (一方、Outlook 2003 は自動検出を利用していないので更新しません)。いつでも、プロファイルを強制的に修復することで、Outlook に新しい RPC エンドポイントを使用させることができます。

クロスサイト データベース移行イベントの後で管理者が手動で RPCClientAccessServer の値を更新した場合の結果

図 2 に戻り、MBX-C のメールボックス データベース コピーがアクティブ化された後で (ActivationPreference の値が 1 より大きいとき)、管理者が手動で MDB1 の cas-sec.contoso.com を指し示すように RPCClientAccessServer の値を変更した場合、既存のプロファイルを使用する Outlook クライアントは、古い RPC エンドポイントが使用できる状態である限り (プロファイルの修復が問題を修正します)、新しい RPC エンドポイントではなく、古い RPC エンドポイントの使用を続けます。RPCClientAccessServer の値が変更された後で作成された Outlook プロファイルは、新しい RPC エンドポイントを使用します。

Active Directory サイト間でのメールボックスの移動

Exchange 2010 より前は、サーバー間でメールボックスを移動すると、Outlook RPC エンドポイントはメールボックスが存在するデータベースをホストしているメールボックス サーバー (またはクラスター化されたメールボックス サーバー インスタンス) を指すように更新されます。メールボックスの移動が完了した後、Outlook クライアントのユーザーには "Microsoft Exchange 管理者によって変更が行われました。Outlook を終了させてから再起動してください" というメッセージが表示されます。Outlook を再起動すると、クライアントは新しい RPC エンドポイントに接続します。

Exchange 2010 では、AD サイト間でメールボックスを移動しても、ユーザーにこのメッセージは表示されません。さらに、RPC エンドポイントは、移動後のメールボックスが存在する AD サイトのメールボックス データベースと関連付けられている RPC Client Access Server アレイを反映するようには更新されません。これは、古い RPC エンドポイントが ecWrongServer 応答をクライアントに返さないためです。RPC エンドポイントは接続を受け付けます。したがって、Outlook は接続が動作しているので自動検出の応答を無視します。古い RPC エンドポイントにアクセスできなくなると、Outlook は設定を更新します (これに対し、Outlook 2003 は自動検出を利用していないので更新しません)。いつでも、プロファイルを強制的に修復することで、Outlook に新しい RPC エンドポイントを使用させることができます。

これで、最初に示したロルキャットの写真の意味が理解できたことでしょう。

今後のこと … SP2 RU3 以降

私は、このような問題に対処する希望を諦めませんでした。何人か傷ついたものもいますが、RPC Client Access 開発チーム、Exchange Servicing チーム、そして私は、2 つの必要な変更を製品に組み込むために辛抱強く作業しました。1 つ目は、メールボックスが異なる AD サイトのデータベース間で単純に移動されたときの、Outlook のプロファイルの修正です。2 つ目は、クロスサイト データベース移行の結果として Outlook が現在アクティブ化されているデータベースの場所に対する最善の選択ではない CAS を使用するようになったときの、Outlook のプロファイルの修正です。

メールボックスの移動

SP2 RU3 をインストールした後、AD サイト間でメールボックスを移動すると、既定の動作として、すべてのバージョンの Outlook で、再起動を求めるメッセージが表示され、Outlook プロファイルの RPC エンドポイントが更新されます。

ソースの RPC Client Access Server アレイで RPC Client Access のログを確認すると、次のようになっています。

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:

RPC 操作 (ROP) が WrongServer (ecWrongServer と同じです) になっていることに注目してください。これにより、Outlook クライアントではプロファイルの検出が強制的に行われ、ディレクトリ内で見つかった新しい情報に基づいてプロファイルが更新されます。プロファイルが更新され、クライアントが再起動されると、クライアントは新しい RPC エンドポイントへの接続を確立します。

また、次のような場合にも "Microsoft Exchange 管理者によって変更が行われました。Outlook を終了させてから再起動してください" というメッセージが表示されます。

  1. New-MoveRequest で DoNotPreserveMailboxSignatureプロパティを指定したとき。
  2. ソースとターゲットのメールボックス データベースでパブリック フォルダー階層ストアが異なるとき。
  3. Exchange のレガシー バージョンから Exchange 2010 にメールボックスを移動したとき。

クロスサイト データベース移行イベント

クロスサイト データベース移行イベントの動作は、DAG プロパティ AllowCrossSiteRPCClientAccess の値に依存します。AllowCrossSiteRPCClientAccess プロパティの値を $true に設定すると、前のセクションで説明した動作が既定の動作になります。つまり、データベースがスタンバイ データセンターでアクティブ化された場合、最低のアクティブ化優先値を持つメールボックス データベースが存在する AD サイトの RPC Client Access アレイが、接続エンドポイントとして使用されます。

AllowCrossSiteRPCClientAccess プロパティの値を $false に設定すると (このプロパティの既定値は $false です)、Outlook プロファイルの RPC エンドポイントは、データベースがアクティブでマウントされている AD と同じ AD 内の RPC Client Access Server アレイに更新されます。RPCClientAccessServer プロパティは優先サイトを定義しているので更新されないことに注意してください。

クロスサイト DAG-4

図 4: MDB1 データベースはスタンバイ Active Directory サイトでアクティブ化され、Outlook プロファイルは自動的に更新されています

ソースの RPC Client Access Server アレイの RPC Client Access のログを確認すると、以下のようになっているでしょう。

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:

メールボックス移動のシナリオと同様に、WrongServer ROP により Outlook クライアントではプロファイルの検出が強制的に行われ、ディレクトリ内で見つかった新しい情報に基づいてプロファイルが更新されます。プロファイルが更新され、クライアントが再起動されると、クライアントは新しい RPC エンドポイントへの接続を確立します。

まとめ

SP2 RU3 (またはそれ以降) を使用すると、メールボックスを AD サイト間で移動した場合に、プロファイルが正しく更新されます。さらに、クロスサイト データベース移行のシナリオでは、クロスサイト RPC 接続を許可するか、またはアクティブ化されてマウントされたデータベースと同じ AD サイトの RPC Client Access Server アレイの使用を Outlook に強制するか (既定の動作) を、制御できます。今の私の気持ちを表すとしたら、次のようなものでしょう。

子猫ちゃん

Ross Smith IV
主席プログラム マネージャー
Exchange カスタマー エクスペリエンス

これはローカライズされたブログ投稿です。原文の記事は「RPC Client Access Cross-Site Connectivity Changes」をご覧ください。