(この記事は 2015 年 12 月 15 日に Exchange Team Blog に投稿された記事 Exchange Management Shell and Mailbox Anchoringの翻訳です。最新情報については、翻訳元の記事をご参照ください。)
Exchange 2013 および Exchange 2016 の次回の CU では、Exchange 管理シェル (EMS) から Exchange への接続方法が変更されます。以前のバージョンでは、お客様がサード パーティのアプリやスクリプトの負荷分散ソリューションをご利用の場合、Exchange 2016 以外のサーバーにルーティングされることがあります。この場合、Exchange 2016 のコマンドレットや機能に依存する一部の管理機能を利用できなくなります。今回は、この変更がExchange 組織にどのような影響を及ぼすのか、Exchange 管理者の皆様にわかりやすく詳細をご説明します。
Exchange 2010 では、特定のクライアントと特定のクライアント アクセス サーバー (CAS) との長期間にわたる関連付けを可能にするために、セッション アフィニティを使用していました。Exchange 2013 とその後の Exchange 2016 では、セッション アフィニティの要件が廃止されました。さらに、Exchange 2016 のリリースに伴い、Exchange 2013 と Exchange 2016 の間でプロキシ転送する機能が追加されました。これにより、Exchange 2013 サーバーを外部に公開し、トラフィックを Exchange 2016 サーバーにプロキシ転送することが可能になりました。そのため、Exchange 管理シェル (EMS) への接続が常に Exchange 2016 サーバーにルーティングされるように、Exchange 2013 CU11 と Exchange 2016 CU1 ではメールボックスのアンカー設定が導入されました。
メールボックスのアンカー設定では、CAS がユーザーのメールボックスの GUID を Active Directory から照会し、GUID を取得できた時点で HTTP プロキシがアクティブ マネージャーを参照してユーザーのメールボックスが含まれるデータベースを特定します。CAS がユーザーのメールボックスの場所を特定すると、適切なメールボックス サーバーにプロトコル要求がプロキシ転送されます。そのサーバーで障害が発生し、データベースが DAG に含まれている場合は、クライアント アクセス プロキシにより、対応するデータベースが格納された新しいアクティブなメールボックス サーバーにセッションがプロキシ転送されます。このプロセスは現在、OWA、ECP、EWS など、ほとんどのクライアント プロトコル (リモート PowerShell を除く) で利用されています。
これでクライアントの問題は解決されますが、Exchange 管理シェル (EMS) についてはどうでしょうか。Exchange 2013 RTM から Exchange 2013 CU10 と Exchange 2016 (RTM) では、メールボックスのアンカー設定のロジックによって PowerShell セッションをプロキシ転送するのではなく、ローカル サーバーに接続するか、Exchange 組織内の別の利用可能なサーバーにプロキシ転送します。つまり、Exchange Server 2013 サーバーにログオンした場合、Exchange 2016 で利用可能になった新しいコマンドレットを使用することはできません。使用するためには、Exchange 2016 サーバーに直接ログオンする必要があります。
Exchange Server 2013 CU11 (英語)および Exchange Server 2016 CU1 以降、Exchange 管理シェル (EMS) セッションでもメールボックスのアンカー設定が使用されるようになります。前述の環境ですべてのサーバーを Exchange 2013 CU11 および Exchange 2016 CU1 にアップグレードした場合、Exchange 管理シェルの動作が変更されます。つまり、ユーザーが Exchange サーバーにログオンして EMS を開くと、ユーザーのメールボックスが含まれるサーバーにセッションがプロキシ転送されるようになります。ユーザーのメールボックスが存在しない場合は、調停メールボックスを利用してメールボックスのアンカー設定のロジックを実行します。この場合、EMS セッションのプロキシ転送先は調停メールボックスがマウントされているサーバーになります。
ここで重要なのは、既存の Exchange Server 2010/Exchange Server 2013 組織を Exchange Server 2013/Exchange 2016 にアップグレードする場合、最上位のバージョンの Exchange メールボックス サーバーのデータベースに調停メールボックスを移行する必要がある点です。また、メールボックスが関連付けられている管理者アカウントも同様です。メールボックスの移行は、Exchange をインストールして正常に動作することを確認した後に行ってください。調停メールボックスを上位バージョンの Exchange に移行しないと、バージョンに適したタスクを利用できなかったり、Search-AdminAuditLog コマンドレットを実行したときにタスクが管理者監査ログに保存されなかったりといった問題が発生する可能性があります。主に使用される調停メールボックスは "SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}" ですが、このメールボックスを利用できない場合は、他の調停メールボックスを使用して接続できます。
次に、想定されるいくつかのシナリオに対処する方法をご紹介しましょう。
Exchange 2013 組織への Exchange 2016 のインストール
最初の Exchange 2016 サーバーのインストールを完了し、すべてが正常に動作していることを確認したら、すべての調停メールボックスを Exchange 2016 に移行する必要があります。そのためには、Exchange 管理センター (EAC) または Exchange 管理シェルを使用して、Microsoft Exchange の移行メールボックス、フェデレーション メールボックス、システム メールボックスをすべて移行します。
Exchange 管理シェルですべての調停メールボックスを移行するには、次のコマンドレットを実行します。
| [PS] C: \PowerShell> Get-Mailbox -Arbitration | New-MoveRequest -TargetDatabase <Exchange_2016_DataBase> |
Exchange 管理センターですべての調停メールボックスを移行するには、以下の手順を実行します。
1. EAC で、[Recipients]、[Migration] の順に選択します。
2. [New Add] アイコンをクリックし、[Move to a different database] をクリックします。
3. [New local mailbox move] ページで、[Select the users that you want to move] をクリックし、[Add] アイコンをクリックします。
4. [Select Mailbox] ページで、「Microsoft Exchange」と入力して検索し、以下の一覧に含まれるすべてのメールボックスを追加します。
5. [OK] をクリックして [Next] をクリックします。
6. [Move configuration] ページで、移行バッチの名前を入力し、[Target database] ボックスの横にある [Browse] をクリックします。
7. [Select Mailbox Database] ページで、システム メールボックスの移行先となるメールボックス データベースを追加します。選択したメールボックス データベースがバージョン 15.1 であることを確認してください。これは、データベースが Exchange 2016 サーバーにあることを表します。
8. [OK] をクリックして [Next] をクリックします。
9. [Start the batch] ページで、移行要求を自動的に開始および完了するためのオプションを選択し、[New] をクリックします。
接続先のサーバーを確認する方法
Exchange 管理シェルのコンソールには、常に最初の接続を受信した CAS サーバーの名前が表示されます。しかし、接続はバックグラウンドで別のメールボックス サーバーにプロキシ転送されている可能性があります。接続のプロキシ転送先のメールボックス サーバーを確認するには、次の手順を実行します。
Exchange 管理シェルを開き、次の単純なクエリを実行して、接続先の Exchange サーバーを確認します。
上記の EMS セッションの例では、ホスト E1501 から Get-ExchangeCertificate コマンドレットを実行したものの、サーバー E1503 の証明書が返されました。詳細を確認する場合は、HTTPProxy PowerShell のログ ディレクトリに移動して、プロキシ転送先のサーバーを確認できます (このパス内を検索する前に、エクスプローラーでパスを開いて所有権を取得する必要があります)。
上記の例では、接続は e1503.contoso.com にプロキシ転送されています。PowerShell 接続は実際にはサーバー e1503 で実行されているため、すべてのコマンドレットはこのサーバーに対して実行されます。使用するコマンドレットで -server スイッチがサポートされている場合は、これを利用してコマンドレットの実行対象となるサーバーを指定することが可能です。たとえば、Get-PowerShellVirtualDirectory を実行する場合、次のように対象のサーバーを指定できます。
フェールオーバー
管理者のメールボックスを用意していて、メールボックスをホストしているデータベースまたはメールボックスが含まれる DAG に障害が発生した場合、調停メールボックスが含まれるデータベースにプロキシ転送されます (そのため、このメールボックスを前述のように移行することをお勧めします)。こうすることで、常に組織内で最上位のバージョンの Exchange サーバーに対してコマンドレットを実行できます。
AD サイト間のプロキシ転送
データセンターがマルチサイトや地理的に離れている場合には、管理者のメールボックスがマウントされているデータセンターに EMS セッションがプロキシ転送されます。ほとんどの場合はこれで問題ありませんが、一部のタスクでは、ローカル サイトで管理者権限が必要になる場合があります。これに対応するには、サイトに調停メールボックスを用意して、メールボックスが関連付けられていない管理者アカウントでサーバーにログオンする必要があります。あるいは、対応するサイトでメールボックスが関連付けられている管理者アカウントを作成します。
重大な障害
EMS を開いても通信が切断されて Exchange サーバーに接続できない場合は、ローカルの PowerShell セッションに Exchange 用 PSSnapin を追加する必要があります。
Rob Whaley
Exchange および Office 365 担当ベータ エンジニア
※ 本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。