Autodiscover の詳細動作


Outlook には Autodiscover という機能があります。
この機能により、メールアドレスとパスワードだけでメール アカウントの構成に必要なサーバーやポート番号などの情報を取得して設定することができます。
Autodiscover では、最終的にサーバーなどの構成情報を含むデータを XML ファイルとして取得するのですが、Outlook はインターネットで一般的に使われる POP や IMAP といったサーバーだけでなく、Microsoft 独自のプロトコルで接続する Exchange サーバーにも対応するため、XML の取得をいくつかの方法で試みる動作になっています。
そのため、環境によっては情報の取得に時間がかかったり、想定外の警告が表示されるということがあります。
 
Microsoft サポート技術情報の「Outlook 2016 の Autodiscover の実装」によると、以下の順序で Autodiscover が実行されます。

  1. 再起動のシナリオを確認する
  2. ローカル データの環境設定を確認する
  3. 前回の既知の有効 (LKG) データを確認する
  4. O365 を優先的に確認する
  5. SCP データを確認する
  6. ルート ドメインを確認する
  7. Autodiscover ドメイン
  8. ローカル データを確認する
  9. HTTP リダイレクトを確認する
  10. SRV データを確認する
  11. O365 のフェールセーフを確認する

前述のサポート技術情報では上記の概要が説明されていますが、具体的にどのような処理が行われるかや、どのようなシナリオで必要なのかなど、トラブルシュートに必要な詳細情報がありません。
そこで、今回の記事では、Autodiscover の詳細について上記の順で説明したいと思います。

手順 0: ローカルにキャッシュされた XML ファイルを確認する

いきなり上記の手順にない処理からスタートしましたが、この手順はすでにプロファイルが作成済みの場合の起動時のみ実行されます。
この手順以外で Autodiscover が成功すると、その際にサーバーから取得した XML ファイルが以下の通り保存されます。
 
フォルダー: C:\Users\ユーザー名\AppData\Local\Microsoft\Outlook\16
ファイル名: AutoD.メールアドレス.xml
 
そして、2 回目以降の起動ではこのファイルを読み込んでサーバーに接続するため、素早く起動できるというメリットがあります。
言い換えると、このファイルが何らかの理由で削除されると、Outlook 起動時に上記の手順で Autodiscover が実行される動作となるので、環境によっては起動に時間がかかるということになります。
 
特に RDS や VDI 環境で移動ユーザー プロファイルを使用している場合、通常は上記のファイルは移動対象ではなく、ログオフ時に削除されるため、このような環境でログオン直後の初回の Outlook の起動にだけ時間がかかるという現象の原因は上記のファイルが削除されることにあると考えられます。
 
また、サーバーの移動や、オンプレミスの Exchange サーバーから Exchange Online に移動した後のサーバー切り替えに失敗するという場合、上記のファイルに移動前の古い情報が残っており、その情報での接続で失敗までに時間がかかりすぎている可能性があります。
そのような場合は、切り替え後に一度上記のファイルを削除することで回避するかもしれません。

手順 1: 再起動のシナリオを確認する

この手順は技術情報にもある通り、Outlook の起動中に Exchange アカウントを追加し、再起動した際に実行されるシナリオです。
具体的には、Outlook の起動中に Exchange アカウントを追加すると、Autodiscover が実行されますが、取得された XML ファイルの内容が以下の通り保存されます。
 
フォルダー: C:\Users\ユーザー名\AppData\Local\Microsoft\Outlook
ファイル名: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}.txt
※ X はランダムな 16 進数
 
また、以下のレジストリも設定されます。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Profiles\プロファイル名\AutoDisc
名前: 追加したアカウントのメールアドレス
種類: REG_BINARY
値: UNICODE で上記のファイルのフルパスを含むバイナリデータ
 
