先週予告した通り、今回は一般的なシナリオごとにどのような手順で Autodiscover が実行されるかを解説します。
今回想定したシナリオは以下の通りです。
- Exchange オンプレミス環境 – 単一フォレスト、社内のみ
- Exchange オンプレミス環境 – 単一フォレスト、社外アクセス
- Exchange オンプレミス環境 – 複数フォレスト、信頼関係あり
- Exchange オンプレミス環境 – 複数フォレスト、信頼関係なし
- Exchange オンプレミス環境 – ワークグループ
- Exchange Online 環境 – オンプレミスなし
- Exchange Online とオンプレミスのハイブリッド環境
- Exchange Online とオンプレミスの混在
- Exchange ホスティング環境
- POP/IMAP 環境
以下それぞれのシナリオについて説明します。
シナリオ 1: Exchange オンプレミス環境 – 単一フォレスト、社内のみ
このシナリオは Exchange がインストールされたフォレストと同じフォレストにクライアントがあり、社内からしかアクセスが行われないというものです。
この場合、通常は SCP で Autodiscover が実行されます。
SCP で Autodiscover が成功するためには DNS 設定が適切に設定されており、クライアントから LDAP で GC に接続できる必要がありますが、普通にインストールすれば問題は発生しないはずです。
ただし、複数のサイトがある環境で Exchange サーバーがサイトごとに存在する場合、クライアントが存在するサイトと異なるサイトの Exchange サーバーに対して Autodiscover が実行されてしまう可能性があります。
このようなことを防ぐには Set-ClientAccessServer の –AutoDiscoverSiteScope により、サーバーの AD サイトを正しく設定する必要があります。
また、既定では SCP の前に O365 へのアクセスが発生しますので、こちらを抑止したい場合は ExcludeExplicitO365Endpoint レジストリを設定します。
シナリオ 2: Exchange オンプレミス環境 – 単一フォレスト、社外アクセス
このシナリオは、シナリオ 1 に社外アクセスが加わったものです。
社外アクセスといっても VPN 接続で社内の GC などにアクセスできる場合は、シナリオ 1 と同等となります。
VPN ではなくリバース プロキシーを立てて社外からのアクセスを受け付けるような場合や、VPN を使っていても GC への接続を制限しているような場合がこのシナリオに相当します。
社外アクセスで GC に接続ができない場合、SCP が使えないため、通常は https://autodiscover.メールドメイン により Autodiscover が実行できるようにします。
具体的には社内の Exchange サーバーに接続できるリバース プロキシーのサーバーの IP アドレスが autodiscover.メールドメインによって解決されるように DNS の A レコードまたは CNAME レコードで設定し、その名前を含む証明書がリバース プロキシーのサーバー証明書として構成されている必要があります。
ノート PC を社内でも社外でも使うというような場合、LKG により社外でも社内のサーバーの URL で Autodiscover が実行されることがありますので、そのようなアクセスで問題が生じる可能性があるなら、社内も社外も https://autodiscover.メールドメイン で統一するという方法もあります。
なお、社外からドメイン名でアクセスすると http://www.ドメイン名 というサーバーにリダイレクトされるというような構成をしている場合がありますが、そのような環境では https://autodiscover.メールドメイン の前に https://メールドメイン にリクエストが行われ、想定外の警告が表示される可能性があります。
そのため、ExcludeHttpsRootDomain を設定しておくとよいでしょう。
シナリオ 3: Exchange オンプレミス環境 – 複数フォレスト、信頼関係あり
このシナリオは、Exchange サーバーがインストールされたフォレストとクライアントのフォレストが異なるものの、フォレスト間で信頼関係が結ばれており、クライアントのログオンで使用したアカウントの認証情報で別フォレストにある Exchange サーバーに接続できるというものです。
この場合、既定では SCP が使用できませんが、前回の手順 5 で説明した通り Export-AutoDiscoverConfig で SCP の情報をクライアント側のフォレストにエクスポートすることで、SCP による Autodiscover が成功する動作となります。
注意点としてはクライアントと Exchange フォレストにある GC の間にファイアウォールがあり、LDAP などをブロックしてしまうと、SCP による Autodiscover が失敗するというものがあります。
なお、何らかの理由で Export-AutoDiscoverConfig が実行できないような場合は、次のシナリオ 4 と同じ状態になります。
シナリオ 4: Exchange オンプレミス環境 – 複数フォレスト、信頼関係なし
このシナリオは、Exchange サーバーがインストールされたフォレストとクライアントのフォレストが異なり、フォレスト間の信頼関係もないというものです。
一般的には、https://autodiscover.メールドメイン で Autodiscover が成功するように構成します。
しかし、多数の異なるフォレストからアクセスが行われ、それぞれが独自のメールドメインを持つというような場合、サーバー証明書の管理が難しくなる可能性があります。
そのような場合は、シナリオ 9 の Exchange ホスティング環境と同様になると考えられます。
なお、クライアント環境の SCP は使用できないので、ExcludeScpLookup を設定してしまってよいでしょう。
また、ExcludeExplicitO365Endpoint や ExcludeHttpsRootDomain も設定したほうが良いかもしれません。
シナリオ 5: Exchange オンプレミス環境 – ワークグループ
通常、企業内で使用するクライアント PC はドメインに参加していると思うのですが、何らかの理由でワークグループの端末から Exchange に接続するというシナリオです。
この場合、SCP は使用できませんので、シナリオ 2 と同様になります。
シナリオ 6: Exchange Online 環境 – オンプレミスなし
このシナリオは、既存のオンプレミス環境にもともと Exchange サーバーは存在せず、新規に Exchange Online を使用するというものです。
この場合は前回の記事の手順 4 (O365 を優先的に確認) が使用されるので、特に設定をしなくても接続はできるはずです。
ただ、この手順は Office 365 ProPlus でしか実行されないため、Outlook 2013 以前や Outlook 2016 の MSI 版を使用している場合には以下のいずれかの DNS 設定が必要になります。
- autodiscover.メールドメイン で autodiscover.outlook.com に接続するよう CNAME レコードを設定
- メールドメインの _autodiscover の SRV レコードで autodiscover-s.outlook.com を設定
CNAME と SRV では設定するサーバー名が異なることに注意してください。
また、ExcludeScpLookup や ExcludeHttpsRootDomain を設定しておくとよいと思います。
シナリオ 7: Exchange Online とオンプレミスのハイブリッド環境
このシナリオは、オンプレミスで Exchange サーバーを使用していた組織が Exchange Online に移行する場合に最もよくあるパターンと考えられます。
この環境で Exchange Online に移行済みのメールボックスにアクセスする場合の Autodiscover の手順は以下のようになります。
- SCP (もしくは https://autodiscover.メールドメイン など) によりオンプレミスの Exchange サーバーから XML ファイルを取得します。
- 取得した XML ファイルには、構成情報ではなく O365 上のメールアドレス (テナントごとに固有の onmicrosoft.com のアドレス) へのリダイレクトが指定されているため、このアドレスで改めて最初から Autodiscover のプロセスを開始します。
- http#x3a;//autodiscover.テナント.onmicrosoft.com で https://autodiscover-s.outlook.com にリダイレクトされ、このサーバーから実際の設定情報を含む XML ファイルを取得します。
このように SCP と HTTP リダイレクトの両方が使用される動作となります。
よくある問題としては http://autodiscover.テナント.onmicrosoft.com の接続がプロキシ設定の問題 (O365 には直接接続が想定されているのに、プロキシの例外として設定されていなかったなど) で失敗するというものがあります。
また、SCP で取得される O365 上のメールアドレスは、AD 上ではユーザーの RemoteRoutingAddress という属性に格納されていますので、何らかの理由でこちらの情報が削除されると Autodiscover が失敗します。
なお、このシナリオではいろいろな Autodiscover が実行される可能性があるのですが、おそらくルートドメインによる Autodiscover が行われることはないので、ExcludeHttpsRootDomain は設定してもよいと思います。
シナリオ 8: Exchange Online とオンプレミスの混在
このシナリオは何らかの理由で Exchange Online とオンプレミスのハイブリッド構成ができず、一時的に Exchange Online とオンプレミスの両方に同じ SMTP アドレスを持つメールボックスが存在してしまうというものです。
このような構成はお勧めできないのですが、どうしてもこの構成をとるのであれば、Autodiscover の構成を慎重に行う必要があります。
まず、Exchange Online 上に作成したテナントでオンプレミスと同じ SMTP アドレスが使用されるようになると、O365 の優先確認により Exchange Online での Autodiscover が実行されるようになります。
この時点でユーザーが Exchange Online にアクセスするための認証情報を持っていなければ Exchange Online に接続はされませんが、不必要な認証ダイアログが起動時などに表示されるという現象が発生します。
また、キャッシュ モードを使用している場合には、オンプレミスで使用していたプロファイルで Autodiscover により Exchange Online の情報が取得されると Exchange Online に接続され、OST に保存されている情報と Exchange Online のメールボックスの情報に不整合が検出されます。
その結果、「メールボックスは、一時的に Microsoft Exchange サーバーで移動されています。」という警告メッセージが表示され、オンライン モードで接続するか、オフラインで OST を参照するかのいずれかしか選択できなくなります。
そのため、プロファイルの再作成は必須なのですが、Exchange Online への移行後に誤ってオンプレミスの Autodiscover に接続されると、再び一時メールボックスの状態になってしまいます。
これらのことを回避するには移行前と移行後でレジストリ設定によりどの Autodiscover を停止するかを厳密にコントロールし、誤って別の Autodiscover で成功しないようにする必要があります。
移行前と移行後で設定すべきレジストリは以下の通りとなります。
移行前 (オンプレミスで Autodiscover)
- ExcludeExplicitO365EndPoint
- ExcludeHttpRedirect
- ExcludeSrvRecord (DNS の SRV レコードに Exchange Online の設定をしている場合のみ)
移行後 (Exchange Online で Autodiscover)
- ExcludeScpLookup
- ExcludeHttpsAutodiscoverDomain
- ExcludeSrvRecord (DNS の SRV レコードにオンプレミスの設定をしている場合のみ)
シナリオ 9: Exchange ホスティング環境
このシナリオは Exchange サーバーを利用して他の会社や個人にメール サービスを提供する環境を想定しています。
この場合、サービスを提供する会社の Active Directory と信頼関係を結ぶどころか、Active Directory が存在しない可能性もあるため、SCP は使用できません。
また、提供するメールアドレスとして顧客ごとに固有のドメインを使うことが想定されるため、https://autodiscover.メールドメイン での Autodiscover をするには以下のいずれかの対処が必要となります。
- メールドメインごとにサーバーを用意する
- 一つのサーバーで複数の autodiscover.メールドメイン の名前を登録した証明書を使用する
しかし、いずれも現実的ではありません。
そこで、http://autodiscover.メールドメイン によるリダイレクトか、DNS の SRV レコードでの Autodiscover を使用することになりますが、リダイレクトの際には警告が表示されてしまいます。
これを回避するには前回の手順 9 に記載した RedirectServers のレジストリ設定をあらかじめクライアントに設定しておく必要があるのですが、レジストリの展開はホスティング サービスでは困難かもしれません。
そのため、マニュアルなどであらかじめ警告が出ることを明記しておくことになるでしょう。
シナリオ 10: POP/IMAP 環境
最後のシナリオは Exchange を使用しない POP/IMAP 環境での Autodiscover です。
前回の手順 8 でも説明しましたが、以下の URL のサンプルを参考にしてXML ファイルを作成することで社内 (あるいは ISP) の POP/IMAP サーバーの構成を自動化することができます。
これについては https://メールドメイン か https://autodiscover.メールドメイン のいずれかのサーバーを用意するというのが妥当と思われます。
注意点としてはこのサーバーに対するリクエストは POST メソッドが使用されるということです。
Autodiscover には POST によりユーザー情報を含んだ XML を提供し、それに合致する構成情報を取得するという前提があるので、Autodiscover で接続されるサーバーが /autodiscover/autodiscover.xml というファイルに対する POST メソッドを拒否するような場合は Autodiscover が失敗します。
したがって、Autodiscover の XML を提供するサーバーについては、実際にサーバーから取得される XML ファイルがユーザー情報を持たない汎用的なものであっても 、必ず POST メソッドで XML ファイルを返すよう構成する必要があります。
Outlook 研究所 