Outlook 2016 の Autodiscover の実装

適用対象: Outlook 2016Outlook 2019

概要


Autodiscover は、Outlook が接続先サーバーの構成情報を取得するために使用する機能です。 Outlook 2016 と Exchange Server を組み合わせて使用する場合、Autodiscover が構成情報について信頼できる唯一の情報源です。Outlook が完全に機能するには、Autodiscover が正しく構成され、動作している必要があります。 この資料では、Outlook 2016 の現在のチャネル クイック実行リリースで Autodiscover を実装する方法について説明します。 Office 365 クライアントのチャネル リリースの詳細については、次のマイクロソフト Web サイトを参照してください。

詳細情報


Autodiscover のタイミング

Autodiscover は次の時間に実行されます。
  1. アカウントの作成時。
  2. 設定された間隔で、Exchange Web サービス機能 (OOF、空き時間情報サービスなど) を提供する URL の変更を収集します。 このプロセスに成功すると、1 時間後に次の試行が実行されます。 試行に成功しない場合、5 分後に次の試行が実行されます。 すべての Microsoft Office アプリケーションに使用されるバックグラウンド タスク インフラストラクチャがあるので、試行ごとに 25% のずれが生じる可能性があります。
  3. 特定の接続エラーに応答したとき。 さまざまなシナリオで、接続の試行に失敗すると、接続の問題を修正するために、Outlook で新しい設定を取得する Autodiscover タスクが開始されます。
  4. 別のアプリケーションが MAPI を使用して Autodiscover を呼び出すとき。 MAPI の詳細については、次の MSDN の資料を参照してください。 Outlook MAPI 参照


Autodiscover の効率

Autodiscover プロセスを効率的に実行するには、ユーザー プリンシパル名 (UPN) を使用します。
 
ドメインに参加しているコンピューターで Autodiscover プロセスを開始するには、Outlook がユーザーの UPN を認識している必要があります。 UPN は Windows へのログオンに使用されている場合があります。この場合、Outlook はログオン資格情報から UPN に直接アクセスできます。 ただし、ユーザーが domain\username を使用して Windows にログインしている場合、Outlook はそのユーザーについて同じ資格情報しか持っていません。 Outlook が UPN を取得するには、まずディレクトリでユーザーを検索する必要があります。 Outlook は、この検索で照会を追跡するように要求します。 複雑な環境では、結果が見つかるまでに大量の DC に接続することになる可能性があります。 Outlook がユーザーの UPN を検出すると、その値は プロファイル に キャッシュ され、このユーザーに対する検索は再実行されません。
 

このシナリオを回避するには、ユーザーが domain\username ではなく UPN を使用してログオンするようにします。


ITAR の考慮事項

Microsoft Office 365 は、ITAR オブリゲーションを使用して、お客様をサポートできる機能を提供します。 Outlook の Autodiscover 機能のコンテキストにおいて、この機能セットは、ポリシー設定と Autodiscover に使用されるサービス エンドポイントが最高のクラウド要件を順守することを保証する動作が含まれています。 具体的には、Autodiscover プロセス (手順 4 および手順 11) に記載されている Office 365 の特定の手順内で、ポリシー制御は、適切なサービス エンドポイントが Autodiscover プロセス中に使用することを確実にするために、利用できます。 


Autodiscover プロセス

Outlook は Autodiscover 情報が必要になるたびに、一連の手順で構成設定を含む XML ペイロードの取得を試行します。 これらの手順の多くは、グループ ポリシー オブジェクト (GPO) を使用して制御できます。この GPO 値は手順の説明に含まれています。
 

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

Outlook の実行中に 2 つ目のアカウントを追加するなど、場合によっては、Outlook クライアントの再起動時に使用されるローカル ファイルに Autodiscover ペイロードがキャッシュされることがあります。 Autodiscover の最初の手順では、このような再起動シナリオの途中であることを Outlook に通知する特殊な ブート 情報をレジストリで確認し、特殊なローカル ファイルから Autodiscover ペイロードを読み取ります。 これはまれな場合であり、通常は一般的な Autodiscover の問題の原因ではありません。 この手順で、この特殊なブート シナリオであり、Autodiscover XML データを取得する試行が失敗したと Outlook が判断した場合、Autodiscover の試行全体が失敗します。 以降の手順は試行されません。
 