そして、次回起動時に Outlook がプロファイルのレジストリに上記のデータが含まれていることを確認すると、データに格納されているパスのファイルから Autodiscover の設定を読み込み、サーバーの構成を行います。
通常起こることではありませんが、もしアカウントを追加してから Outlook を終了し、次に起動するまでに上記のファイルが削除されたような場合、次回起動時のアカウント追加処理が失敗し、アカウントの追加は行われません。 

手順 2: ローカル データの環境設定を確認する

この手順は以下のレジストリ設定がなければ実行されません。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
名前: PreferLocalXML
種類: REG_DWORD
値: 1
 
この設定は手順 8 の「ローカル データを確認する」の処理を他よりも前に実行させることを目的としています。
何らかの理由で手順 3 から手順 7 をレジストリ設定でスキップさせずに手順 8 を実行させたい場合にこの設定を行います。
例えば、特定のドメインだけローカル XML で構成し、ほかのドメインは通常の Autodiscover で構成するというような場合などが考えられます。
 
ローカル データの確認の詳細については、手順 8 で説明します。 

手順 3: 前回の既知の有効 (LKG) データを確認する

この手順はプロファイルが作成されている状況でのみ実行され、アカウント作成時には実行されません。
正常にプロファイルが作成されてアカウントが追加されると、以下のレジストリに Autodiscover の XML ファイルを取得した URL が Unicode のバイナリで格納されます。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Profiles\プロファイル名\アカウントごとのランダムな 16 進数
名前: 001f664a
種類: REG_BINARY
 
そして、次回以降の Autodiscover は試行錯誤せずに前回の既知の有効な (Last Known Good) URL にアクセスすることで、時間が短縮できるというものです。
サーバーの移行などにより LKG URL が無効となってしまった状況で、この URL へのアクセスが問題になるようであれば以下のレジストリ設定でこの動作を無効にすることができます。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
名前: ExcludeLastKnownGoodURL
種類: REG_DWORD
値: 1
 
ただし、この設定を行うと、後述の SCP による Autodiscover のために GC へのアクセスが発生して GC の負荷が増大したり、Autodiscover に時間がかかるようになる可能性があります。 

手順 4: O365 を優先的に確認する

こちらは、Outlook for Office 365 ProPlus において、特に設定を行っていない状況で最初に行われる Autodiscover の手順です。

技術情報では「Outlook は一連のヒューリスティックを使用して、指定されたユーザー アカウントが Office 365 から提供されたかどうかを判断します」とあるのですが、実際に判断しているのは実は Outlook ではありません。
まず、Outlook は以下の URL で GET リクエストを行います。
 
https://outlook.office365.com/autodiscover/autodiscover.json/v1.0/メールアドレス?Protocol=Autodiscoverv1
 
そうすると、これを受け取った O365 のサーバーがメールアドレスに応じて正しいと思われる Autodiscover URL へのリダイレクトを行います。
つまり、判定を行っているのは O365 のサーバーになります。
ただし、厳密にメールアドレスのチェックを行っているわけではなく、O365 に登録されているドメインであれば O365 の Exchange サーバーの URL に、そうでなければ https://autodiscover.メールドメイン/autodiscover/autodiscover.xml にリダイレクトされるという動作のようです。
そして、O365 のアカウントであれば最終的に https://outlook.office365.com/autodiscover/autodiscover.xml で構成情報の取得が成功します。
 
O365 にメールボックスがなく、outlook.office365.com というサーバーにアクセスができない環境で失敗までに時間がかかるような場合には、以下のレジストリ設定でこの動作を無効にすることができます。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
名前: ExcludeExplicitO365Endpoint
種類: REG_DWORD
値: 1 

手順 5: SCP データを確認する

この手順は、ドメインに参加しているクライアントでのみ実行される手順です。
Exchange サーバーがインストールされると、Active Directory の構成名前付きコンテキストに Autodiscover の URL が書き込まれます。
具体的には以下の DN のオブジェクトの serviceConnectionPoint プロパティに格納されます。
 
CN=サーバー名,CN=Autodiscover,CN=Protocols,CN=サーバー名,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=組織名,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=組織固有の DC
 
