此问题很可能是由Outlook的自动发现服务引起的，该服务是Outlook Anywhere功能的一部分。自动发现向最终用户的Outlook客户端提供有关Exchange提供的各种服务以及这些服务可以位于何处的各种信息；这用于多种目的：
这是Microsoft的RFC 6186专有实现。不幸的是，他们在Outlook Anywhere的设计中并未真正遵循该RFC的建议，但这可能是可以预期的，因为Exchange和RPC over HTTPS功能不是传统的IMAP / SMTP服务器。
自动发现如何工作（对于外部*用户）？
自动发现与客户端访问服务器上的Web服务（在本例中，所有角色都在SBS服务器上）进行通信，该路径/Autodiscover/Autodiscover.xml从其默认网站开始。要找到要与之通信的服务器的FQDN，它将删除电子邮件地址的用户部分，并离开域（即@ companyB.com）。它尝试依次使用以下每个URL与自动发现进行通信：
https://companyB.com/Autodiscover/Autodiscover.xmlhttps://autodiscover.companyB.com/Autodiscover/Autodiscover.xml
如果这些操作失败，它将通过禁用SSL并尝试在端口80（HTTP）上进行通信来尝试进行非安全连接，通常是在提示用户确认这是可接受的操作之后（我认为这是一个错误的选择，因为无知的用户会通常会批准此操作，并冒着通过纯文本发送凭据的风险-不需要凭据和业务敏感数据的安全通信的笨拙的系统管理员会对业务连续性造成威胁）。
最后，使用DNS中的服务记录（SRV）进行后续检查，该记录位于companyB.com名称空间外的知名位置，并且可以将Outlook重定向到服务器正在侦听的正确URL。
有什么问题吗？
在此过程中可能会出现以下几个问题之一：
没有DNS条目
通常，域（companyB.com）的根可能无法解析为DNS中的主机记录。DNS配置不正确（或有意识地决定不公开Outlook Anywhere服务）可能意味着该autodiscover.companyB.com记录也不存在。
在这种情况下，没有重大问题；Outlook仅使用最新的已知配置继续与Exchange通信，并且可能会因某些基于Web的功能而降级，而Outlook需要通过Autodiscover（如办公室外助手）来检索URL。解决方法是使用Outlook Web Access访问此类功能。
在新的Outlook配置文件中自动配置Exchange帐户也不是自动的，并且需要手动配置RPC over HTTPS设置。但是，这不会引起您描述的问题。
错误的SSL证书
Outlook很有可能使用URL尝试联系Exchange Server解析为主机，该主机可能是也可能不是客户端访问服务器。如果Outlook可以在端口443上与该服务器通信，则当然将交换证书以在Outlook和远程服务器之间建立安全通道。如果Outlook认为正在与之交谈的URL不在该证书上列出（可以是通用名称或主题备用名称（SAN）），这将促使Outlook呈现您在初始帖子中描述的对话框。
发生这种情况可能有多种原因，其中包括DNS的配置方式以及Outlook如何检查上述URL：
如果https://companyB.com/... URL解析为主机记录，并且该地址的Web服务器在端口443上侦听，并且它的SSL证书未companyB.com在公用名或主题备用名中列出，则将发生此问题。主机是否为Exchange Server无关紧要；可能是托管未正确配置公司网站的Web服务器。纠正以下任何一种情况：
- 禁用
companyB.com区域根目录中的主机记录（要求访问网站或其他服务的访问者输入www.companyB.com，或等价物；或
- 禁用
companyB.com对端口443上的计算机的访问，从而导致Outlook companyB.com在交换证书并继续操作之前拒绝URL。要么
- 将证书固定在，
companyB.com以确保companyB.com在该证书上列出该证书，并且尝试https://companyB.com在标准浏览器中进行访问不会失败。
无论是否companyB.com解析到Exchange Server，以上内容均适用。如果Outlook可以与之通信，则以后它将发现该/Autodiscover/Autodiscover.xml路径产生HTTP 404错误（不存在）并继续前进。
如果https://autodiscover.companyB.com/... URL解析为Exchange Server（或任何其他服务器），但是再次autodiscover.companyB.com没有列出为公用名或使用者替代名，则您会观察到此行为。它可以通过固定证书被固定如上，或为你正确地表示，则可以使用一个SRV记录到Outlook重定向到其中URL 是列出的证书上并观可以与之通信。
您可能解决的此问题
在这种情况下，典型的解决方法是执行后者；在新的DNS提供程序中创建SRV记录，以确保将Outlook重定向到autodiscover.companyA.com，因为Outlook （在证书上列为SAN）会成功运行（除其他问题外）。为此，您需要：
_autodiscover._tcp.companyB.com根据文档配置SRV记录。- 删除
autodiscover.companyB.com主机记录（如果存在），以防止Outlook解决此问题并尝试以这种方式到达自动发现。
- 还要解决与
https://companyB.com上述HTTPS访问有关的任何问题，因为Outlook 在使用SRV记录方法之前会枚举从用户的电子邮件地址派生的URL 。
*自动发现如何工作（对于内部加入域的客户端）？
我之所以添加它只是为了完整性，因为这是这些证书提示出现的另一个常见原因。
在加入域的客户端上，当它在Exchange环境本地时（即在内部LAN上），则不使用上述技术。而是，Outlook与Active Directory中的服务连接点直接通信（在Exchange客户端访问设置中列出），该目录列出了Outlook可以在其中找到自动发现服务的URL。
在这些情况下，通常会发生证书警告，因为：
- 为此目的配置的默认URL是指Exchange 的内部 URL，它通常与公共URL不同。
- SSL证书可能不会在其上列出内部URL。目前您是这样做的，但是对于使用
.local和类似的非全局gTLD域名后缀的Active Directory域，将来可能会成为一个问题，因为ICANN决定禁止在2016年之后为此类域颁发SSL证书。
- 内部地址可能无法解析为正确的服务器。
在这种情况下，通过Set-ClientAccessServer使用-AutodiscoverServiceInternalUri开关运行cmdlet，可以通过更正记录的URL以引用正确的外部地址（证书中列出）来解决此问题。这样做的各方通常还会配置水平分割DNS，这是因为它们的网络配置要求它们这样做和/或在上游解析器/连接中断的情况下为了保持解析的连续性。