This issue is most likely caused by Outlook's Autodiscover service, part of the Outlook Anywhere functionality. Autodiscover provides various information to the end-user's Outlook client on the various services offered by Exchange and where these can be located; this is used for a variety of purposes:
Autoconfiguration of Outlook profiles on first-run of Outlook, which can configure an Exchange account using only the user's email address and password, since the other information is automatically located and retrieved.
Dynamic location of web-based services accessed by the Outlook client, including the out-of-office assistant, Unified Messaging functionality, location of the Exchange Control Panel (ECP) and so forth.
This is Microsoft's proprietary implementation of RFC 6186. Unfortunately, they didn't really follow the recommendations of that RFC in Outlook Anywhere's design, but that is perhaps to be expected since Exchange and RPC over HTTPS functionality is not a traditional IMAP/SMTP server.
How does Autodiscover work (for external* users)?
Autodiscover communicates with a web service on a Client Access Server (in this case, all roles are on the SBS server) at the path /Autodiscover/Autodiscover.xml, rooted off its default web site. To locate the FQDN of the server to communicate with, it removes the user portion of the email address, leaving the domain (i.e. @companyB.com). It attempts to communicate with Autodiscover using each of the following URLs, in turn:
https://companyB.com/Autodiscover/Autodiscover.xmlhttps://autodiscover.companyB.com/Autodiscover/Autodiscover.xml
If these fail, it will attempt a non-secure connection by disabling SSL and attempting to communicate on port 80 (HTTP), typically after prompting the user to confirm this is an acceptable action (a flawed option in my opinion, since clueless users will typically approve this and risk sending credentials over plain text -- and clueless sysadmins who don't require secured communication of credentials and business-sensitive data are a risk to business continuity).
Finally, a follow-on check is made using a service record (SRV) in the DNS, which exists at a well-known location off the companyB.com namespace and can redirect Outlook to the proper URL where the server is listening.
What can go wrong?
One of several issues can arise in this process:
No DNS entries
Typically, the root of the domain (companyB.com) might not resolve to a host record in the DNS. Improper DNS configuration (or a conscious decision not to expose the Outlook Anywhere service) might mean the autodiscover.companyB.com record does not exist either.
In these cases, there is no major issue; Outlook simply continues to communicate with Exchange using the last known configuration, and may be degraded with respect to certain web-based functions for which it needs to retrieve URLs via Autodiscover (such as the out-of-office assistant). A workaround is to use Outlook Web Access to access such functions.
Automatic configuration of Exchange accounts in new Outlook profiles is also not automated, and requires manual configuration of the RPC over HTTPS settings. However, this will not cause the issue you describe.
Faulty SSL certificates
It is entirely possible that the URL Outlook uses to attempt to contact the Exchange Server resolves to a host, which may or may not be a Client Access Server. If Outlook can communicate with that server on port 443, certificates will of course be exchanged to set up a secure channel between Outlook and the remote server. If the URL Outlook believes it is talking to is not listed on that certificate -- be it as the common name or a subject alternative name (SAN) -- this will elicit Outlook to present the dialog you describe in your initial post.
This can happen for several reasons, all down to how DNS is configured and how the URLs I described above are checked by Outlook:
If the https://companyB.com/... URL resolves to a host record, and the web server at that address listens on port 443, and it has an SSL certificate which does not list companyB.com in the common name or Subject Alternative Name, then the issue will occur. It matters not whether the host is an Exchange Server or not; it might be a web server hosting a company website which is not properly configured. Corrige either:
- Disable the host record at the root of the
companyB.com zone (requiring visitors to the website or other service to enter www.companyB.com, or equivalent; or
- Disable access to the machine at
companyB.com on port 443, causing Outlook to reject the companyB.com URL before certificates are exchanged and move on; or
- Fix the certificate at
companyB.com to ensure companyB.com is listed on that certificate, and that attempts to visit https://companyB.com in a standard browser do not fail.
The above applies regardless of whether companyB.com resolves to the Exchange Server; if Outlook can communicate with it, it will later discover that the /Autodiscover/Autodiscover.xml path yields an HTTP 404 error (does not exist) and move on.
- If the
https://autodiscover.companyB.com/... URL resolves to the Exchange Server (or any other server) but, again, autodiscover.companyB.com is not listed as the common name or a subject alternative name, you will observe this behaviour. It can be fixed as above by fixing the certificate, or as you rightly indicate, you can use a SRV record to redirect Outlook to a URL which is listed on the certificate and which Outlook can communicate with.
Your probable fix to this issue
In this case, the typical fix is to do the latter; create SRV records in the new DNS provider to ensure Outlook is redirected to autodiscover.companyA.com, which (any other issues aside) will work successfully since it is listed on the certificate as a SAN. For this to work, you need to:
- Configure an
_autodiscover._tcp.companyB.com SRV record in accordance with the documentation.
- Delete the
autodiscover.companyB.com host record, if it exists, to prevent Outlook resolving this and attempting to reach Autodiscover in that way.
- Also resolve any issues with HTTPS access to
https://companyB.com as above, since Outlook will enumerate the URLs derived from the user's email address before falling over to the SRV record approach.
*How does Autodiscover work (for internal, domain-joined clients)?
I add this merely for completeness, as it is another common reason for these certificate prompts to occur.
On a domain-joined client, when it is local to the Exchange environment (i.e. on the internal LAN), the above techniques are not used. Instead, Outlook communicates directly with a Service Connection Point in Active Directory (listed in Exchange Client Access settings), which lists the URL where Outlook can locate the Autodiscover service.
It is common for certificate warnings to occur in these circumstances, because:
- The default URL configured for this purpose refers to the internal URL of Exchange, which is often dissimilar from the public URL.
- SSL certificates may not list the internal URL on them. At present, yours does, but this may become an issue in the future for Active Directory domains which use
.local and similar non-global gTLD domain name suffixes, since a decision by ICANN prohibits SSL certificates for such domains being issued post-2016.
- The internal address might not resolve to the proper server.
In this case, the matter is resolved by correcting the recorded URL to refer to the proper, external address (listed in the certificate), by running the Set-ClientAccessServer cmdlet with the -AutodiscoverServiceInternalUri switch. Parties doing this typically also configure split-horizon DNS, either because they are required to do so by their network configuration and/or for continuity of resolution in the event of an upstream resolver/connection outage.