Outlook は PC が Active Directory ドメインに参加していることを認識すると、LDAP によりドメインの GC に対して上記のオブジェクトを Keyword の値で検索し、見つかったオブジェクトの serviceConnectionPoint プロパティに格納されている URL に対して HTTP のリクエストを行って自動構成の XML を取得します。
 
既定では、Exchange サーバーが異なるフォレストにインストールされている場合には上記の情報がクライアントの AD 上に存在しないため SCP による構成は失敗します。
しかし、Exchange サーバーの Export-AutoDiscoverConfig コマンドレットでクライアントのフォレストに SCP の情報をエクスポートすると、そのフォレストで SCP による Autodiscover ができるようになります。
この場合、クライアントの AD では以下の DN のオブジェクトが生成されます。
 
CN=Exchange のドメイン名,CN=Microsoft Exchange Autodiscover,CN=Services,CN=Configuration,DC=組織固有の DC
 
そして、このオブジェクトの serviceConnectionPoint プロパティの serviceConnectionPoint プロパティの値を取得するのですが、ここに格納されているのは Autodiscover の URL 自体ではなく、LDAP://<ドメイン名> という LDAP の URL となります。
そこで、Outlook は指定された LDAP URL に対して改めて SCP 取得のための検索を行い、見つかったオブジェクトの serviceConnectionPoint プロパティから Autodiscover の URL を取得するという処理を行います。
そのため、別フォレストの Exchange への Autodiscover を SCP で成功させるには以下のような要件が必要になります。

  • DNS により Exchange のドメインの LDAP の SRV レコードが取得できる
  • Exchange のドメインの GC の LDAP (TCP ポート 389) に接続ができる
  • Exchange のドメインの GC に対して Windows にログオンしたユーザーの資格情報で認証が通る

クライアントが所属するフォレストに Exchange サーバーが存在せず、GC への不要な LDAP アクセスを抑止したいような場合には、以下のレジストリ設定でこの動作を無効にすることができます。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
名前: ExcludeScpLookup
種類: REG_DWORD
値: 1

手順 6: ルート ドメインを確認する

この手順では、以下のような URL での Autodiscover を実行します。
 
https://<メールドメイン>/Autodiscover/Autodiscover.xml
 
例えば、user@example.com というメールアドレスの Autodiscover の場合、https://example.com/Autodiscover/Autodiscover.xml という URL で構成情報の取得を行います。
これが成功するにはドメイン名で解決される IP アドレスでサーバーが稼働しており、そのサーバーのサーバー証明書の名前にドメイン名が設定されている必要があります。
インターネット プロバイダーなどで POP/IMAP アカウントを Autodiscover で構成する場合などに使用することが想定されていると思われます。
 
なお、Active Directory 環境では、ドメイン名で名前解決するとドメイン コントローラーの IP が返され、https://ドメイン名/ でドメイン コントローラーへのアクセスが発生する場合があります。
また、DNS の管理を外部に委託している場合に、ドメイン名でのアクセスが委託先のサーバーへのリクエストになり、想定外の認証要求や証明書エラー、接続遅延などの原因になることもあります。
例えば、Outlook の起動時に認証ダイアログが表示され、何を入力しても通らないものの、キャンセルしても特に問題ないというような場合、ルート ドメインの Autodiscover が原因の可能性があります。
そのため、Exchange アカウントを作る前提の場合は、以下のレジストリ設定でこの動作を無効にすることをお勧めします。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
名前: ExcludeHttpsRootDomain
種類: REG_DWORD
値: 1 

手順 7: Autodiscover ドメイン

この手順では、以下のような URL での Autodiscover を実行します。
 
https://autodiscover.メールドメイン/Autodiscover/Autodiscover.xml
 