この手順に固有のポリシー制御はありません。
 


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

Outlook には、構成に使用するための Autodiscover XML ファイルを管理者が展開できるようにする GPO が用意されています。 管理者がこのレジストリ値を展開し、autodiscover.xml ファイルをシードした場合、Outlook はこのファイルから Autodiscover ペイロードを読み取ります。 これも一般的ではない場合であり、通常は一般的な Autodiscover の問題の原因ではありません。 この手順でペイロードが取得されない場合、Outlook は手順 3 に進みます。

Autodiscover XML の詳細については、以下の TechNet の資料を参照してください。 Outlook 2010 でユーザー アカウントを自動的に構成するための計画

この資料は、Outlook 2010 用に作成されました。 しかし、新しいバージョンの Outlook にも関連しています。

この手順のポリシー制御値は PreferLocalXML です。
 

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

Autodiscover が任意の手順で XML ペイロードを正常に取得すると、そのペイロードは "前回の既知の有効" な構成としてローカルにキャッシュされます。 一般的に成功する Autodiscover のペイロードを取得するには、まずこの前回の既知の有効のファイルを使用します。 前回の既知の有効な XML ファイルのパスは、Outlook プロファイルで確認できます。 この LKG 手順は、プライマリ メールボックスの構成を検出するためにのみ使用されます。 Autodiscover の検索対象がプライマリ以外のメールボックス (代替、代理、パブリック フォルダー、グループ メールボックスなど) の場合、LKG 手順は自動的にスキップされます。 この手順でペイロードが取得されない場合、Outlook は手順 4 に進みます。

この手順のポリシー制御値は ExcludeLastKnownGoodURL です。
 

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

Outlook は一連のヒューリスティックを使用して、指定されたユーザー アカウントが Office 365 から提供されたかどうかを判断します。 Outlook が O365 ユーザーであると判定した場合は、既知の O365 エンドポイント (通常は https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml または https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml) から Autodiscover ペイロードの取得が試行されます。 この手順でペイロードが取得されない場合、Outlook は手順 5 に進みます。

この手順のポリシー制御値は ExcludeExplicitO365Endpoint です。


ITAR 考察

既定では、Outlook は、 Autodiscover ペイロードを取得するために既知のエンドポイントにクエリを実行します。 この手順を省略する既存のポリシーは有効であり、エンドポイントを試さずに、手順 5 に移動して使用することができます。 代わりに、Outlook に重要な Office 365 の構成サービスを照会するよう指示して、適切な URL を取得し、そこから Autodiscover ペイロードを取得する新しいポリシーがあります。 概念的には、プロセスは次のように進みます。

  1. 新しいポリシーを設定します。
  2. Autodiscover プロセスの手順 4 の間には、Outlook は Office 365 構成サービスを照会します。
  3. サービスは、必要であるどの特別な ITAR が (もしあれば) 指定されたユーザーに対して有効であると判断し、UPN のドメイン情報を使用して、そのユーザーの適切な URL を返します。
  4. Outlook は、サービスによって提供される URL から Autodiscover ペイロードを取得しようとします。

Office 365 の構成サービスを使用する新しい機能のポリシー制御値は EnableOffice365ConfigService です。

ビルド 16.0.9327.1000 以降は、 EnableOffice365ConfigService ポリシーは使用されなくなりました。


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

コンピューターがドメインに参加している場合、Outlook は LDAP クエリを実行して、Autodiscover XML のパスを返すサービス接続ポイント データを取得します。 次に、SCP の検索から返された各 URL に対して、Autodiscover ペイロードの取得が試行されます。 この手順でペイロードが取得されない場合、Outlook は手順 6 に進みます。

SCP の詳細については、次の MSDN の資料を参照してください。 サービス接続ポイントを使用して発行

この手順のポリシー制御値は ExcludeScpLookup です。
 

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

