Outlook 2016検出の実装

Autodiscover のタイミング

Autodiscover は次の時間に実行されます。

1. アカウントの作成時。

2. 設定された間隔で、Exchange Web サービス機能 (OOF、空き時間情報サービスなど) を提供する URL の変更を収集します。 このプロセスに成功すると、1 時間後に次の試行が実行されます。 試行に成功しなかった場合、次の試行は 5 分後に行います。 すべてのアプリケーションで使用されるバックグラウンド タスク インフラストラクチャにより、各試行を 25% Microsoft Office可能性があります。

3. 特定の接続エラーに応答したとき。 さまざまなシナリオで、接続の試行に失敗すると、接続の問題を修正するために、Outlook で新しい設定を取得する Autodiscover タスクが開始されます。

4. 別のアプリケーションが 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 の値は手順の説明に含まれています。

[自動検出プロセス] セクションのリダイレクト処理手順 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。