例えば、user@example.com というメールアドレスの Autodiscover の場合、https://autodiscover.example.com/Autodiscover/Autodiscover.xml という URL で構成情報の取得を行います。
オンプレミス環境で社外から接続するというような場合や、ワークグループもしくは Exchange サーバーとは別のフォレスト環境から接続する場合には、SCP での取得ができないため、この手順で Autodiscover を実行するのが一般的です。
この手順が実施されるときのポイントとしては、autodiscover.メールドメイン という名前で解決されるサーバーのサーバー証明書の名前に autodiscover.メールドメイン が含まれていなければならないという点があります。
通常、Exchange サーバーを構築する際にはサーバー自体に autodiscover という名前を付けることはほとんどないと思われるので、サーバー証明書にも実サーバーの名前を設定し、DNS の CNAME で autodiscover として実サーバーに接続するよう構成することになります。
しかし、サーバー証明書に autodiscover が別名で登録されていない場合には、Outlook が https://autodiscover.メールドメイン としてアクセスした際に、想定したサーバー名と異なる証明書であるため、警告が表示される結果となります。
これを回避するには、Exchange に登録するサーバー証明書に以下のいずれかの対応を行う必要があります。

  • 別名として autodiscover.メールドメイン を登録する
  • ワイルドカード証明書を使用する (名前を *.メールドメイン とする)

なお、O365 環境では autodiscover.メールドメイン というサーバーは CNAME で autodiscover.outlook.com に接続されるように構成されることがあります、このサーバーでは TCP ポート 443 での接続は遮断されるので、この手順は失敗するのが想定される動作です。
 
autodiscover という名前で CNAME の登録をしていないような場合には、以下のレジストリ設定でこの動作を無効にすることができます。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
名前: ExcludeHttpsAutodiscoverDomain
種類: REG_DWORD
値: 1 

手順 8: ローカル データを確認する

この手順はあらかじめ Autodiscover の XML ファイルを作成してクライアントに配布しておき、それをもとに自動構成を行うというものです。
この手順を行うには、ローカル ファイルに XML ファイルを配置し、以下のレジストリに保存した XML ファイルのパスを記述する必要があります。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
名前: メールドメイン
種類: REG_SZ
値: XML ファイルのフル パス名
 
Outlook 2010 までは既定でいくつかのプロバイダの XML ファイルがインストールされていたのですが、Outlook 2013 以降はインストールされなくなったようです。
ローカルの XML ファイルだとプロバイダ側での構成変更に対応できなかったからかもしれません。
 
保存する XML ファイルには以下の 2 つのパターンがあります。 

  • XML に構成情報を記載する
  • XML にリダイレクト URL を記載する

前者は、ユーザーごとに固有の情報がメールアドレスやログオン情報のみの場合に有効な方法です。
Outlook 2013 まではこの方法で Exchange アカウントの構成もできていたのですが、Outlook 2016 以降ではこの方法での Exchange アカウントの構成はできなくなりました。
POP/IMAP などの環境であれば Outlook 2016 以降でも構成は可能であり、以下の URL のサンプルを参考にしてXML ファイルを作成することで社内の POP/IMAP サーバーの構成を自動化することもできます。
https://docs.microsoft.com/ja-jp/previous-versions/office/office-2010/cc511507(v=office.14)?redirectedfrom=MSDN
 
後者は、XML ファイル自体には構成情報が含まれておらず、実際に構成情報を取得するための URL が記載されているというものです。
例えば、O365 に接続するための Autodiscover の URL を XML ファイルに記述する場合は以下のようなものとなります。
 
<?xml version=”1.0″ encoding=”utf-8″ ?>
<Autodiscover xmlns=”http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006″>
<Response xmlns=”http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a”>
<Account>
<AccountType>email</AccountType>
<Action>redirectUrl</Action>
<RedirectUrl>https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml</RedirectUrl>
</Account>
</Response>
</Autodiscover>
 
この方法は、O365 に接続したいものの、DNS の構成に手が出せず、後述の CNAME レコードも SRV レコードも設定できないというような場合に使われるようです。
 
なお、メールドメインのレジストリ設定がなければ実行されないものであるため、この手順を無効にするレジストリ設定はありません。 

