概要
Autodiscover は、Outlook が接続先サーバーの構成情報を取得するために使用する機能です。 Outlook 2016 と Exchange Server を組み合わせて使用する場合、Autodiscover が構成情報について信頼できる唯一の情報源です。Outlook が完全に機能するには、Autodiscover が正しく構成され、動作している必要があります。 この資料では、Outlook 2016 の現在のチャネル クイック実行リリースで Autodiscover を実装する方法について説明します。 Office 365 クライアントのチャネル リリースの詳細については、次のマイクロソフト Web サイトを参照してください。
更新プログラム チャネル リリースのバージョン番号とビルド番号
Office 365 クライアント更新プログラムのチャネル リリース
詳細情報
Autodiscover のタイミング
Autodiscover は次の時間に実行されます。
- アカウントの作成時。
- 設定された間隔で、Exchange Web サービス機能 (OOF、空き時間情報サービスなど) を提供する URL の変更を収集します。 このプロセスに成功すると、1 時間後に次の試行が実行されます。 試行に成功しない場合、5 分後に次の試行が実行されます。 すべての Microsoft Office アプリケーションに使用されるバックグラウンド タスク インフラストラクチャがあるので、試行ごとに 25％ のずれが生じる可能性があります。
- 特定の接続エラーに応答したとき。 さまざまなシナリオで、接続の試行に失敗すると、接続の問題を修正するために、Outlook で新しい設定を取得する Autodiscover タスクが開始されます。
- 別のアプリケーションが 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 プロセス中に使用することを確実にするために、利用できます。
自動検出プロセス Outlook で自動検出情報が必要になるたびに、一連の順序付けされた手順を使用して、構成設定を含む 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 に進みます。
自動検出 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 から提供されたかどうかを判断します。 自分が O365 ユーザーであると確信している場合は、既知の O365 エンドポイント (通常は https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml または https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml) から自動検出ペイロードを取得しようとします。 この手順でペイロードが取得されない場合、Outlook は手順 5 に進みます。
この手順のポリシー制御値は
ExcludeExplicitO365Endpoint です。
ITAR 考察
既定では、Outlook は、 Autodiscover ペイロードを取得するために既知のエンドポイントにクエリを実行します。 この手順を省略する既存のポリシーは有効であり、エンドポイントを試さずに、手順 5 に移動して使用することができます。 代わりに、Outlook に重要な Office 365 の構成サービスを照会するよう指示して、適切な URL を取得し、そこから Autodiscover ペイロードを取得する新しいポリシーがあります。 概念的には、プロセスは次のように進みます。
- 新しいポリシーを設定します。
- Autodiscover プロセスの手順 4 の間には、Outlook は Office 365 構成サービスを照会します。
- サービスは、必要であるどの特別な ITAR が (もしあれば) 指定されたユーザーに対して有効であると判断し、UPN のドメイン情報を使用して、そのユーザーの適切な URL を返します。
- 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://<domain>/自動検出/autodiscover.xml の形式で URL を作成し、結果の URL からペイロードを取得しようとします。 多くのルート ドメインは Autodiscover 用に構成されていないため、Outlook は、取得の試行中に発生した証明書エラーを意図的に表示しません。 この手順でペイロードが取得されない場合、Outlook は手順 7 に移動します。
この手順のポリシー制御値は、 ExcludeHttpsRootDomain です。
手順 7: 自動検出ドメインを確認する
この手順では、Outlook は初期アドレスのドメイン名から https://autodiscover.< の形式で URL を作成します。domain>/autodiscover/autodiscover.xml し、結果の URL からペイロードを取得しようとします。 通常、これは Autodiscover データのプライマリ URL なので、Outlook は取得の試行中に発生した証明書エラーを非表示にしません。 この手順でペイロードが取得されない場合、Outlook は手順 8 に移動します。
この手順のポリシー制御値は、 ExcludeHttpsAutoDiscoverDomain です。
手順 8: ローカル データを確認する
手順 2 では、Outlook は管理者が環境設定として Autodiscover ペイロードを特に確認するポリシーを展開しているかどうかを確認しました。 ポリシーが設定されておらず、前の手順でペイロードが取得されなかった場合、Outlook は PreferLocalXML 設定がない場合でもローカル ファイルからペイロードの取得を試行します。 この手順でペイロードが取得されない場合、Outlook は手順 9 に移動します。
この手順のポリシー制御はありません。
手順 9: HTTP リダイレクトを確認する
この手順では、Outlook から自動検出ドメイン URL (http://autodiscover.< に要求が送信されますdomain>/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 の設定サービスを呼び出します。 その変更が行われたとき、この資料は新しい手順を反映するように更新されます。
[自動検出プロセス] セクションの手順 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 ペイロードの取得を試行します。
例外 自動検出プロセスセクションの手順は、Outlook が自動検出ペイロードの取得を試みる一般的なルールです。 様々な最適化と例外的な試みのため、少しプロセスを変更することがあります。 たとえば、新しいアカウント作成を行う場合、前回の既知の有効なエントリはまだ存在しないため、Outlook は内部的に手順 3 (前回の既知の有効 (LKG) データを確認する) をスキップします。 同様に、現在の構成情報を使用してエラーが発生したために試行がトリガーされた場合、Outlook は意図的に Autodiscover を再実行しますが、前回の既知の有効な情報はエラーになると推定されるので、LKG 情報を使用しません。
ポリシーコントロール 自動検出プロセス セクションで定義されているポリシー値は、ポリシーベースのレジストリ値またはポリシーベース以外の値のいずれかです。 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 が設定されます。 たとえば、値 ExcludeHttpsRootDomain を 1 に設定すると、プロセスで手順 6 を実行しないように Outlook が設定されます。
その他のレジストリ制御
Outlook には、Autodiscover プロセスに影響する可能性があるその他のレジストリ ベースの構成オプションがいくつか用意されています。
Office 365 構成サービスを使用する
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
値: EnableOffice365ConfigService
既定値: 0
データ: この DWORD データを 1 に設定して、Outlook が Office 365 Config Service を呼び出して適切な自動検出 URL を取得するように強制します。
HTTP のタイムアウト設定
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
値: タイムアウト
既定値: 25 秒
最小: 10 秒
最大: 120 秒
情報: 指定されたタイムアウトは 、WinHttpSetTimeouts 設定として使用されます。 指定したデータは、WinHttpSetTimeouts API の 4 つのパラメーターすべてに渡されます。 この設定で、到達できない HTTP 要求を早くタイムアウトさせることができるので、全体のパフォーマンスが向上します。 また、タイムアウトを 25 秒を超える値に増やすことで、既定の 25 秒よりも長くかかる HTTP 要求を成功させることもできます。
Mapi/Http プロトコル制御
キー: HKEY_CURRENT_USER\Software\Microsoft\Exchange
値: MapiHttpDisabled
既定値: 0
データ: 1 = プロトコルが無効です。0 = プロトコルが有効
情報: この値は自動検出キーの下にありません。 これは、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 = ヘッダーは追加されません
情報: この値は自動検出キーの下にありません。 この設定は、認証ネゴシエーション ヘッダーを 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 つの証明書エラー状態の詳細 については、WINHTTP_STATUS_CALLBACK コールバック関数 を参照してください。
プロキシ認証処理
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\HTTP\
値: AllowOutlookHttpProxyAuthentication
既定値: 0
データ: 1 = Outlook がプロキシ サーバーからの認証の課題を処理できるようにします。0 = プロキシ サーバーからの認証チャレンジをサイレント で失敗する
情報: このレジストリ値を使用すると、セキュリティ構成の緩和が可能になり、Microsoft サポート技術情報の次の記事で詳しく説明されています。
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 の詳細については、以下のマイクロソフトの資料を参照してください。