1. Exchange 2010のFree Busy：はじめに
Cloudiway FreeBusyツールを使用すると、G Suite、Office 365、およびExchangeオンプレミス環境間でFreeBusyをクエリできます。
他のシステムとは異なり、Exchange 2010オンプレミスでは、FreeBusyを構成するために追加のタスクが必要です。このドキュメントでは、CloudiwayFreeBusyがExchange2010オンプレミスとどのように連携するかについて説明します。
Exchangeには、空き時間情報要求を外部システムに転送するためのネイティブ機能があります。構成はPowerShellを使用して行われます。
管理者は、Add-AvailabilityAddressSpaceコマンドを実行して、特定のSMTPドメインに対するFreeBusy要求をリモートサーバーに転送するようにExchangeを構成する必要があります。
Exchangeの最近の実装（2013以降）には、リクエストの転送先を指示する「TargetAutodiscoverEpr」というパラメーターがあります。このパラメーターは、Exchange2013以降に導入されました。
Exchange 2010 Add-AvailabilityAddressSpaceにはこのパラメーターがなく、Exchange2010はDNS要求に依存しています。
remotedomain.comという名前のリモートドメインのユーザーに対してFreeBusyを要求している場合、ExchangeはAutodiscover.remotedomain.comに対してDNS要求を行い、サーバーに接続します。
次の章では、そのシステムをバイパスし、Cloudiwayプラットフォームにリクエストを転送するようにExchangeを構成する方法について説明します。
2. Exchange2010のセットアップ
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の有効な証明書とそれに関連付けられた秘密鍵を所有している必要があります。
サーバーごとにインストールできるSSL証明書は1つだけであるという技術的な制限もあります。
実際、Exchange（クライアントとして機能）がCloudiwayへのSSL接続を開く場合、CloudiwayはExchangeが接続しようとしているサーバー名を認識せず、異なる証明書から選択することはできません。
したがって、ファーム内のサーバーごとに1つの証明書のみをインストールでき、ExchangeがAutodiscover.remotedomain.comが指すサーバーに接続すると、Cloudiwayはこのサーバー名の証明書を返します。
これが、Exchange 2010サーバーを接続するために、Cloudiway側に専用サーバー（関連する証明書を「ホスト」するサーバー）が必要な理由です。
Freebusyにクエリを実行できるようにするドメインが複数ある場合は、ドメインと同じ数の証明書と専用サーバーが必要になります。
これはすぐにコストがかかる可能性があり、このシナリオの場合は、この制限とコストを回避するためにExchange2013以降へのアップグレードを想定することをお勧めします。
3. Freebusyプロキシサーバーの構成
この記事では、空き時間情報を照会するときにプロキシサーバーを使用するようにExchangeオンプレミスを構成する方法について説明します。
3.1. バックグラウンド
Microsoft Exchange可用性サービスは、OutlookまたはOWAを実行しているクライアントに空き時間情報を提供します。フリー/ビジーリクエストはユーザーのCASサーバーに送信され、ユーザーのCASサーバーはリクエストを可用性サービスに転送します。
このサービスはIIS（Internet Information Server）でホストされています。
3.2. 問題
デフォルトでは、Availability Serviceはシステムのプロキシ設定（IE設定）を使用しません。
したがって、外部システムに送信された空き時間情報要求はプロキシに転送されず、インターネットターゲット（つまりCloudiwayサーバー）に到達しません。
3.3. 解像度
EWS URLがプロキシを介してインターネット上でのみ利用可能な場合、Exchange2013とExchange2010の両方で特定のsystem.netプロキシ構成が必要です。
これを構成する唯一の方法は、アプリケーションで使用されるweb.configファイルを編集することです。
最も簡単な方法はExchangeweb.configファイルに変更を加えることですが、変更はパッチ、累積的な更新、またはサービスパックによって上書きされる可能性があります。 これを回避する1つの方法は、ExchangeバックエンドEWS Web構成ではなく、ルートweb.configでsystem.netプロキシ設定を構成することです。
System.Net XMLノードはデフォルトではファイルに含まれておらず、次のページに示すように<system.web>と同じレベルで追加する必要があります。
Exchangeファイルの構文例。
位置：C:\ Program Files4\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>
位置：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>
テクニカルリファレンス：https：//blogs.technet.microsoft.com/appssrv/2009/08/11/proxying-cas-http-cross-forest-availability-requests/
3.4. バイパスリストノードに関する注意
この変更を行うと、Availability Serviceによって処理されたすべての呼び出しがプロキシに送信されます。
バイパスリストノードを使用して、（プロキシ経由ではなく）直接送信する必要のあるリクエストを定義できます。
ローカルサーバーは、正規表現構文を使用して表す必要があります。 下記を参照してください:
https://msdn.microsoft.com/en-us/library/aa903323(v=vs.71).aspx
MSDNの記事に基づいて、ドメインを正規表現形式(regex)で追加する必要もあります。 いくつかのサンプルを以下に示します。
構文 <bypasslist> 要素
つまり、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]+
更新日：2022/09/23