手順 9: HTTP リダイレクトを確認する

この手順では、まず以下のような URL にアクセスします。
 
http://autodiscover.メールドメイン/Autodiscover/Autodiscover.xml
 
例えば、user@example.com というメールアドレスの Autodiscover の場合、http://autodiscover.example.com/Autodiscover/Autodiscover.xml という URL にアクセスするのですが、この URL で構成情報の取得は行われません。
その代わり、サーバーから HTTP の 302 という応答とともにリダイレクト先の URL が返され、その URL から構成情報を取得するという動作になります。
このような手順が必要となる理由としては、サーバー証明書のサーバー名が特定できない環境があるためです。
具体的にはパブリック クラウド環境や多数のメールドメインを持つような大企業などでは、たとえワイルドカード証明書を使ったとしてもサーバー証明書に追加しなければならない名前が多すぎたり、証明書の書き換えが頻繁に発生する状況となります。
こうした環境で https://autodiscover.ルートドメイン で証明書の警告を出さないようにすることは難しいため、証明書のチェックが不要な http://autodiscover.ルートドメイン にアクセスを行い、そこから単一の URL にリクエストを転送することで、サーバー証明書の問題が回避させるというのがこの手順の目的です。
 
ただし、http によるリクエストの場合、そのサーバーの信頼性が確認できず、何らかの方法で不正なサーバーにリダイレクトされる可能性もあります。
そのため、リダイレクトの際に「この Web サイトで メールアドレス のサーバー設定を構成できるようにしますか?」というような警告メッセージが表示されます。
このダイアログを最初から表示させたくない場合には、以下のレジストリ設定を行う必要があります。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover\RedirectServers
名前: リダイレクト先サーバーの FQDN
種類: REG_SZ
値: 空の文字列
 
DNS に autodiscover という名前で CNAME の登録をしていないような場合には、以下のレジストリ設定でこの動作を無効にすることができます。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
名前: ExcludeHttpRedirect
種類: REG_DWORD
値: 1 

手順 10: SRV データを確認する

この手順は DNS の “メールドメイン” の SRV レコードに以下のような値を設定しておくことで、指定されたサーバーから構成情報を取得するというものです。
 
サービス: _autodiscover
プロトコル: _tcp
ポート番号: 443
ホスト: Autodiscover の取得先となるサーバーの FQDN
 
こちらも、手順 9 と同様に多数のメールドメインを扱う環境で使用され、サーバーにアクセスする際にリダイレクトの警告が表示されます。
警告を表示しないようにする設定も手順 9 と同じです。
 
DNS に Autodiscover の SRV レコードの登録をしていないような場合には、以下のレジストリ設定でこの動作を無効にすることができます。
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover
名前: ExcludeSrvRecord
種類: REG_DWORD
値: 1 

手順 11: O365 のフェールセーフを確認する

最後の手順は、アカウント作成時には行われません。
既存のアカウントが O365 のものであることがわかっている状況で、何故か Autodiscover に失敗してしまったという場合に、 O365 の既知の Autodiscover URL から構成情報を取得するというものです。
この動作は手順 4  のレジストリ設定で O365 の優先構成を無効にすると、自動的に無効化されます。

まとめ

上記のように Outlook は様々な方法で Autodiscover を実行しますが、基本的にはどれか 1 つ成功すればよいものであるため、不要な手順は ExcludeXXX レジストリにより無効化しておくと時間短縮や想定外の動作の抑制になるでしょう。
無効化するためのレジストリのキーとしては HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Autodiscover と記載しましたが、グループ ポリシーで展開する場合には HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\Autodiscover というキーで展開することになります。
 
「説明が長すぎて結局どの手順で成功するのかわからない」という方もいると思うので、来週は一般的な環境でどの Autodiscover の手順により構成されるかの解説をします。

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト /  変更 )

Google フォト

Google アカウントを使ってコメントしています。 ログアウト /  変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト /  変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト /  変更 )

%s と連携中