概要
自動検出は、接続Outlookの構成情報を取得するために使用する機能です。 Outlook 2016 Exchange サーバーでは、自動検出は構成情報の単一の真のポイントと見なされ、Outlook が完全に機能するように構成し、正しく動作する必要があります。 この記事では、現在のチャネルでの自動検出の実装と、クイック実行のOutlook 2016。 クライアント チャネルのリリースOffice 365については、次の Microsoft Web サイトを参照してください。
詳細情報
Autodiscover のタイミング
Autodiscover は次の時間に実行されます。
-
アカウントの作成時。
-
設定された間隔で、Exchange Web サービス機能 (OOF、空き時間情報サービスなど) を提供する URL の変更を収集します。 このプロセスに成功すると、1 時間後に次の試行が実行されます。 試行に成功しなかった場合、次の試行は 5 分後に行います。 すべてのアプリケーションで使用されるバックグラウンド タスク インフラストラクチャにより、各試行を 25% Microsoft Office可能性があります。
-
特定の接続エラーに応答したとき。 さまざまなシナリオで、接続の試行に失敗すると、接続の問題を修正するために、Outlook で新しい設定を取得する Autodiscover タスクが開始されます。
-
別のアプリケーションが MAPI を使用して Autodiscover を呼び出すとき。 MAPI の詳細については、MSDN の資料「Outlook MAPI リファレンス」を参照してください。
自動検出の効率
自動 検出プロセスを迅速化するには、 ユーザー プリンシパル名 (UPN) を使用します。
ドメインに参加しているコンピューターでは、Outlook検出プロセスを開始するために、ユーザーの UPN を知っている必要があります。 UPN は、ログオン資格情報から UPN にWindows使用されている可能性Outlook UPN に直接アクセスできます。 ただし、ユーザーがドメイン\ユーザー名を使用してWindows、Outlookに対して同じ資格情報のみを持っている必要があります。 UPN を取得するには、Outlookディレクトリでユーザーを検索する必要があります。 Outlook参照を追跡する必要があります。 複雑な環境では、結果が見つかる前に多数の NIC に接続される可能性があります。 ユーザー Outlook UPN を検出した後、値はプロファイルにキャッシュされ、このユーザーに対してルックアップが再度実行されることはありません。
このシナリオを回避するために、ユーザーは domain\username ではなく UPN を使用してログオンできます。
ITAR に関する考慮事項
Microsoft Office 365は、ITAR義務を持つ顧客をサポートできる機能を提供します。 Outlook の自動検出機能のコンテキストでは、この機能セットには、自動検出に使用されるサービス エンドポイントがソブリン クラウドの要件に準拠していることを保証するポリシー設定と動作が含まれています。 具体的には、自動検出プロセス (手順 4 と手順 11) に記載されている Office 365 固有の手順では、ポリシー制御を使用して、自動検出プロセス中に適切なサービス エンドポイントが使用されます。
自動検出プロセス Outlook自動検出情報が必要な場合は、一連の順序付けされた手順を使用して、構成設定を含む XML ペイロードを取得します。 これらの手順の多くは、グループ ポリシー オブジェクト (GPO) を使用して制御できます。GPO の値は手順の説明に含まれています。
手順 1: 再起動シナリオを確認する
Outlook の実行中に 2 つ目のアカウントを追加するなど、場合によっては、Outlook クライアントの再起動時に使用されるローカル ファイルに Autodiscover ペイロードがキャッシュされることがあります。 最初の自動検出の手順は、レジストリで、これらの再起動シナリオの途中にあると Outlook に指示する特別な "ブート" 情報を確認し、特殊なローカル ファイルから自動検出ペイロードを読み取る方法です。 これはまれな場合であり、通常は一般的な Autodiscover の問題の原因ではありません。 この手順で、この特殊なブート シナリオであり、Autodiscover XML データを取得する試行が失敗したと Outlook が判断した場合、Autodiscover の試行全体が失敗します。 以降の手順は試行されません。
この手順に対する特定のポリシー制御はありません。
手順 2: ローカル データの環境設定を確認する
Outlook、管理者が構成に使用する特定の自動検出 XML ファイルをデプロイできる GPO を提供します。 管理者がこのレジストリ値をデプロイし、autodiscover.xml ファイルをシード処理した場合Outlookファイルから自動検出ペイロードを読み取ります。 これは一般的なケースであり、通常は一般的な自動検出の問題の原因ではありません。 この手順でペイロードが取得されない場合は、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 Outlook確信を持って判断した場合は、既知の O365 エンドポイント (通常は https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml または https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml) から自動検出ペイロードを取得しようと試みられています。 この手順でペイロードが取得されない場合は、Outlook 5 に移動します。
この手順のポリシー制御値は次のとおりです。
ExcludeExplicitO365Endpoint。
ITAR に関する考慮事項
既定では、Outlookエンドポイントにクエリを実行して自動検出ペイロードを取得します。 この手順をバイパスする既存のポリシーは引き続き有効であり、エンドポイントを試さずに手順 5 に進むのに使用できます。 または、Outlook に対して中央の Office 365 Config Service にクエリを実行し、自動検出ペイロードを取得する適切な URL を取得する新しいポリシーがあります。 概念的には、このプロセスは次のように動作します。
-
新しいポリシーを設定します。
-
自動検出プロセスの手順 4 の間に、Outlook構成サービスOffice 365クエリを実行します。
-
サービスは、指定されたユーザーに対して有効な特別な ITAR ニーズ (該当する場合) を決定し、UPN のドメイン情報を使用して、そのユーザーに適した URL を返します。
-
Outlookサービスによって提供される URL から自動検出ペイロードを取得します。
新しい構成サービスを使用する新機能のポリシー制御Office 365 EnableOffice365ConfigService です。
注: ビルド16.0.9327.1000の現在 、EnableOffice365ConfigService ポリシーは使用されなくなりました。
手順 5: SCP データを確認する
コンピューターがドメインに参加している場合、Outlook LDAP クエリを実行して、自動検出 XML のパスを返すサービス接続ポイント データを取得します。 次に、SCP の検索から返された各 URL に対して、Autodiscover ペイロードの取得が試行されます。 この手順でペイロードが取得されない場合、Outlook は手順 6 に進みます。
SCP の詳細については、MSDN の記事「サービス接続ポイントを使用した発行」を参照してください。
この手順のポリシー制御値は 、ExcludeScpLookupです。
手順 6: ルート ドメインを確認する
この手順では、Outlook は https://<ドメイン>/autodiscover/autodiscover.xml の形式で初期アドレスのドメイン名から URL を構築し、結果の URL からペイロードの取得を試行します。 多くのルート ドメインは Autodiscover 用に構成されていないため、Outlook は、取得の試行中に発生した証明書エラーを意図的に表示しません。 この手順でペイロードが取得されない場合、Outlook は手順 7 に進みます。
この手順のポリシー制御値は 、ExcludeHttpsRootDomainです。
手順 7: 自動検出ドメインを確認する
この手順では、Outlook は https://autodiscover.<ドメイン>/autodiscover/autodiscover.xml の形式で初期アドレスのドメイン名から URL を構築し、結果の URL からペイロードの取得を試行します。 通常、これは Autodiscover データのプライマリ URL なので、Outlook は取得の試行中に発生した証明書エラーを非表示にしません。 この手順でペイロードが取得されない場合、Outlook は手順 8 に進みます。
この手順のポリシー制御値は 、ExcludeHttpsAutoDiscoverDomainです。
手順 8: ローカル データを確認する
手順 2 ではOutlookとして自動検出ペイロードを特にチェックするポリシーが管理者によってデプロイされているかどうかを確認しました。 ポリシーが設定されているのに、前の手順でペイロードを取得しなかった場合、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 がフェールセーフとして確認する
前のすべての手順でペイロードを返さなかった場合、Outlook は制限の少ないヒューリスティック セットを使用して、O365 エンドポイントに対する最終的な試行が役に立つかどうかを判断します。 Outlook は、試行の価値があると判断した場合、アカウントが O365 アカウントである場合に、既知の O365 自動検出エンドポイントを試します。 この試行では、手順 4 と同じターゲット URL が使用されます。これは、自動検出プロセスの前ではなく、最後の方法として試行されたという事実でのみ異なります。
この手順のポリシー制御値は 、ExcludeExplicitO365Endpoint です。
ITAR に関する考慮事項
このOutlookにアクセスし、Autodiscover ペイロードを正常に取得しなかった場合は、既知の Office 365 エンドポイントを試行するかどうかを確認する 2 つのテストが実行されます。 まず、メールボックスがコンシューマー アカウント (たとえば、outlook.com) の場合、既知のエンドポイントが試行されます。 次に、メールボックスが ITAR 要件を持っていないドメインに属すると判断された場合、既知のエンドポイントが試行されます。 メールボックスが商用と判断され、ITAR 要件を持つドメインに属している場合、既知のエンドポイントに対する試行Office 365されません。 今後のリリースでは、手順 11 は手順 4 と同じロジックに移行し、Config Service の 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 の場合Outlookは、プロトコルが https である場合に、新しい URL から自動検出 XML の取得を試みる必要があります。 セキュリティで保護されていない (http) URL は試行されません。 さらに、新しい URL のプロトコルが https の場合でも、Outlook は証明書情報をチェックして、セキュリティの追加の手段を提供します。
ケース 3 では、Outlookから自動検出プロセス全体が開始されます。 すべての手順 (1 ~ 11) が新しいメール アドレスを使用して成功せずに試行された場合、Outlook は元のメール アドレスに戻り、手順 5 に進み、元のアドレスを持つ XML ペイロードの取得を続行します。
例外 自動検出プロセス セクションの手順は、自動検出ペイロードを取得Outlook一般的なルールです。 プロセスを少し変更する可能性があるさまざまな最適化と例外的な試行があります。 たとえば、新しいアカウントの作成を行う場合、Outlook は最後の既知の良好なエントリをまだ持てないので、手順 3 (最後の既知の良好 (LKG) データを確認する) を内部的にスキップします。 同様に、現在の構成情報を使用してエラーが原因で試行がトリガーされた場合、Outlook は誤って再検出を行い、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 は、プロセス内のそのステップを有効にOutlook 1 セットの設定として、他のコントロール値とは異なります。 その他の値については、1 を設定すると、関連する手順が無効になるように、またはスキップされるように Outlook が設定されます。 たとえば、値 ExcludeHttpsRootDomain を 1 に設定すると、プロセス内の手順 6 を実行しないように Outlook が設定されます。
追加のレジストリ制御
Outlook、自動検出プロセスに影響を与える可能性がある追加のレジストリ ベースの構成オプションがいくつか提供されます。
構成サービスOffice 365使用する
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
値: EnableOffice365ConfigService
既定値: 0
データ: この DWORD データを 1 に設定して、Outlook Config Service を呼び出して適切Office 365自動検出 URL を取得する必要があります。
HTTP のタイムアウト設定
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
値: タイムアウト
既定値: 25 秒
最小: 10 秒
最大: 120 秒
情報: 指定されたタイムアウトは 、WinHttpSetTimeouts 設定として使用されます。 指定したデータは、WinHttpSetTimeouts API の 4 つのパラメーターすべてに渡されます。 これにより、到達できない HTTP 要求の時間が短縮され、全体的なパフォーマンスが向上する可能性があります。 また、この設定では、既定の 25 秒を超える時間がかかる HTTP 要求を、25 秒より大きい値に増やして成功を許可することもできます。
Mapi/Http プロトコル制御
キー: HKEY_CURRENT_USER\Software\Microsoft\Exchange
値: MapiHttpDisabled
既定値: 0
データ: 1 = Protocol is Disabled;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-Negotiate-Capability: Negotiate、pku2u、Kerberos、NTLM、MSOIDSSP" があります。 このレジストリ値と追加するヘッダーは、最新の認証スタックではめったに使用されません。また、負または肯定的な方法で tAodiscover プロセスに影響を与える可能性はほとんどありません。
証明書のエラー処理
キー: HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover
値: ShowCertErrors
既定値: 0
データ: 1 = 証明書の警告/エラーを表示します。0 = 証明書の警告を表示しない
情報: この値は、Outlook が HTTP タスクの実行時に受け取る証明書のエラーと警告を処理する方法を制御します。 Outlook では、この設定がオーバーライドされる場合があります ([自動検出プロセス] セクションの手順 6)、一般的なケースでは、この設定が有効になっている場合、Outlook は証明書のエラーまたは警告を表示するセキュリティ ダイアログを表示し、ユーザーが [OK] または [Http 要求を取り消す] を許可するように求めるメッセージを表示します。 ユーザーが無視して http 要求を再試行する必要がある特定の証明書Outlook次の 3 つがあります。
-
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 日」で詳しく説明されています。
他のプロトコルの自動検出
Outlook で機能として Autodiscover を使用し、Exchange ActiveSync (EAS) アカウントを検出して構成することもできます。 EAS の自動検出プロセスと意思決定は、この記事で説明する手順とは別です。 たとえば、EAS の実装では O365 エンドポイント ロジックが実装されておらず、SCP の場所を確認する手順はありません。 この記事では、OUTLOOK が MAPI ベースのプロトコルをOutlookして MAPI ベースのプロトコルを取得するために使用する詳細な手順について説明Exchange。
関連情報
自動検出に関する従来の情報については、Microsoft サポート技術情報の次の記事を参照してください。
2212902 \Autodiscover キーの下にレジストリ設定がある場合の予期しない自動検出動作
自動検出の詳細については、次の Microsoft 記事を参照してください。