Exchange 2010 のための Coexistence Free/Busy
1. Exchange 2010でのFree-busy導入
CloudiwayのFreeBusyツールは、G Suite、Office 365、およびExchangeオンプレミス環境間でのFreeBusyの照会を可能にします。
他のシステムとは異なり、Exchange 2010オンプレミスはFreeBusyを設定するための追加タスクが必要です。このドキュメントは、Cloudiway FreeBusyがExchange 2010 On Premisesとどのように連携するかを説明しています。
Exchangeには、Free Busyリクエストを外部システムに転送するネイティブ機能があります。設定はPowerShellを使用して行います。
管理者は、Add-AvailabilityAddressSpaceコマンドを実行して、指定されたSMTPドメインのFreeBusyリクエストをリモートサーバーに転送するようにExchangeを設定する必要があります。
Exchange 2013以降の最近の実装には、どこにリクエストを転送するかを指示する「TargetAutodiscoverEpr」というパラメーターがあります。このパラメータは、Exchange 2013以降に導入されました。
Exchange 2010 Add-AvailabilityAddressSpaceにはこのパラメーターがなく、Exchange 2010はDNSリクエストに依存しています。
remotedomain.comという名前のリモートドメインのユーザーのFreeBusyを要求する場合、ExchangeはDNSリクエストを行い、サーバーに接続します。
次の章では、そのシステムをバイパスして、リクエストをCloudiwayプラットフォームに転送するようにExchangeを設定する方法について説明します。
2. Exchange 2010 のセットアップ
remotedomain.comという名前のリモートドメインのユーザーのFreebusyを要求する場合、Exchangeはautodiscover.remotedomain.comのDNSリクエストを行います。
Cloudiwayプラットフォームにリクエストを転送するには、DNSクエリAutodiscover.remotedomain.comはCloudiwayのIPアドレスに解決する必要があります。
したがって、Exchange 2010サーバーのすべてで、ホストファイルを編集してAutodiscover.remotedomain.comをCloudiwayによって提供されたIPにポイントする必要があります。
リクエストはCloudiwayに転送されます。
ただし、トラフィックはSSL/TLS接続にカプセル化されます。
ExchangeはAutodiscover.remotedomain.comというサーバーの名前でHTTPSリクエストを送信します。
Cloudiwayが適切に応答するためには、CloudiwayはAutodiscover.remotedomain.comの有効な証明書とそれに関連する秘密キーを所有する必要があります。
1つのサーバーにインストールできるSSL証明書は1つだけであるという技術的な制限もあります。
実際、Exchange（クライアントとして動作する）がCloudiwayにSSL接続を開くと、CloudiwayはExchangeがどのサーバー名に接続しようとしているかを知らず、異なる証明書の中から選択することはできません。
したがって、ファーム内のサーバーごとに1つの証明書しかインストールできず、Autodiscover.remotedomain.comというサーバー名を指すサーバーにExchangeが接続すると、Cloudiwayはこのサーバー名の証明書を返します。
このため、Exchange 2010サーバーを接続する場合、Cloudiwayの側に専用のサーバーが必要となります（関連する証明書を「ホスト」するサーバー）。 Freebusyの複数のドメインを照会できるようにする場合、ドメインの数だけ証明書と専用のサーバーが必要となります。
これはすぐにコストがかかる可能性があり、このシナリオにある場合は、この制限とコストを回避するためにExchange 2013以降にアップグレードすることを検討するかもしれません。
3. Freebusyプロキシサーバーの設定
この記事では、Free/busyを照会する際にExchange On-Premisesがプロキシサーバーを使用するように設定する方法について説明します。
3.1. 背景
Microsoft Exchangeの可用性サービスは、OutlookまたはOWAを実行しているクライアントにfree/busy情報を提供します。Free/busyリクエストは、ユーザーのCASサーバーに送信され、そのリクエストはAvailability Serviceに転送されます。
このサービスはIIS（Internet Information Server）でホストされています。
3.2. 問題
デフォルトでは、Availability Serviceはシステムのプロキシ設定（IE設定）を使用しません。
したがって、外部システムに送信されるfree/busyリクエストはプロキシに転送されず、インターネットのターゲット（つまり、Cloudiwayサーバー）に到達しません。
3.3. 解決策
Exchange 2013およびExchange 2010の両方は、EWS URLがプロキシを経由してインターネットでのみ利用可能な場合、特定のsystem.netプロキシ設定が必要です。 これを設定する唯一の方法は、アプリケーションで使用されるweb.configファイルを編集することです。 最も簡単なアプローチは、Exchangeのweb.configファイルで変更を行うことですが、パッチ、累積更新、またはサービスパックによって変更が上書きされる可能性があります。これを回避する方法の1つは、Exchange Backend EWS web configの代わりに、ルートweb.configのsystem.netプロキシ設定を設定することです。
System.Net XMLノードはデフォルトでファイルに含まれていないため、<system.web>と同じレベルに追加する必要があります。
Exchangeファイルの構文の例。
場所：C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\exchweb\ews\web.config
</system.web> <system.net> <defaultProxy> <proxy usesystemdefault = "false" proxyaddress = "http://proxyserver:port/" bypassonlocal = "true" /> <bypasslist> <add address="http://[a-z]+/.contoso/.com$" /> </bypasslist> </defaultProxy> </system.net>
Root web.configの構文の例
場所：C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config
<location path="Exchange Back End/EWS"> <system.net> <defaultProxy> <proxy bypassonlocal="True" proxyaddress="http://proxyserver:port" usesystemdefault="false" /> <bypasslist> <add address="http://[a-z]+/.contoso/.com$" /> </bypasslist> </defaultProxy> </system.net> </location>
web.configファイルの変更を行った後は、IISRESETを実行する必要があります。
技術的参考：
3.4. Bypasslistノードに関する注記
この変更を行った後、Availability Serviceで処理されるすべての呼び出しがプロキシに送信されます。
bypasslistノードを使用して、どのリクエストを直接送信するか（プロキシを介さずに）を定
義できます。
ローカルサーバーは、正規表現の構文を使用して表される必要があります。参照： https://msdn.microsoft.com/en-us/library/aa903323(v=vs.71).aspx
MSDNの記事に基づいて、正規表現形式でドメインも追加する必要があります。以下にいくつかのサンプルを示します：
構文：<bypasslist> Element
company.comのすべてのサーバーについて：
[a-z,0-9]+.company.com
..company.comについては、以下を追加する可能性があります：
[a-z,0-9]+.[a-z,0-9]+.xxx.com
..company.com:444の場合、以下を追加する可能性があります：
[a-z,0-9]+.[a-z,0-9]+.xxx.com.[0-9]+