この手順では、Outlook は https://<ドメイン>/autodiscover/autodiscover.xml の形式で初期アドレスのドメイン名から URL を構築し、結果の URL からペイロードの取得を試行します。 多くのルート ドメインは Autodiscover 用に構成されていないため、Outlook は、取得の試行中に発生した証明書エラーを意図的に表示しません。 この手順でペイロードが取得されない場合、Outlook は手順 7 に進みます。

この手順のポリシー制御値は ExcludeHttpsRootDomain です。
 

手順 7: Autodiscover ドメインを確認する

この手順では、Outlook は https://autodiscover.<ドメイン>/autodiscover/autodiscover.xml の形式で初期アドレスのドメイン名から URL を構築し、結果の URL からペイロードの取得を試行します。 通常、これは Autodiscover データのプライマリ URL なので、Outlook は取得の試行中に発生した証明書エラーを非表示にしません。 この手順でペイロードが取得されない場合、Outlook は手順 8 に進みます。

この手順のポリシー制御値は ExcludeHttpsAutoDiscoverDomain です。
 

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

手順 2 では、Outlook は管理者が環境設定として Autodiscover ペイロードを特に確認するポリシーを展開しているかどうかを確認しました。 ポリシーが設定されておらず、前の手順でペイロードが取得されなかった場合、Outlook は PreferLocalXML 設定がない場合でもローカル ファイルからペイロードの取得を試行します。 この手順でペイロードが取得されない場合、Outlook は手順 9 に進みます。 

この手順のポリシー制御はありません。
 

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

