Partager via

Exchange 2013 のクライアント アクセス サーバー ロールに OWA/ECP の仮想ディレクトリを複数構成する

  • Article

(この記事は 2015 年 2 月 11 日に Office Blogs に投稿された記事 Configuring Multiple OWA/ECP Virtual Directories on the Exchange 2013 Client Access Server Role の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

 

以前、Exchange Server 2007/2010 で OWA や ECP の仮想ディレクトリを複数セットアップする方法を公開しましたが、今回は新たに Exchange Server 2013 でのセットアップ方法をお知らせします。

セットアップの目的が変わったわけではなく、方法が異なるだけなので、この記事は過去の記事から部分的に流用しています。

概要: Exchange 2013 クライアント アクセス サーバー ロールを持つサーバーで、複数の Outlook Web App (OWA) および Exchange コントロール パネル (ECP)/管理センターのフロントエンド仮想ディレクトリを使用することができます。ただし、それぞれのディレクトリはそれ自身の Web サイト上に存在し、かつ 「OWA」または「ECP」という名前である必要があります。また、各仮想ディレクトリで、標準の TCP 443 ポートでサイトへの通信をリッスンする必要があります。

注: 既定の Web サイトで IP の設定が [All Unassigned] になっていることを必ず確認してください。この設定が誤っていると PowerShell で問題が発生します。

このような構成を使用するシナリオとしては、主に次の 3 つが考えられます。それぞれのシナリオで考慮事項が少しずつ異なります。これは、Exchange 2010 の際に説明したものと同じです。

  • シナリオ 1: インターネットに接続されている Active Directory サイトが 1 つ存在し、Exchange のフロントにリバース プロキシ (Microsoft Forefront Threat Management Gateway や Unified Access Gateway など) を使用している。
    ファイアウォールから Exchange に認証情報を委任している (クライアント アクセス サーバー (CAS) で基本認証または統合 Windows 認証 (IWA) を使用し、フォーム ベース認証 (FBA) を使用していない) が、内部と外部のすべてのユーザーが FBA を使用できるようにする必要がある。
  • シナリオ 2: インターネットに接続されていない Active Directory サイトが 1 つ存在し、内部と外部のすべてのユーザーが FBA を使用できるようにする必要がある。この構成では、外部ユーザーが OWA や ECP にアクセスできるようにするために、インターネットに接続されているサイトの CAS は、インターネットに接続されていないサイトの CAS への要求をプロキシ転送する必要があります。そのためにはインターネットに接続されていないサイトの CAS では IWA が有効である必要があり、その結果 FBA は無効化されている。
  • シナリオ 3: 組織内の複数のユーザーがそれぞれ異なる OWA エクスペリエンス (異なるパブリック/プライベート ファイル アクセス、その他のポリシーやセグメント化機能など) を必要としている (念のためお伝えしておくと、OWA のカスタマイズとブランディングは Exchange 2013 でサポートされる部分が異なるので、この構成を検討する理由にはなりません)。

Exchange 2013 では状況が少し変わりましたので説明したいと思います。シナリオ 1 とシナリオ 2 については、Web サイトの追加といった追加の構成作業を行わなくても、既定の状態のままでセットアップできます。

Exchange 2013 では、OWA や ECP の仮想ディレクトリで、統合 Windows 認証と同時にフォーム ベース認証も有効化できるようになりました。このため、Threat Management Gateway や Unified Access Gateway から Exchange への経路で、NTLM の委任や KCD の使用が可能です。また、OWA では、OWA への接続元が他の Exchange Server ではなくブラウザーであるということを判定できるため、シナリオ 2 の場合でも既定のままの状態でセットアップすることができます。このとき、クライアントで FBA を有効にしてもプロキシを使用できます。

また、Exchange 2013 では考慮事項が増えました。クライアントに接続されている ECP の設定ページと Exchange 管理コンソール (EAC) の設定ページが分割された点です。どちらの設定ページにも ECP 仮想ディレクトリからサービスが提供されるため、その違いはわかりづらいかもしれません。基本的に、ECP 仮想ディレクトリ内のコードは、ユーザーのログイン時の認証情報に応じて、個人の ECP ページまたは管理者の EAC ページのどちらかのサービスを提供します。つまり、インターネットから /ECP フォルダーへのアクセスを許可する場合 (OWA ユーザーや Outlook ユーザーが ECP にアクセスする際に必要です)、同時に、管理者用の認証情報を所有しているユーザーが EAC にログインすることも許可する必要があります。そのため、この設定方法は好まれないこともあります。

以上をまとめると、OWA や ECP の仮想ディレクトリを複数作成する必要があるとすれば、次のような場合が考えられます。

  1. 管理者とユーザーの ECP へのアクセスを分離する。
  2. 前述のシナリオ 3 のように、ユーザーごとに異なるポリシーや設定、認証要件を適用する。

これで条件が明確になりました。次に、このほかにお伝えすべきことや注意事項について説明したいと思います。

マイクロソフトでは、新しい IP アドレスを使用した新しい IIS Web サイトに追加の OWA/ECP 仮想ディレクトリを作成し、それらをクライアント アクセス用のみに使用する方法をサポートしています。これらの新しい仮想ディレクトリでは、既定で FBA が有効で、内部または外部の URL の値は持っていません。

FBA が有効になった OWA/ECP サイトへの接続に使用するユーザー名が、インストールされているすべての証明書に存在し、その名前が正しい IP アドレスに解決されるように DNS が設定されている必要があります。

ほかにも次の点に注意する必要があります。

  • Exchange が Windows 2008 R2 にインストールされている場合、DNS の登録に関する問題を回避するために、次の修正プログラムを適用することをお勧めします。
    https://support2.microsoft.com/default.aspx?scid=kb;ja-jp;2386184 (機械翻訳)
  • あるサイトでリソースの消費が激しく速度が低下している場合、該当するアプリケーション プール内のすべての Web サイトの速度が低下します。
  • アプリケーション プールをリサイクルする場合、そのアプリケーション プールでホストされているすべての Web サイトは一時的に処理を停止します。

以上で各シナリオの説明は終了です。考慮事項や潜在的な問題を理解したうえでセットアップの手順を進めてください。

なお、もう 1 つ注意していただきたいのが次の点です。マイクロソフトがサポートできるのは、これから説明する手順に従っていただいた場合のみです。 手順を省略したり、ご自身の環境に合わせて変更したり、独自の解釈で作業を進めた場合は、サポート対象外となりますのでご注意ください。また、手順を守らな かったためにエンド ユーザーに悪影響が及んでしまう可能性もありますので、必ず下記の説明に従って手順を進めてください。

それでは、各手順の説明を始めます。

この手順では、統合 Windows 認証のみを使用するように、既定の Web サイトを設定します。また、新しい仮想ディレクトリを、新たにサポートされた FBA に対応するように構成します。特に何もしないと既定の Web サイトも FBA に対応した構成のままになりますが、必要に応じてこれを無効にする手順も説明しています。

1. セカンダリ IP アドレスをサーバーに追加します。この手順では、追加の NIC を使用しても、既存の NIC に IP を追加してもかまいません。
2. NIC を追加した場合は、ネットワーク プロパティの設定画面で NIC の IPv4 について [register this connection in DNS] のチェックボックスをオフにします (この設定により IPv6 でも登録されなくなります)。
3. IIS で新しいルート フォルダー (C:\inetpub\OWA_SECONDARY) に追加の Web サイトを作成し、新しい IP アドレスにバインドします。SSL を有効化する場合は、このサイトで使用する証明書を選択します。


4. ローカルの IIS_IUSRS グループの読み取りおよび実行のアクセス許可を C:\inetpub\OWA_SECONDARY フォルダーに付与します。
5. 既定の Web サイトのルート フォルダーの中身をサブフォルダーも含めてすべて、新しいサイトのルート フォルダーにコピーします (例: %SystemDrive%\inetpub\wwwroot\ の中身を C:\inetpub\OWA_SECONDARY へ)。
6. 新たに OWA と ECP のサブフォルダーを新しい Web サイトのルート フォルダーに作成します (C:\inetpub\OWA_SECONDARY\OWA および C:\inetpub\OWA_SECONDARY\ECP)。
7. 既定の Web サイトの OWA および ECP のフォルダーの中身をサブフォルダーも含めてすべて、新しい Web サイトの新しいサブフォルダーにコピーします (コピー元: /…/FrontEnd/HttpProxy)。
8. 下記のコマンドを実行します (コマンド内の <Server> の部分は CAS ロールをホストしているサーバー名に変更してください)。
a. New-OwaVirtualDirectory -Server <Server> -Role ClientAccess -WebSiteName OWA_SECONDARY -Path "C:\inetpub\OWA_SECONDARY\OWA"
b. New-EcpVirtualDirectory -Server <Server> -Role ClientAccess -WebSiteName OWA_SECONDARY -Path "C:\inetpub\OWA_SECONDARY\ECP"


9. 次のコマンドを実行して、既定のサイトで IWA のみが有効となるようにします (この手順はオプションですので、必要な場合のみ実行してください)。
a. Set-OwaVirtualDirectory -Identity "<server>\owa (Default Web Site)" -FormsAuthentication $false -WindowsAuthentication $true
b. Set-EcpVirtualDirectory -Identity "<server>\ecp (Default Web Site)" -FormsAuthentication $false -WindowsAuthentication $true
10. IISReset コマンドを実行します。
11. 動作確認を行います。

最後に、上記の変更を行ったサーバーに累積更新プログラム (CU) を適用するときの注意事項について説明します。CU をインストールすると、セカンダリの OWA または ECP の Web サイトのファイルが適切に更新されなかったり、セカンダリ サイトが正しく動作しなくなったりする場合があります。これはリソース フォルダーやファイルのバージョンの問題だけではありません。ディレクトリ内のファイルを更新するだけでは処理が正常に行われないため、追加の手順が必要となります。

この場合は、セカンダリの仮想ディレクトリと Web サイトをいったん削除して、すべての手順をやり直すという方法のみサポートされています。サイトで既定の設定を変更した箇所をすべてメモし、仮想ディレクトリ、Web サイトの順に削除し (この手順は必ず行ってください)、フォルダー内の中身をすべて削除します。その後、上記の手順 3 からやり直し、Web サイトの再作成、仮想ディレクトリの再作成、最新ファイルのコピーを実行し、以前適用していた構成や設定のカスタマイズを再度適用します。各手順は省略せずに必ず行ってください。上記の手順をスクリプト化 (Web サイトの削除や作成もスクリプト化できます) すると、CU のインストール後にスクリプトを実行すれば、CU 適用後確実にこれらの手順を実行できます。

必要な手順は以上です。

この記事で構成についてのご理解を深めていただき、この手順をご利用いただけますと幸いです。また、ご不明な点やご意見がございましたら、ぜひコメントをお寄せください。

Greg Taylor
Office 365 カスタマー エクスペリエンス担当
主任プログラム マネージャー