プロキシとリダイレクトについて
適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3
トピックの最終更新日: 2016-11-28
Microsoft Exchange Server 2010 組織では、クライアント アクセス サーバーは、組織内の他のクライアント アクセス サーバーのプロキシとして動作できます。これは、組織内の異なる Active Directory サイトに複数のクライアント アクセス サーバーが存在し、それらのサイトの 1 つ以上がインターネットに公開されている場合に役立ちます。
クライアント アクセス サーバーは、Microsoft Office Outlook Web App URL 用と Exchange ActiveSync デバイス用のリダイレクトを実行することもできます。ユーザーがローカルの Active Directory サイトにはないクライアント アクセス サーバーに接続する場合、またはメールボックスを Active Directory サイト間で移動する場合、リダイレクトが役に立ちます。ユーザーが、より分かりやすい URL を使用する場合にも役立ちます。例えば、メールボックスが存在する Active Directory サイトに似ている URL などです。
クライアント アクセス サーバーの応答はプロトコルによって異なる場合があります。クライアント アクセス サーバーの所属先以外の Active Directory サイト内にメールボックスがあるユーザーの要求をクライアント アクセス サーバーが受信すると、クライアント アクセス サーバーは以下のアクションを行います。この場合、サーバーは、ユーザーのメールボックスと同じ Active Directory サイト内にあるクライアント アクセス サーバー上の関連仮想ディレクトリで ExternalURL プロパティがあるか調べます。ExternalURL プロパティが存在して、クライアントの種類でリダイレクトがサポートされている場合 (Outlook Web App または Exchange ActiveSync など)、クライアント アクセス サーバーはそのクライアントにリダイレクトを発行します。ExternalURL プロパティが存在しない場合、またはクライアントの種類でリダイレクトがサポートされない場合 (POP3 または IMAP4 など)、クライアント アクセス サーバーはターゲット Active Directory サイトへの接続のプロキシを試みます。
ここでは、プロキシとリダイレクトの概要、使用する状況、および各シナリオでのクライアント アクセス サーバーの構成方法について説明します。
注意
組織内に複数の Active Directory サイトがない場合は、プロキシまたはリダイレクト用に Exchange 2010 を構成する必要がありません。ただし、このトピックで後述するように URL の負荷分散の構成が必要になる場合があります。
注意
インターネットに公開されていないクライアント アクセス サーバーでは、別のクライアント アクセス サーバーからのプロキシ処理されたトラフィックを許可するために個別の Secure Sockets Layer (SSL) 証明書は必要ありません。既定では、Exchange 2010 でインストールされている自己署名入りの証明書を使用できます。ただし、これらの証明書は通常、Outlook Web App または Outlook などの内部クライアントによって信頼されていないため、それらを使用するとたいていの場合、証明書の警告が発生します。自己署名証明書付きのクライアント アクセス サーバーと同じ Active Directory サイトに内部クライアントがある場合、自己署名証明書をクライアントが信頼する証明機関で発行された証明書に置き換える必要があります。
目次
プロキシの概要
リダイレクトの概要
ネットワーク負荷分散によるプロキシ
クライアント アクセス方法の概要
プロキシのパフォーマンスとスケーラビリティ
プロキシの概要
Microsoft Exchange Server 2003 では、フロントエンド サーバーは HTTP 経由でバックエンド サーバーと通信します。Exchange Server 2007 および Exchange 2010 で、クライアント アクセス サーバーは RPC 経由で Exchange メールボックス サーバーと通信します。Exchange 2010 メールボックス サーバーを含む各 Active Directory サイトには、Exchange 2010 クライアント アクセス サーバーが必要です。1 つのクライアント アクセス サーバーが別のクライアント アクセス サーバーにトラフィックを送信するときにプロキシが発生します。Exchange 2010 クライアント アクセス サーバーは、次の場合に要求を転送できます。
Exchange 2010 クライアント アクセス サーバー間 2 つの Exchange 2010 クライアント アクセス サーバー間で要求をプロキシ処理することにより、複数の Active Directory サイトのある組織で、1 つのクライアント アクセス サーバーをインターネットに直接接続されたサーバーとして指定し、そのサーバーがサイト内のインターネット プレゼンスを持たないクライアント アクセス サーバーに要求をプロキシ処理できるようになります。インターネットに直接接続されたクライアント アクセス サーバーは、ユーザーのメールボックスの最も近くにあるクライアント アクセス サーバーに要求をプロキシ処理します。
Exchange 2010 クライアント アクセス サーバーと Exchange 2007 クライアント アクセス サーバーの間 1 つの Exchange 2010 サイト内、または Exchange 2007 サイト間の Active Directory クライアント アクセス サーバーと Active Directory クライアント アクセス サーバーの間で要求をプロキシ処理することにより、Exchange 2010 と Exchange 2007 が同じ組織内で共存できるようになります。アップグレードおよび共存の方法の詳細については、「Exchange 2003 クライアント アクセスからのアップグレード」および「Exchange 2007 クライアント アクセスからのアップグレード」を参照してください。
プロキシ処理は、Outlook Web App、Exchange ActiveSync、Exchange コントロール パネル (ECP)、POP3、IMAP4、および Exchange Web サービスを使用するクライアントでサポートされます。転送先のクライアント アクセス サーバーで転送元のクライアント アクセス サーバーと同じバージョンの Microsoft Exchange またはそれより前のバージョンの Microsoft Exchange が実行されている場合、クライアント アクセス サーバーから別のクライアント アクセス サーバーへのプロキシ処理がサポートされます (バージョン固有の URL が必要な場合を除く)。Exchange 2007 と Exchange 2010 の混在環境におけるバージョン固有の URL と従来のホスト名について詳しくは、「Exchange 2007 クライアント アクセスからのアップグレード」をご覧ください。Exchange 2010 と Exchange 2013 の混在環境におけるバージョン固有の URL と従来のホスト名について詳しくは、「従来の Exchange ホスト名の作成」をご覧ください。
警告
NTLM 認証を使用する IMAP4 クライアントが、ターゲット メールボックスが存在しない Active Directory サイト内のクライアント アクセス サーバーに接続しようとすると、接続は失敗します。ある Active Directory サイトから別のサイトに IMAP4 クライアントをプロキシする場合、別の認証方法を選択する必要があります。
注意
インターネット ベースのクライアントからのアクセスを許可する必要がある各 Exchange 組織では、少なくとも 1 つの Active Directory サイトをインターネットに直接接続する必要があります。インターネットに直接接続されていないすべての Active Directory サイトは、インターネットに直接接続されたクライアント アクセス サーバー (複数可) を使用して、外部クライアントからのすべての関連要求をプロキシ処理します。
クライアント アクセス プロキシ
前の図で、ユーザー 1 のメールボックスはメールボックス サーバー 1 上にあります。 ユーザー 2 のメールボックスはメールボックス サーバー 2 上にあります。 ユーザー 3 はメールボックス サーバー 3 の上にあります。 各メールボックス サーバーは別のアクティブ ディレクトリ サイト内にあります。ユーザー 1 は、プロキシ処理を使用せずに自身のメールボックスにクライアント アクセス サーバー 1 を経由してアクセスでき、ユーザー 2 は、クライアント アクセス サーバー 2 を経由して自身のメールボックスにアクセスできます。ユーザー 3 がクライアント アクセス サーバー 1 または 2 を経由して自身のメールボックスにアクセスを試みる場合、いずれかのサーバーがクライアント アクセス サーバー 3 にそれらの要求をプロキシ処理します。クライアント アクセス サーバー 3 は、インターネットに直接接続されていませんが、ファイアウォール内部のその他のサーバーから要求を受信できます。プロキシはユーザーには認識されません。
注意
異なるサイト内のクライアント アクセス サーバー間の通信は、Secure HTTP (HTTPS) で行われますが、クライアント アクセス サーバーは、既定で使用される証明書の状態をチェックしません。証明書は、認証ではなく暗号化にのみ使用されるので、名前の不一致、有効期間、および信頼情報は無視されます。
プロキシの概要
リダイレクトの概要
Outlook Web App ユーザーが自身のメールボックスが含まれているサイトとは異なる Active Directory サイト内にあるインターネットに直接接続されたクライアント アクセス サーバーにアクセスすると、自身のメールボックス サーバーと同じサイト内にあるクライアント アクセス サーバーがインターネットに直接接続されている場合はそのクライアント アクセス サーバーにリダイレクトされます。Outlook Web App ユーザーが自身のメールボックス サーバーが含まれている Active Directory サイトの外側にあるクライアント アクセス サーバーに接続しようとすると、自身のメールボックスに対する正しいクライアント アクセス サーバーへのリンクが記載された Web ページが表示されます。これを手動リダイレクトと呼びます。Exchange 2010 SP2 では、サイト間のサイレント リダイレクトを構成できます。これにより、ユーザーに知られることなくこのリダイレクト処理を実行できます。詳細については、このトピックの「クロスサイト サイレント リダイレクト」を参照してください。
注意
Office 365 と社内 Exchange Server を使用するハイブリッド環境では、クロスサイト サイレント リダイレクトを使用することはできません。
Exchange ActiveSync ユーザーが自身のメールボックスを含むサイトとは異なる Active Directory サイト内でインターネットに直接接続されたクライアント アクセス サーバーにアクセスすると、自身のメールボックス サーバーと同じサイト内のクライアント アクセス サーバーがインターネットに直接接続されている場合と、クライアントの携帯電話またはモバイル デバイスが Exchange 2007 および Exchange 2010 との通信時に使用するプロトコルに組み込まれたリダイレクト ロジックを正しく実装している場合は、そのクライアント アクセス サーバーにリダイレクトされます。Exchange ActiveSync ユーザーのリダイレクトは、デバイスが使用する必要がある URL を含む HTTP 451 エラー コードをデバイスに送信することによって実行されます。続いて、デバイスが新しい URL を使用するようにデバイス自体を再構成します。
次の図は、複数の Active Directory サイト内に複数のクライアント アクセス サーバーがある組織内でのリダイレクトの仕組みを示します。
Exchange 2010 での Exchange ActiveSync と Outlook Web App のリダイレクト
前の図で、ユーザー 1 は Active Directory サイト 1 内の自身のメールボックスに自身の携帯電話でアクセスします。管理者は、Active Directory サイト 2 内のメールボックス サーバー 2 に自身のメールボックスを移動します。 デバイスが次回同期を試みると、サーバーが HTTP 451 状態エラーを応答します。これには、デバイスがそのユーザーに使用する必要がある URL が含まれます。手順 3 で、デバイスはデバイス自体を再構成して指定の URL に接続します。ユーザー 2 は、メールボックスが Active Directory サイト 2 にあり、インターネット上でクライアント アクセス サーバー 1 に接続することによって、Outlook Web App で自身のメールボックスを開こうとします。手動によるリダイレクトでは、ユーザーが認証されるとすぐに、クライアント アクセスサーバー 1 は Active Directory サイト 2 のクライアント アクセスサーバーの Outlook Web App URL へのリンクとページを表示します。リンクをクリックすると Active Directory サイト 2 に移動し、もう一度サイン インしてメールボックスにアクセスします。サイレント リダイレクトでは、ユーザーが認証されると、通知なしで Active Directory サイト 2 のクライアント アクセス サーバーの Outlook Web App URL にリダイレクトされます。
クロスサイト サイレント リダイレクト
注意
Office 365 と社内 Exchange Server を使用するハイブリッド環境では、クロスサイト サイレント リダイレクトを使用することはできません。
Exchange 2010 SP2 を使用すると、管理者はクロスサイト サイレント リダイレクトを構成できます。クロスサイト サイレント リダイレクトは、同じ Exchange 組織内の別の Active Directory サイトに配置された CAS を宛先とするクライアント要求に対して、サイレント リダイレクトを実行します。たとえば、Active Directory SiteA にメールボックスがあるユーザーが Active Directory SiteB にある Outlook Web App URL にアクセスすると、ユーザーは、SiteA の Active Directory の Outlook Web App URL に通知なしでリダイレクトされます。
クロスサイト サイレント リダイレクトを構成するには、Set-OWAVirtualDirectory コマンドレットに追加された新しい CrossSiteRedirectType パラメーターを使用する必要があります。このパラメーターには、2 つの設定を指定できます。既定の設定は Manual です。
Silent この設定を構成すると、クライアント アクセス サーバーが別の Active Directory サイトに配置されたクライアント アクセス サーバーまたはサーバー アレイに Outlook Web App 要求をリダイレクトする必要がある場合、ユーザーの Web ブラウザーは常に自動的にリダイレクトされます。フォームベースの認証がソースとターゲット CAS OWA 仮想ディレクトリで構成されている場合 (SSL が必要)、サイレント リダイレクトは自動的にシングル サインオン イベントにもなります。リダイレクトが行われるには、ターゲット クライアント アクセス サーバーの Outlook Web App 仮想ディレクトリに
ExternalURL値が構成されている必要があります。Manual この設定を構成すると、ユーザーがアクセスしようとしている URL は正しくなく、正しいメールボックスの Outlook Web App URL にアクセスするにはリンクをクリックする必要があるという通知がユーザーに表示されます。この通知は、クライアント アクセス サーバーが、別の Active Directory サイトのクライアント アクセス サーバーまたはサーバー アレイに Outlook Web App の要求をリダイレクトする必要があると判断した場合にのみ表示されます。リダイレクトが行われるには、ターゲット クライアント アクセス サーバーの Outlook Web App 仮想ディレクトリに
ExternalURL値が構成されている必要があります。
たとえば、
Set-OWAVirtualDirectory -Identity "Contoso\owa (Default Web site)" -CrossSiteRedirectType Silent
Set-OwaVirtualDirectory コマンドレットの詳細については、次を参照してください。Set-OwaVirtualDirectory
Exchange ActiveSync のプロキシおよびリダイレクト
次に示す一連の手順は、携帯電話によって CAS-01 という名前の Exchange 2010 クライアント アクセス サーバーに接続するユーザーの受信要求がどのように処理されるかを示しています。
クライアント アクセス サーバーは、Active Directory に対してクエリを実行して、ユーザーのメールボックスの場所と、メールボックス サーバー上にインストールされている Microsoft Exchange のバージョンを確認します。
ユーザーのメールボックスが Exchange 2003 サーバーにある場合、受信要求は、ユーザーのメールボックスと Exchange ActiveSync 仮想ディレクトリをホストする Exchange 2003 サーバーに直接プロキシ処理されます。Exchange 2003 では、既定で Exchange ActiveSync 仮想ディレクトリがすべてのメールボックス サーバーにインストールされました。Active Directory が場所の特定に Exchange 2003 サイトを使用しないため、ユーザーのメールボックスの Active Directory サイトはこの場合は当てはまりません。接続は必ず Exchange 2010 クライアント アクセス サーバーから Exchange 2003 メールボックス サーバーに直接確立されます。
注意
メールボックスが Exchange 2003 サーバーにあるユーザーが Exchange 2010 クライアント アクセス サーバー経由で Exchange ActiveSync を使用しようとすると、Exchange 2003 サーバー上の Microsoft-Server-ActiveSync 仮想ディレクトリで統合 Windows 認証が有効になっていない限り、エラーが発生して同期を実行できません。統合 Windows 認証では、Exchange 2010 クライアント アクセス サーバーおよび Exchange 2003 バックエンド サーバーを通信できるようにします。
ユーザーのメールボックスが Exchange 2007 メールボックス サーバー上にある場合、CAS-01 は、ユーザーのメールボックス サーバーと同じ Exchange 2007 サイト内の Active Directory クライアント アクセス サーバーを検索します。これは、CAS-01 と同じ Active Directory サイトである場合もあります。CAS-01 は ExternalURL 設定に関係なく、Exchange ActiveSync 要求を Exchange 2007 クライアント アクセス サーバーの InternalURL にプロキシします。要求は IIS の Microsoft Server Exchange ActiveSync 仮想ディレクトリの下にある /Proxy 仮想ディレクトリに渡されます。既定では統合 Windows 認証が有効になっています。
ユーザーのメールボックスが CAS-01 と同じ Active Directory サイト内の Exchange 2010 メールボックス サーバーにある場合、CAS-01 ではメールボックスへのアクセスを提供します。ユーザーのメールボックスが別の Active Directory サイト内の Exchange 2010 メールボックス サーバー上にある場合、CAS-01 はユーザーのメールボックス サーバーと同じ Active Directory サイト内のクライアント アクセス サーバーを検索します。CAS-01 は、その Exchange 2010 サイト内の Active Directory クライアント アクセス サーバーが ExternalURL プロパティを Exchange ActiveSync 仮想ディレクトリ上で構成しているかどうかを確認します。その場合、CAS-01 は、ExternalURL 値を含む HTTP エラー コード 451 をクライアントに発行して、その場所にリダイレクトするようクライアントに指示します。ExternalURL 値が設定されていない場合、接続は InternalURL プロパティで指定された FQDN によってクライアント アクセス サーバー、特に /Proxy にプロキシ処理されます。この仮想ディレクトリは、IIS 内の Exchange ActiveSync 仮想ディレクトリの下にあり、既定でそのディレクトリに対して統合 Windows 認証が有効化されています。
重要
基本認証を使用する仮想ディレクトリ間では、プロキシ処理はできません。異なるサーバー上にある Exchange ActiveSync 仮想ディレクトリ間でクライアント通信をプロキシ処理するには、/Proxy 仮想ディレクトリが統合 Windows 認証を使用する必要があります。
プロキシの概要
Outlook Web App のプロキシおよびリダイレクト
次に示す一連の手順は、Outlook Web App によって CAS-01 という名前の Exchange 2010 クライアント アクセス サーバーに接続するユーザーの受信要求がどのように処理されるかを示しています。
クライアント アクセス サーバーは、Active Directory に対してクエリを実行して、ユーザーのメールボックスの場所と、メールボックス サーバー上にインストールされている Microsoft Exchange のバージョンを確認します。
ユーザーのメールボックスが Exchange 2003 サーバー上にあり、ユーザーが https://domain name/owa を使用して Outlook Web App にアクセスしようとする場合は、Exchange 2010 クライアント アクセス サーバーが Outlook Web App メールボックスへの Exchange 2003 アクセスを直接実行できないため、エラーが返ります。ただし、Exchange 2003 から Exchange 2010 への移行中によく行われる、Exchange 2010 から Exchange 2003 へのリダイレクトを管理者が構成した場合、Outlook Web App 仮想ディレクトリの Exchange2003URL プロパティがインターネットに直接接続されている Exchange 2003 サーバーの値に設定されました。
ユーザーのメールボックスが Exchange 2007 メールボックス サーバー上にある場合、CAS-01 は、ユーザーのメールボックス サーバーと同じ Active Directory サイト内のクライアント アクセス サーバーを検索します。Exchange 2007 メールボックス サーバーが CAS-01 と同じ Active Directory サイト内にある場合、次の 4 つの操作のうち 1 つが行われます。
CAS-01 は、Exchange 2010 クライアント アクセス サーバーの InternalAuthenticationMethods 設定と同一の ExternalAuthenticationMethods 設定が行われた Exchange 2007 ExternalURL プロパティを検索します。設定が一致する場合、CAS-01 はこの外部 URL にリダイレクトします。ソース CAS とターゲット CAS でフォーム ベース認証 (FBA) が有効である場合、ソース CAS は、ユーザーの資格情報、FBA 設定、およびリダイレクト URL を含む隠しフォームを発行して、ブラウザーに戻します。これは、ユーザーには表示されません。
一致する ExternalURL 設定が見つからない場合、CAS-01 は一致とは無関係に、ExternalURL プロパティが構成された Exchange 2007 クライアント アクセス サーバーを検索します。いずれかが見つかった場合、CAS-01 はこの外部 URL にリダイレクトします。これは、認証を求めるメッセージが表示されているユーザーで行われます。
一致する ExternalURL 設定が見つからない場合、CAS-01 は、Exchange 2010 クライアント アクセス サーバー上の InternalAuthenticationMethods 設定と同一の InternalAuthenticationMethods 設定が行われた InternalURL プロパティの Exchange 2007 クライアント アクセス サーバーを検索します。いずれかが見つかった場合は、CAS-01 はこの InternalURL にリダイレクトします。フォームベース認証が有効になっている場合、これはシングル サインオン リダイレクトになります。
InternalURL の一致が見つからない場合、CAS-01 は、一致と無関係に、InternalURL が構成された Exchange 2007 クライアント アクセス サーバーを検索します。いずれかが見つかった場合は、CAS-01 はこの InternalURL にリダイレクトします。これは、認証を求めるメッセージが表示されているユーザーで行われます。
Exchange 2007 メールボックス サーバーが別の Active Directory サイト内にある場合、CAS-01 は、その Active Directory サイト内で ExternalURL プロパティが設定されているかどうかを確認します。ExternalURL プロパティが設定されていて、クロスサイト サイレント リダイレクトが有効になっていない場合、CrossSiteRedirectType 値は Manual に設定され、手動リダイレクトが発行されます。このシナリオでは、ユーザーには指定された URL にリダイレクトされるクリック可能なリンクが表示されます。
クロスサイト サイレント リダイレクトが有効であれば、CrossSiteRedirectType 値は Silent に設定され、ユーザーは指定された URL に自動的にリダイレクトされます。ExternalURL プロパティが存在せず、/OWA 仮想ディレクトリの認証方法が統合 Windows 認証に設定されている場合、CAS-01 は、InternalURL プロパティによって指定されたクライアント アクセス サーバーに対してユーザーの要求をプロキシ処理します。
重要
Exchange 2010 クライアント アクセス サーバーが別の Outlook Web App サイト内の Exchange 2007 クライアント アクセス サーバーへの Active Directory 要求をプロキシ処理できるようにするには、送信先 Exchange 2007 サイト内の Active Directory クライアント アクセス サーバーの最新バージョンのフォルダーを %installpath%\ClientAccess\OWA\ フォルダーからプロキシ要求作成中の Exchange 2010 クライアント アクセス サーバー上の同じパスにコピーする必要があります。
重要
Exchange 2010 クライアント アクセス サーバーは、同じ Active Directory サイト内の Exchange 2007 クライアント アクセス サーバーに Outlook Web App 要求をプロキシ処理することはありません。同じ Active Directory サイト内部のすべての要求は、クライアント アクセス サーバーの InternalURL または ExternalURL プロパティのいずれか (構成されたプロパティにより異なる) を使用して、Exchange 2007 クライアント アクセス サーバーにリダイレクトされます。
ユーザーのメールボックスが CAS-01 と同じ Active Directory サイト内の Exchange 2010 メールボックス サーバーにある場合、CAS-01 ではメールボックスへのアクセスを提供します。ユーザーのメールボックスが別の Active Directory サイト内の Exchange 2010 メールボックス サーバー上にある場合、CAS-01 はユーザーのメールボックス サーバーと同じ Active Directory サイト内のクライアント アクセス サーバーを検索します。1 つ見つかる場合、Exchange 2010 は、クライアント アクセス サーバーでその Active Directory サイト内で ExternalURL プロパティが設定されているかどうかを確認します。このプロパティが設定されていて、クロスサイト サイレント リダイレクトが有効になっていない場合、指定された URL にリダイレクトされるクリック可能なリンクがユーザーに表示されます。クロスサイト サイレント リダイレクトが有効であれば、ユーザーは指定された URL に自動的にリダイレクトされます。ExternalURL が設定されず、仮想ディレクトリの認証方法が統合 Windows 認証に設定された場合、CAS-01 は、InternalURL プロパティによって指定されたクライアント アクセス サーバーに対してユーザーの要求をプロキシ処理します。
Exchange コントロール パネルのプロキシ
Exchange 2010 は、ユーザーおよび組織の管理者の両方に Web ベースのインターフェイスを提供し、それらのメールボックスの設定または組織の設定を構成します。Exchange コントロール パネル (ECP) は、Outlook Web App または Outlook 2010 のいずれかの [オプション] メニューでアクセスします。このためには、[ボイス メール] オプションを選択するか、メッセージ追跡情報を要求するか、モバイル通知を構成します。Outlook 内部でこれらのオプションのいずれかを選択すると、Web ブラウザー セッションが起動します。
セッションの接続先は、Outlook クライアントの現在の接続状態によって決まります。Outlook クライアントが RPC over TCP で接続している場合、クライアントは ECP 仮想ディレクトリの InternalURL 値に接続します。クライアントが Outlook Anywhere で接続している場合、Outlook クライアントがブラウザー セッションを起動します。ブラウザー セッションは、ECP 仮想ディレクトリの ExternalURL 値に接続を試みます。URL が自動検出サービスによって Outlook クライアントに示されます。
内部クライアントが TCP によって接続している場合、ECP セッションは必ず、ユーザーのメールボックスと同じ Active Directory サイト内のクライアント アクセス サーバーに接続します。プロキシは、このシナリオでは使用されません。企業ネットワーク外部のクライアントが接続に Outlook Anywhere を使用する場合、クライアントは、ユーザーのメールボックスがインターネットに直接接続していないサイト内に置かれていれば、ECP 仮想ディレクトリの外部 URL へのブラウザー セッションを開くか、インターネットに直接接続している Active Directory サイトの外部 URL へのブラウザー セッションを開きます。
ECP のプロキシ処理のロジックは、Outlook Web App と同じです。ユーザーのメールボックスが要求受信中のクライアント アクセス サーバーと同じ Active Directory サイト内の Exchange 2010 メールボックス サーバーにある場合、クライアント アクセス サーバーではメールボックスへのアクセスを提供します。ユーザーのメールボックスが別の Active Directory サイト内の Exchange 2010 メールボックス サーバー上にある場合、クライアント アクセス サーバーはユーザーのメールボックス サーバーと同じ Active Directory サイト内のクライアント アクセス サーバーを検索します。元のクライアント アクセス サーバーは、そのクライアント アクセス サーバーにユーザーの要求をプロキシします。
ECP はリダイレクトを実行しますが、ユーザーが ECP へのアクセス用に明示的に URL を入力しない限り、実行されることはほとんどありません。ユーザーが Outlook Web App から ECP にアクセスする場合、Outlook Web App はユーザーが正しい URL を使用していることを確認する責任があります。ユーザーが Outlook 2010 を使用している場合、Outlook および自動検出サービスは、ユーザーが ECP の正しい URL を使用することを確認する責任があります。
プロキシの概要
Exchange Web サービスのプロキシ
Exchange Web サービスには、Exchange ストア項目を管理して、クライアント アプリケーションから Exchange サーバー機能にアクセスすることを可能にするメッセージング インターフェイスがあります。プロキシ、リダイレクト、およびクライアントの観点から、この機能は通常、次のいずれかの状況で使用されます。
可用性サービス要求
自動検出要求
自動応答 (OOF) の状態を設定して確認する
Exchange Web サービスを使用して記述されたアプリケーションは、自動応答 (不在時) メッセージの設定などのタスクにプロキシ動作を使用できます。 これは、必要に応じて、Active Directory サイト間でプロキシ処理が行われます。
次の手順は、CAS-01 という名前の Exchange 2010 クライアント アクセス サーバーに対して可用性サービス要求を作成するユーザーの受信要求がどのように処理されるかを示します。 ユーザーは、同じ Outlook Web App 組織内の別ユーザーの可用性を確認するために、Exchange を使用しています。
CAS-01 は、Active Directory に対してクエリを実行して、ユーザーのメールボックスの場所と、メールボックス サーバー上にインストールされている Microsoft Exchange のバージョンを確認します。
ユーザーのメールボックスが Exchange 2003 サーバー上にある場合、Outlook Web App は、Exchange 2003 サーバーの /Public 仮想ディレクトリに HTTP 接続を作成して、要求された情報を Free/Busy システム フォルダーから取得します。
ユーザーのメールボックスが Exchange 2007 メールボックス サーバー上にある場合、エラーがユーザーに返されます。Exchange 2007 メールボックス サーバー上にメールボックスを格納している Exchange 組織では、外部からアクセスできる Exchange 2007 クライアント アクセス サーバーが存在する必要があります。自動検出サービスは、正しい Exchange Web サービス URL をクライアントに返します。この URL は、ユーザーのメールボックスがあるメールボックス サーバーのバージョンと一致する必要があります。
ユーザーのメールボックスが CAS-01 と同じ Active Directory サイト内の Exchange 2010 メールボックス サーバーにある場合、CAS-01 は、要求された情報を取得するために、メールボックス自体にアクセスします。ユーザーのメールボックスが別の Active Directory サイト内の Exchange 2010 メールボックス サーバー上にある場合、CAS-01 は、/EWS 仮想ディレクトリの InternalURL プロパティで指定された FQDN を使用して、その Active Directory サイト内のクライアント アクセス サーバーに対してプロキシします。
重要
Exchange クライアント アクセス サーバーは、ExternalURL プロパティの設定有無にかかわらず、サーバー間で可用性サービス要求をプロキシします。
重要
一部の Exchange Web サービス アプリケーションでは、GetEvents および Unsubscribe などの Web メソッドを使用します。 これには、非常に強力なクライアント アクセス サーバー アフィニティがあります。あるクライアント アクセス サーバーがこれらの要求のいずれかを別の Active Directory サイトにプロキシする必要がある場合、クライアント アクセス サーバーの InternalNLBBypassURL プロパティを使用できます。 このプロパティは、常にホスト サーバー自体の FQDN に設定されている必要があります。これにより、要求を作成しているクライアント アクセス サーバーがターゲット Active Directory サイト内の特定クライアント アクセス サーバーとのアフィニティを保持することができます。
Exchange Web サービス自体は、URL をアプリケーションに提示するために使用される自動検出サービスが特定メールボックスへのアクセスに必要な URL を提示するので、リダイレクト機能を提供しません。たとえば、メールボックスがActive Directory サイト間で移動する場合、Outlook は、次回のクエリ発行時に自動検出サービスから更新された Active Directory サイト固有 URL を受信します。これにより、クライアントは、メールボックスが内部にあるサーバーではなく Active Directory サイト内のクライアント アクセス サーバーに対して、可用性サービス要求を作成することもあります。けれども、可用性サービスが引き続いて要求を処理して、必要であればプロキシ処理するので、ユーザーに影響はありません。
重要
Exchange メールボックス サーバー上にメールボックスを格納している Exchange 2007 組織では、外部からアクセスできる Exchange 2007 クライアント アクセス サーバーが存在する必要があります。自動検出サービスが正しい Exchange Web サービス URL を要求元のクライアントに返した場合、この URL は、ユーザーのメールボックスがあるサーバーのバージョンと一致します。Exchange 2007 メールボックス サーバーと Exchange 2010 メールボックス サーバーの両方にメールボックスを格納している Exchange 組織では、インストールされている Exchange のバージョンごとに 1 つずつ、2 つの外部 URL を Exchange Web サービス用に構成する必要があります。
POP3 および IMAP4 のプロキシ
Exchange 2010 は、クライアント アクセス サーバーと Active Directory サイト間で POP3 および IMAP4 セッションをプロキシ処理できます。
次の手順は、POP3 クライアントによって CAS-01 という名前の Exchange 2010 クライアント アクセス サーバーに対して要求を作成するユーザーの受信要求がどのように処理されるかを示します。
CAS-01 は、Active Directory に対してクエリを実行して、ユーザーのメールボックスの場所と、メールボックス サーバー上にインストールされている Microsoft Exchange のバージョンを確認します。
ユーザーのメールボックスが Exchange 2003 サーバー上にある場合、CAS-01 は、ユーザーのメールボックスをホストしている Exchange 2003 サーバー上で実行している POP3 サービスへの接続をプロキシ処理します。
ユーザーのメールボックスが Exchange 2007 メールボックス サーバー上にある場合、CAS-01 は、ユーザーのメールボックス サーバーと同じ Exchange 2007 サイト内の Active Directory クライアント アクセス サーバーを検索します。 これは、CAS-01 サイトと同じ Active Directory サイト内にある場合があります。 CAS-01 は、クライアント アクセス サーバーに要求をプロキシします。
ユーザーのメールボックスが CAS-01 と同じ Active Directory サイト内の Exchange 2010 メールボックス サーバーにある場合、CAS-01 はメールボックス自体にアクセスします。ユーザーのメールボックスが別の Active Directory サイト内の Exchange 2010 メールボックス サーバー上にある場合、CAS-01 は、そのサーバーの POP 構成の InternalConnectionSettings プロパティで指定された FQDN を使用して、クライアント アクセス サーバーに対してプロキシします。
重要
POP3 または IMAP4 サービスには、InternalURL または ExternalURL 設定がなく、Exchange 2010 クライアント アクセス サーバーは POP3 および IMAP4 サービス要求を必要な場合にサーバー間でプロキシします。
重要
別の Active Directory サイトへのプロキシを試みているクライアント アクセス サーバーは、リモート クライアント アクセス サーバー上で実際に実行中であるのが POP3 サービスであるか IMAP4 サービスであるかを確認しません。そのため、リモート Active Directory サイト内のあらゆるクライアント アクセス サーバー上でサービスが実行中であることを確認するだけでなく、サービスの負荷分散装置の使用を検討することが重要です。負荷分散装置については、後で説明します。
プロキシの概要
プロキシの構成
クライアント アクセス サーバーがインターネットに直接接続されている場合は、Exchange 管理コンソール (EMC) または Exchange 管理シェル (シェル) を使用して、/Microsoft-Server-ActiveSync、/OWA、/ECP、および /EWS 仮想ディレクトリに ExternalURL プロパティを設定します。EWS 仮想ディレクトリは、シェルを使用してのみ構成できます。InternalURL プロパティは、Exchange 2010 の初期セットアップ時に自動的に構成され、負荷分散ソリューションを使用する場合のみ変更する必要があります。ExternalURL プロパティには、DNS で Exchange 組織用に登録されている FQDN を含める必要があります。
次の表は、URL https://mail.contoso.com を使用して Outlook Web App にアクセスする Exchange 組織の、インターネットに直接接続するクライアント アクセス サーバーの ExternalURL および InternalURL プロパティに適した値を示しています。2 番目の表は、同じ組織の 2 番目の Active Directory サイト内の、インターネットに直接接続しないクライアント アクセス サーバーの ExternalURL および InternalURL プロパティ値を示しています。これらすべての仮想ディレクトリの認証方法が統合 Windows 認証に設定されていることを確認する必要があります。プロキシ処理は、SSL/TLS を使用してユーザーの基本認証資格情報をプロキシする、POP3 および IMAP4 を除くその他の認証方法を使用する仮想ディレクトリではサポートされません。
注意
新しい Outlook Web App 仮想ディレクトリがシェルを使用して作成される場合は、これらの仮想ディレクトリで InternalURL プロパティを手動で構成する必要があります。
インターネットに直接接続されたクライアント アクセス サーバーの InternalURL および ExternalURL 設定
| Exchange 2010 サービス | InternalURL 設定 | ExternalURL 設定 |
|---|---|---|
Outlook Web App |
https://完全修飾コンピューター名/OWA |
https://mail.contoso.com/OWA |
Exchange ActiveSync |
https://fullyqualifiedcomputername/Microsoft-Server-ActiveSync |
https://mail.contoso.com/Microsoft-Server-ActiveSync |
Exchange Web サービス |
https://完全修飾コンピューター名/EWS/Exchange.asmx |
https://mail.contoso.com/EWS/Exchange.asmx |
Exchange コントロール パネル |
https://完全修飾コンピューター名/ECP |
https://mail.contoso.com/ECP |
インターネットに直接接続していないクライアント アクセス サーバーの InternalURL および ExternalURL 設定
| Exchange 2010 サービス | InternalURL 設定 | ExternalURL 設定 |
|---|---|---|
Outlook Web App |
https://完全修飾コンピューター名/OWA |
|
Exchange ActiveSync |
https://完全修飾コンピューター名/Microsoft-Server-ActiveSync |
|
Exchange Web サービス |
https://完全修飾コンピューター名/EWS/Exchange.asmx |
|
Exchange コントロール パネル |
https://完全修飾コンピューター名/ECP |
|
リダイレクトの構成
複数の Active Directory サイトがインターネットに直接接続されている場合は、EMC またはシェルを使用して、/OWA および /Microsoft-Server-ActiveSync 仮想ディレクトリに ExternalURL プロパティを設定します。InternalURL プロパティは、Exchange 2010 の初期セットアップ時に自動的に構成され、負荷分散ソリューションを使用する場合のみ変更する必要があります。以下の 2 つの表は、Contoso という名前の会社の 2 つの Active Directory サイトにあるクライアント アクセス サーバーの ExternalURL および InternalURL 設定を示します。2 つのサイトは、usa.contoso.com と europe.contoso.com です。
注意
新しい Outlook Web App 仮想ディレクトリがシェルを使用して作成される場合は、これらの仮想ディレクトリで InternalURL プロパティを手動で構成する必要があります。
usa.contoso.com サイト内のインターネットに直接接続されたクライアント アクセス サーバーの InternalURL および ExternalURL プロパティ設定
| Exchange 2010 サービス | InternalURL 設定 | ExternalURL 設定 |
|---|---|---|
Outlook Web App |
https://完全修飾コンピューター名/OWA |
https://usa.contoso.com/OWA |
Exchange コントロール パネル |
https://完全修飾コンピューター名/ECP |
https://usa.contoso.com/ECP |
Exchange ActiveSync |
https://完全修飾コンピューター名/Microsoft-Server-ActiveSync |
https://usa.contoso.com/ Microsoft-Server-ActiveSync |
Exchange Web サービス |
https://完全修飾コンピューター名/EWS/Exchange.asmx |
https://usa.contoso.com/EWS/Exchange.asmx |
europe.contoso.com サイト内のインターネットに直接接続されたクライアント アクセス サーバーの InternalURL および ExternalURL プロパティ設定
| Exchange 2010 サービス | InternalURL 設定 | ExternalURL 設定 |
|---|---|---|
Outlook Web App |
https://完全修飾コンピューター名/OWA |
https://europe.contoso.com/OWA |
Exchange コントロール パネル |
https://完全修飾コンピューター名/ECP |
https://europe.contoso.com/ECP |
Exchange ActiveSync |
https://完全修飾コンピューター名/Microsoft-Server-ActiveSync |
https://europe.contoso.com/ Microsoft-Server-ActiveSync |
Exchange Web サービス |
https://完全修飾コンピューター名/EWS/Exchange.asmx |
https://europe.contoso.com/EWS/Exchange.asmx |
注意
1 つ以上の Active Directory サイト内の Exchange ActiveSync 仮想ディレクトリに ExternalURL プロパティが設定されていない場合、自動検出サービスは携帯電話の構成に失敗します。理由は、自動検出プロセス中に ExternalURL プロパティの値セットが携帯電話に渡されるためです。
プロキシの概要
ネットワーク負荷分散によるプロキシ
複数の Active Directory サイトがあり、各サイト内に複数のクライアント アクセス サーバーがある組織では、ネットワーク負荷分散 (NLB) を使用して、各サイト内のクライアント アクセス サーバー間でプロキシ処理されるトラフィックを負荷分散し、ユーザーがそれらのサーバーに直接アクセスできるようにすることが可能です。負荷分散装置を展開するだけでは、トラフィックを効率的に負荷分散できません。InternalURL および ExternalURL プロパティの追加の構成もいくつか行う必要があります。同じ Active Directory サイト内にあるクライアント アクセス サーバーのみを負荷分散アレイに含めることをお勧めします。インターネットに直接接続された Active Directory サイトおよびインターネットに直接接続されていない Active Directory サイトで NLB を展開できます。
次の表は、インターネットの直接接続するサイトと直接接続しないサイトの両方でクライアント アクセス サーバー上に仮想ディレクトリを構成する必要がある設定を示します。NLB の FQDN は、負荷分散装置またはサービスを解決するように DNS 内で構成する必要があります。続いて、負荷分散ソリューションは、クライアント アクセス サーバーへのトラフィックを転送する責任があります。
NLB を使用する組織にあるクライアント アクセス サーバーの仮想ディレクトリ設定
| 仮想ディレクトリ /service | InternalURL | ExternalURL (インターネットに直接接続された Active Directory サイト) | ExternalURL (インターネットに直接接続されていない Active Directory サイト) |
|---|---|---|---|
/OWA |
NLB FQDN (次のガイドラインを参照してください) |
NLB FQDN |
$null |
/ECP |
NLB FQDN (次のガイドラインを参照してください) |
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 |
該当なし |
該当なし |
次のガイドラインを参考にして InternetlURL プロパティを設定することをお勧めします。
内部 Outlook 2010 ユーザーが存在する場合、Active Directory サイト内のすべてのクライアント アクセス サーバーの /OWA および /ECP 仮想ディレクトリの InternalURL プロパティを、そのサイトのサーバーの NLB FQDN に設定できます。
Active Directory サイト内のクライアント アクセス サーバーが、その他の任意の Active Directory サイト内のクライアント アクセス サーバーからの Outlook Web App または ECP プロキシ要求の宛先であれば、アフィニティが維持されるように負荷分散装置を構成してください。これは、インターネットに直接接続するサイト内のクライアント アクセス サーバーが、各個別の要求についてサーバーを選択したり、そのサーバーのアフィニティを維持したりできないためです。
次の表は、ネットワーク負荷分散 (NLB) を使用する組織内で仮想ディレクトリに必要になる各種認証設定を示します。NLB を使用する組織では、クライアント接続のために、特定のクライアント アクセス サーバー URL の代わりに NLB URL が使用されます。
フォールト トレランスおよび負荷分散のために NLB URL を使用する組織内のクライアント アクセス サーバーの仮想ディレクトリ認証設定
| 仮想ディレクトリ /service | インターネットに直接接続された Active Directory サイト | インターネットに直接接続されていない Active Directory サイト |
|---|---|---|
/OWA |
Microsoft Forefront Threat Management Gateway 2010 (Forefront TMG) または Microsoft Forefront Unified Access Gateway 2010 (Forefront UAG) を使用している場合、フォームベースの認証が有効化され、ファイアウォール規則委任設定に応じて、基本または統合 Windows 認証を使用します。 インターネットからのトラフィックが事前認証なしでクライアント アクセス サーバーに渡される場合、フォームベース認証を使用します。 同じ認証方法は、/OWA および /ECP 仮想ディレクトリ上で有効化する必要があります。 |
統合 Windows 認証 |
/ECP |
Forefront TMG または Forefront UAFG を使用している場合、フォームベースの認証が有効化され、ファイアウォール規則委任設定に応じて、基本または統合 Windows 認証を使用します。 インターネットからのトラフィックが事前認証なしでクライアント アクセス サーバーに渡される場合、フォームベース認証を使用します。 同じ認証方法は、/OWA および /ECP 仮想ディレクトリ上で有効化する必要があります。 |
統合 Windows 認証 |
/Microsoft-Server-ActiveSync |
基本認証。 |
基本認証 (プロキシは /Proxy 仮想サブディレクトリを使用して実行される) |
/OAB |
ファイアウォール規則委任設定によって異なる基本または統合 Windows認証。 |
ファイアウォール規則委任設定によって異なる基本または統合 Windows 認証。(OAB 要求は Active Directory サイト間ではプロキシされません。この仮想ディレクトリは、Outlook クライアントのみが使用します。) |
/EWS |
基本 (ファイアウォール規則委任設定によっては省略可能)。 統合 Windows 認証が必要。 |
統合 Windows 認証 |
POP/IMAP |
クライアント接続方法によって要求された通り。 |
クライアントの接続方法によって要求された通り |
プロキシの概要
Active Directory サイト間でのプロキシ時にクライアント アクセス サーバーによって使用される負荷分散ロジック
プロキシ試行のターゲットになるサイト内に複数のクライアント アクセス サーバーが存在し、ユーザーのメールボックスが置かれたサーバーが結合されたクライアント アクセス サーバーおよびメールボックス サーバーである場合、ソース Active Directory サイト内のクライアント アクセス サーバーは、プロキシ試行のターゲットとして、結合されたクライアント アクセス サーバーおよびメールボックス サーバーを常に選択します。
Outlook Web App、ECP、および Exchange Web サービスは、可用性サービスおよび Exchange ActiveSync が実行するものと異なる負荷分散を処理します。 Outlook Web App、ECP、および Exchange Web サービスは、同じ Active Directory サイト内で複数のクライアント アクセス サーバーに展開される場合、それぞれの負荷分散を実装します。ユーザーが https://mail.contoso.com/owa で Outlook Web App にアクセスしようとして、CAS-01 にプロキシされる場合、ユーザーは次回 Outlook Web App にアクセスしようとすると再び CAS-01 にプロキシされます。CAS-02 の同時接続数の方が少ない場合でもこのようになります。これは、長時間実行されているトランザクションを再認証またはデータの再要求なしで完了できることを確認するために行われます。これはアフィニティと呼ばれます。CAS-01 が使用できない場合、ユーザーは CAS-02 にプロキシされ、ユーザーは再認証が必要になる場合があります。
Exchange Web サービスは、NLB URL で構成しているターゲット サーバーの InternalURL プロパティにかかわらず、Active Directory サイト間のプロキシ時にアフィニティを保持できます。この理由は、アフィニティを必要とするアプリケーションのプロキシ要求を作成しているクライアント アクセス サーバーがターゲット サーバー上の InternalNLBBypassURL プロパティを使用しているからです。InternalNLBBypassURL プロパティは、ターゲット サーバーの FQDN で構成され、既定で Windows 認証を使用します。
注意
Outlook Web App、ECP、および Exchange Web サービスの場合、ファイアウォールで Cookie ベースまたは IP ベースのアフィニティを構成する必要があります。これにより、特定のクライアント アプリケーションが毎回同じサーバーに接続されるようになります。これは、要求ごとに SSL ネゴシエーションが繰り返し実行されないようにするために必要です。トランザクションに関係するクライアント アプリケーションから最終クライアント アクセス サーバーへのアフィニティを保持することは重要です。
注意
クライアント アクセス サーバーの InternalNLBBypassURL プロパティの値を変更しないでください。変更すると、プロキシされた Exchange Web サービス要求を壊すことになります。
Exchange ActiveSync の場合、プロセスは異なります。インターネットに直接接続するサーバーがインターネットに直接接続しないサーバーに要求をプロキシする場合、要求しているクライアント アクセス サーバーはターゲット サイト内のクライアント アクセス サーバーを検索し、そのサーバーにInternalURL プロパティで構成された値を使用して接続しようとします。サーバーが応答しない場合、要求は失敗して、クライアントにエラーが返ります。NLB アレイ内にラウンドロビン負荷分散を実装して、InternalURL プロパティを負荷分散された値に設定することをお勧めします。
また、可用性サービスの負荷分散もお勧めします。可用性サービス要求は、それらの接続状態を保持する必要がありません。言い換えれば、同一クライアントからの連続した 2 つの可用性サービス要求は、パフォーマンスに影響することなく、送信先 Active Directory サイト内の別のクライアント アクセス サーバーにプロキシでき、InternalURL プロパティが負荷分散された値に設定された場合、認証の問題はありません。さらに、InternalURL プロパティを負荷分散された値に設定することにより、Outlook 2007 および Outlook 2010 クライアントには内部的に利益を受けます。 理由は、自動検出サービスがそれらのクライアントに InternalURL プロパティ内の負荷分散された値セットを提供して、それらの可用性サービス要求を完了できるようにするからです。
ネットワーク負荷分散の詳細については、「Exchange 2010 の負荷分散について」を参照してください。
注意
多くの展開では、クライアント アクセス サーバーの役割とハブ トランスポート サーバーの役割が同じコンピューターにインストールされます。このトポロジでは、クライアント アクセス サーバーの役割の NLB をハブ トランスポート サーバーの役割とは別に構成できます。現在、NLB はハブ トランスポート サーバーの役割ではサポートされていません。ただし、クライアント アクセス サーバーの役割ではサポートされます。クライアント アクセス サーバーの役割の NLB を構成し、ハブ トランスポート サーバーの役割に対しては構成しないようにするには、クライアント アクセス用にポート 80 とポート 443 を構成します。ハブ トランスポート サーバーの役割では、ソフトウェア内に独自の高可用性が実装されています。
プロキシの概要
クライアント アクセス方法の概要
次の表は、Exchange 2010 にアクセスするために使用されるプロトコルと、これらのプロトコルがプロキシとリダイレクトでどのように使用されるのかを示しています。
リダイレクトとプロキシのクライアント アクセス プロトコル
| プロトコルとアプリケーション | クライアント アクセス サーバー間でサポートされるリダイレクト | クライアント アクセス サーバー間でサポートされるプロキシ | コメント |
|---|---|---|---|
Outlook Web App |
はい |
はい |
Active Directory を使用するには、各 Outlook Web App サイトにクライアント アクセス サーバーが必要です。 |
Exchange コントロール パネル |
はい |
はい |
ECP を使用するには、各 Active Directory サイトにクライアント アクセス サーバーが必要です。 |
Exchange ActiveSync |
はい |
はい |
Exchange ActiveSync を使用するには、各 Active Directory サイトにクライアント アクセス サーバーが必要です。 |
Exchange Web サービス |
不可(適切な ExternalURL 値を持つアプリケーションを自動検出サービスが提供) |
はい |
Active Directory Web サービスを使用するには、各 Exchange サイトにクライアント アクセス サーバーが必要です。 |
空き時間情報サービス |
不可(適切な ExternalURL 値を持つアプリケーションを自動検出サービスが提供) |
はい |
可用性サービスを使用するには、各 Active Directory サイトにクライアント アクセス サーバーが必要です。 |
POP3 と IMAP4 |
不可 |
はい |
POP3 および IMAP4 を使用するには、各 Active Directory サイトにクライアント アクセス サーバーが必要です。 |
プロキシのパフォーマンスとスケーラビリティ
Exchange 2010 プロキシ環境では、クライアント アクセス サーバーが多数の同時要求を受信すると、多くの場合パフォーマンスが低下します。この問題は、多くの場合、ASP.NET からの Web サービス要求のためにスレッドや使用可能な接続がすべて使用されることが原因で発生します。 これにより、要求の処理時に、クライアント アクセス サーバーによって要求が拒否されたり、待ち時間が長くなったりする可能性があります。
これらの問題を解決するために、クライアント アクセス サーバー上で Machine.config ファイルを編集して、複数の ASP.NET パラメーターを構成することができます。これらのパラメーターを構成する方法の詳細については、Microsoft サポート技術情報の記事 821268「ASP.NET アプリケーションから Web サービス要求を行うと、競合、パフォーマンスの低下、およびデッドロックが発生する」を参照してください。
サポート技術情報の記事 821268 で説明されている 2 つのパラメーターは、Exchange 2010 プロキシ環境では異なる方法で設定する必要があります。プロセッサごとに 36 個のスレッドを許可し、maxconnections 値を 2,000 に設定することをお勧めします。
サーバー パフォーマンスの詳細については、「Windows Server 2003 での .NET Framework の管理」を参照してください (このサイトは英語の場合があります)。
© 2010 Microsoft Corporation.All rights reserved.