この手順では、Outlook から Autodiscover のドメイン URL (http://autodiscover.<ドメイン>/autodiscover/autodiscover.xml) に要求を送信し、リダイレクト応答をテストします。 リダイレクトではなく実際の Autodiscover XML ペイロードが返された場合、セキュリティ (http) なしで取得されたため、Outlook では実際の Autodiscover XML 応答が無視されます。 応答が有効なリダイレクト URL である場合、Outlook はリダイレクトに従い、新しい URL からペイロード XML の取得を試行します。 また、Outlook は、この手順で有害な可能性がある URL へのリダイレクトを防ぐために証明書チェックも実行します。 この手順でペイロードが取得されない場合、Outlook は手順 10 に進みます。

この手順のポリシー制御値は ExcludeHttpRedirect です。
 

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

この手順では、Outlook は "_autodiscover._tcp.<ドメイン名>" の DNS クエリを作成し、結果をループしてプロトコルとして https を使用する最初のレコードを探します。 次に Outlook はその URL からペイロードの取得を試行します。 この手順でペイロードが取得されない場合、Outlook は手順 11 に進みます。
 
この手順のポリシー制御値は ExcludeSrvRecord

 

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

前のすべての手順でペイロードが返されなかった場合、O365 エンドポイントへの最終的な試行が潜在的に役立っているかどうかを決定するために、Outlook ではあまり制限のないヒューリスティック セットを使用します。 Outlook は、試行に価値があると判断すると、アカウントが O365 アカウントである場合に、既知の O365 Autodiscover エンドポイントを試行します。 この試行では、手順 4 と同じターゲット URL が使用されます。異なるのは、Autodiscover プロセスの前の段階ではなく最後の手段として試行されたという点のみです。

この手順のポリシー制御値は ExcludeExplicitO365Endpoint です。

ITAR の考慮事項
Outlook がこの手順に到達し、Autodiscover のペイロードを正常に取得していない場合、よく知られている Office 365 エンドポイントが試行されるべきかどうかを確認する 2 つのテストが実行されます。 最初に、メールボックスが消費者のアカウント (たとえば outlook.com) の場合、よく知られたエンドポイントが試行されます。 第二に、メールボックスが、ITAR の要件を持っていないドメインに属していると判断した場合は、既知のエンドポイントが試行されます。 メールボックスが商業用であり、ITAR の要件を持つドメインに属していると判断した場合、よく知られている Office 365 エンドポイントでは試行されません。 将来のリリースでは、手順 11 は手順 4 と同じロジックで移動し、Office 365 の設定サービスを呼び出します。 その変更が行われたとき、この資料は新しい手順を反映するように更新されます。


リダイレクトの処理

「Autodiscover プロセス」セクションの手順 9 は、セキュリティで保護されていないリダイレクト データを処理するための手順です。 その他のセキュリティで保護された手順では、Autodiscover XML ペイロードの取得を試行した場合、エンドポイントから受け取る可能性のある応答の 1 つとして、リダイレクト応答があります。 この応答に従って、Outlook は新しい、別の URL にリダイレクトしてペイロードの取得を試行します。 さらに、リダイレクト データには、Autodiscover 試行のターゲット アドレスとして使用できる別の新しい電子メール アドレスが含まれている場合があります。 Outlook では、3 つの応答が「リダイレクト応答」と見なされます。
  • 新しい URL を含む HTTP 状態コード (301、302)
  • 200 の HTTP 状態コード (ただし、別の URL にリダイレクトするように Outlook に指示するペイロード XML が含まれている)
  • 200 の HTTP 状態コード (ただし、異なる SMTP アドレスをターゲット アドレスとして使用するように Outlook に指示する ペイロード XML が含まれている)

ケース 1 と 2 の場合、プロトコルが https であれば、Outlook は新しい URL から Autodiscover XML の取得を試行します。 セキュリティで保護されていない (http) URL は試行されません。 さらに、新しい URL のプロトコルが https であっても、Outlook は追加のセキュリティ対策を講じるために証明書情報を確認します。

ケース 3 の場合、Outlook は Autodiscover プロセス全体を最初から開始します。  新しい電子メール アドレスを使用してすべての手順 (1-11) の試行が成功しなかった場合、Outlook は元の電子メール アドレスに戻り、手順 5 に進み、元のアドレスで XML ペイロードの取得を試行します。


例外

Autodiscover プロセスのセクションの手順は、Outlook が Autodiscover ペイロードを取得しようとしている方法の一般的なルールです。 様々な最適化と例外的な試みのため、少しプロセスを変更することがあります。 たとえば、新しいアカウント作成を行う場合、前回の既知の有効なエントリはまだ存在しないため、Outlook は内部的に手順 3 (前回の既知の有効 (LKG) データを確認する) をスキップします。  同様に、現在の構成情報を使用してエラーが発生したために試行がトリガーされた場合、Outlook は意図的に Autodiscover を再実行しますが、前回の既知の有効な情報はエラーになると推定されるので、LKG 情報を使用しません。


ポリシー制御

「Autodiscover プロセス」セクションで定義されるポリシー値は、ポリシー ベースのレジストリ値またはポリシー ベースではない値のいずれかです。  GPO、またはポリシー キーの手動構成を使用して展開された設定の場合、ポリシーではないキーよりも優先されます。

ポリシーではないキー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover

ポリシー キー: HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover

各値の種類は DWORD です。

PreferLocalXML は、1 を設定するとプロセス内のその手順が有効になるように Outlook が設定されるので、他の制御値とは異なります。  その他の値については、1 を設定すると、関連する手順が無効になるように、またはスキップされるように Outlook が設定されます。 たとえば、値 ExcludeHttpsRootDomain1 に設定すると、プロセス内の手順 6 を実行しないように Outlook が設定されます。


その他のレジストリ制御

Outlook には、Autodiscover プロセスに影響する可能性があるその他のレジストリ ベースの構成オプションがいくつか用意されています。

Office 365 構成サービスを使用する

キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
値: EnableOffice365ConfigService
既定値: 0
データ : この DWORD データを 1 に設定し、Outlook に、強制的に適切な Autodiscover URL を取得するために Office 365 設定サービスを呼び出させます。

HTTP のタイムアウト設定
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
値: タイムアウト
既定値: 25 Seconds
最小: 10 Seconds
最大: 120 Seconds
 
情報: 指定したタイムアウトは、WinHttpSetTimeouts 設定として使用されます。 指定したデータは、WinHttpSetTimeouts API の 4 つのパラメーターすべてに渡されます。 この設定で、到達できない HTTP 要求を早くタイムアウトさせることができるので、全体のパフォーマンスが向上します。 また、タイムアウトを 25 秒を超える値に増やすことで、既定の 25 秒よりも長くかかる HTTP 要求を成功させることもできます。

Mapi/Http プロトコル制御
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Exchange
値: MapiHttpDisabled
既定値: 0
データ : 1 = プロトコルは無効、0 = プロトコルは有効
 
情報: この値は Autodiscover キー以下にありません。 これは、Outlook が Mapi/Http プロトコル スタックを使用して Exchange に接続を試行するかどうかを制御する一般的な設定です。 Outlook 2016 の既定では、このプロトコルを無効にすることはできません。 そのため、Autodiscover プロセスで特殊なヘッダー (X-MapiHttpCapability:1) を検出プロセスに追加して、Mapi/Http プロトコル設定を評価して処理できるようにします。

レガシ認証ネゴシエーション制御
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\RPC
値: AllowNegoCapabilityHeader
既定値: 0
データ : 1 = ヘッダーが追加される、0 = ヘッダーは追加されない
 
情報: この値は Autodiscover キー以下にありません。 この設定は、認証ネゴシエーション ヘッダーを http 要求に追加するかどうかを制御します。 ヘッダーの内容は、クライアント コンピューターの認証機能によって変わります。 ヘッダーの一例を次に示します。 X-Nego-Capability: Negotiate, pku2u, Kerberos, NTLM, MSOIDSSP”. このレジストリ値と、それを追加するヘッダーは、先進認証スタックではほとんど使用されません。また、tAodiscover プロセスに悪影響も肯定的な影響も与える可能性はほとんどありません。

証明書のエラー処理
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
値: ShowCertErrors
既定値: 0
データ : 1 = 証明書の警告/エラーを表示する、0 = 証明書の警告を表示しない
 
情報: この値は、Outlook が HTTP タスクの実行時に受け取る証明書のエラーと警告を処理する方法を制御します。 この設定は、場合 (「Autodiscover プロセス」セクションの手順 6) によっては Outlook が上書きすることがありますが、一般的なケースでは、この設定を有効にすると、証明書のエラーまたは警告が表示され、ユーザーは HTTP 要求を OK またはキャンセルできるようになります。 ユーザーが無視できる証明書のエラーは 3 つあり、これらのエラーが発生すると Outlook は HTTP 要求を再試行します。
  • WINHTTP_CALLBACK_STATUS_FLAG_CERT_DATE_INVALID – 証明書のプロパティの日付に問題があります
  • WINHTTP_CALLBACK_STATUS_FLAG_CERT_CN_INVALID – 証明書のプロパティの共通名に問題があります
  • WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA – 証明書のプロパティの認証機関に問題があります

    これら 3 つの証明書エラーの状態にの詳細については、https://msdn.microsoft.com/ja-jp/library/windows/desktop/aa383917(v=vs.85).aspx を参照してください。
プロキシ認証処理
 
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\HTTP\
値: AllowOutlookHttpProxyAuthentication
既定値: 0
データ : 1 = Outlook がプロキシ サーバーからの認証チャレンジを処理できるようにする、0 = プロキシ サーバーからの認証チャレンジはエラーを返さずに失敗する
 
情報: このレジストリ値を使用すると、セキュリティ構成を緩和できます。詳細については、次のマイクロソフト サポート技術情報を参照してください。

3115474 MS16-099: Outlook 2010 セキュリティ更新プログラムについて 2016 年 8 月 9 日

他のプロトコル用の Autodiscover

Outlook で機能として Autodiscover を使用し、Exchange ActiveSync (EAS) アカウントを検出して構成することもできます。 EAS Autodiscover のプロセスと意思決定方法は、この資料で説明した手順とは異なります。 たとえば、EAS の実装では O365 エンドポイント ロジックが実装されておらず、SCP の場所を確認する手順はありません。 この資料では、Outlook が Autodiscover を使用して、Exchange から MAPI ベースのプロトコルの取得を試行する詳細な手順を中心に説明しています。

関連情報


Autodiscover に関する以前の情報については、マイクロソフト サポート技術情報の次の資料を参照してください。

2212902 \Autodiscover キーの下にレジストリ設定があると、予期しない Autodiscover の動作が発生する


Autodiscover の詳細については、以下のマイクロソフトの資料を参照してください。