この問題は、Outlook Anywhere機能の一部であるOutlookの自動検出サービスが原因である可能性があります。自動検出は、Exchangeが提供するさまざまなサービスとそれらの場所にあるエンドユーザーのOutlookクライアントにさまざまな情報を提供します。これはさまざまな目的に使用されます。
これは、Microsoft独自のRFC 6186の実装です。残念ながら、Outlook Anywhereの設計ではそのRFCの推奨事項に実際に従わなかったが、ExchangeおよびRPC over HTTPS機能は従来のIMAP / SMTPサーバーではないため、おそらく予想されることです。
自動検出はどのように機能しますか（外部*ユーザー向け）？
自動検出は/Autodiscover/Autodiscover.xml、既定のWebサイトをルートとするパスで、クライアントアクセスサーバー（この場合、すべての役割がSBSサーバー上にある）上のWebサービスと通信します。通信するサーバーのFQDNを見つけるために、メールアドレスのユーザー部分を削除し、ドメイン（@ companyB.com）を残します。次の各URLを順に使用して、自動検出との通信を試みます。
https://companyB.com/Autodiscover/Autodiscover.xmlhttps://autodiscover.companyB.com/Autodiscover/Autodiscover.xml
これらが失敗した場合、SSLを無効にしてポート80（HTTP）で通信を試みることにより、通常はこれが受け入れ可能なアクションであることを確認するように求めた後、非セキュアな接続を試みます（無知なユーザーは通常、これを承認し、プレーンテキストで資格情報を送信するリスクがあります。資格情報とビジネスに依存するデータの安全な通信を必要としない無知なシステム管理者は、ビジネス継続性のリスクです。
最後に、DNSのサービスレコード（SRV）を使用して後続チェックが行われます。SRVは、companyB.comネームスペースから離れた既知の場所に存在し、サーバーがリッスンしている適切なURLにOutlookをリダイレクトできます。
何がうまくいかないのでしょうか？
このプロセスでは、いくつかの問題の1つが発生する可能性があります。
DNSエントリなし
通常、ドメインのルート（companyB.com）はDNSのホストレコードに解決されない場合があります。不適切なDNS構成（またはOutlook Anywhereサービスを公開しないという意識的な決定）は、autodiscover.companyB.comレコードも存在しないことを意味する場合があります。
これらの場合、大きな問題はありません。Outlookは、最後の既知の構成を使用してExchangeと通信し続けるだけであり、自動検出（不在時のアシスタントなど）を介してURLを取得する必要がある特定のWebベースの機能に関して低下する場合があります。回避策は、Outlook Web Accessを使用してこのような機能にアクセスすることです。
新しいOutlookプロファイルでのExchangeアカウントの自動構成も自動化されていないため、RPC over HTTPS設定を手動で構成する必要があります。ただし、これにより、説明した問題は発生しません。
不完全なSSL証明書
OutlookがExchange Serverへの接続を試みるために使用するURLは、クライアントアクセスサーバーである場合とそうでない場合があるホストに解決される可能性があります。Outlookがポート443でそのサーバーと通信できる場合、証明書はもちろん、Outlookとリモートサーバー間の安全なチャネルをセットアップするために交換されます。Outlookが通信しているとURLがその証明書に記載されていない場合（一般名またはサブジェクトの別名（SAN）として）、これによりOutlookは最初の投稿で説明するダイアログを表示します。
これはいくつかの理由で発生する可能性があります。すべてDNSの構成方法と、上記で説明したURLがOutlookによってチェックされる方法に至るまでです。
場合はhttps://companyB.com/ホストレコードへ... URLの解決さ、およびポート443上のアドレスをリッスンで、Webサーバ、およびそれがないSSL証明書持っていないリストをcompanyB.com共通名またはサブジェクトの別名にし、その後、問題が発生します。ホストがExchange Serverであるかどうかは関係ありません。適切に設定されていない会社のWebサイトをホストしているWebサーバーである可能性があります。次のいずれかを修正します。
companyB.comゾーンのルートでホストレコードを無効にします（Webサイトまたは他のサービスへの訪問者にwww.companyB.com、または同等の入力を要求します; またはcompanyB.comポート443でマシンへのアクセスを無効にします。これにより、companyB.com証明書が交換されて先に進む前にOutlookがURL を拒否します。または- で証明書を修正して、その証明書にリストされていること
companyB.comを確認し、標準ブラウザでcompanyB.comアクセスしようとしてhttps://companyB.comも失敗しないようにします。
上記はcompanyB.com、Exchange Serverに解決されるかどうかに関係なく適用されます。Outlookが通信できる場合、/Autodiscover/Autodiscover.xmlパスがHTTP 404エラーを生成する（存在しない）ことを後で発見し、先に進みます。
場合https://autodiscover.companyB.com/Exchange Serverの（または任意の他のサーバ）へ... URLの解決さしかし、再び、autodiscover.companyB.com共通名またはサブジェクトの別名としてリストされていない、あなたは、この動作を観察します。これは、証明書を固定することにより、上記のように固定することができる、またはあなたが正しく示すように、使用することができるSRVレコードを URLにOutlookをリダイレクトするようにされている証明書に記載されているとOutlookがどのことができると通信します。
この問題に対する修正案
この場合、典型的な修正は後者を行うことです。新しいDNSプロバイダーでSRVレコードを作成し、Outlookがにリダイレクトされるようにします。autodiscover.companyA.comこれは、証明書にSANとしてリストされているため、正常に機能します。これが機能するには、次のことが必要です。
- ドキュメント
_autodiscover._tcp.companyB.comに従ってSRVレコードを構成します。
autodiscover.companyB.comホストレコードが存在する場合は削除して、Outlookがこれを解決し、その方法で自動検出に到達しようとするのを防ぎます。- また
https://companyB.com、OutlookはSRVレコードアプローチに移行する前にユーザーのメールアドレスから派生したURLを列挙するため、上記へのHTTPSアクセスの問題も解決します。
*自動検出はどのように機能しますか（ドメインに参加している内部クライアントの場合）？
これらの証明書のプロンプトが発生するもう1つの一般的な理由であるため、これを完全性のために追加します。
ドメインに参加しているクライアントでは、Exchange環境に対してローカル（つまり、内部LAN上）にある場合、上記の手法は使用されません。代わりに、OutlookはActive Directoryのサービス接続ポイント（Exchangeクライアントアクセス設定に一覧表示されます）と直接通信します。これは、Outlookが自動検出サービスを見つけることができるURLを一覧表示します。
これらの状況で証明書の警告が発生するのは一般的です。理由は次のとおりです。
- この目的のために設定されたデフォルトのURL は、Exchange の内部 URLを参照します。これは多くの場合、パブリックURLとは異なります。
- SSL証明書には、内部URLがリストされていない場合があります。現在、あなたのものはありますが、これは、ICANNの決定により 2016年以降に発行されるそのようなドメインのSSL証明書が禁止されているため
.local、同様の非グローバルgTLDドメイン名サフィックスを使用するActive Directoryドメインで将来問題になる可能性があります。
- 内部アドレスが適切なサーバーに解決されない場合があります。
この場合、問題を解決するには、記録されたURLを修正して、適切な外部アドレス（証明書にリストされている）を参照Set-ClientAccessServerし、-AutodiscoverServiceInternalUriスイッチでコマンドレットを実行します。通常、これを行う締約国は、スプリットホライズンDNSも構成します。これは、ネットワーク構成によって、またはアップストリームリゾルバー/接続が停止した場合に解決を継続するために、そうする必要があるためです。