The official blog for Windows Server Essentials and Small Business Server support and product group communications.
[Today’s post comes to us courtesy of Shawn Sullivan]
An issue experienced by our customers from time to time is when Outlook 2007 generates a certificate name mismatch error while trying to connect to SBS 2008. This is almost always caused by a configuration error in either public or private DNS where the wrong records are present for the type of certificate you have, or the records point to some other destination IP. The purpose of this post is to provide a few steps to help you resolve the issue.
A couple rules to follow when configuring DNS when it comes to Autodiscover and SBS:
Note: In SBS 2008, the IAMW creates a zone for the public name of your domain in internal DNS along with a Host A record that points to the server’s internal IP. Unless you are hosting your own public DNS records, there should be no other public name records on the server itself.
Note: If you choose to allow a partner registrar to manage your domain for you during the IAMW, then the necessary DNS records, including the SRV record, will be created and updated for you automatically. More information on this process can be found in part 2 and 3 of our IAMW blog post.
Straying from these rules can cause the following scenarios to occur.
SCENARIO 1: You incorrectly have an Autodiscover Host A record registered and you are using the SBS certificate generated by the Internet Management Address Wizard (IAMW) when configuring your domain manually. This certificate does not support the use of an Autodiscover Host A record since does not register Autodiscover as a Subject Alternative Name. If the A record points to the public IP address of the SBS server, the domain name and suffix will match while the prefix will not match.
To resolve this, register a public SRV record that points the Autodiscover service to the public fully qualified domain name that you chose for your server during the IAMW. You can use KB 940881 as a guide to creating this record. Remove any Autodiscover Host A record that you have configured in either private or public DNS and/or verify that a wildcard record is not registered for your domain.
You can use nslookup to verify the SRV record for your domain:
> set type=srv > _autodiscover._tcp.contoso.com
_autodiscover._tcp.contoso.com SRV service location: priority = 1 weight = 10 port = 443 svr hostname = remote.contoso.com remote.contoso.com internet address =x.x.x.x
SCENARIO 2: You have installed a trusted certificate on the SBS server that supports the use of an Autodiscover A record, such as a Unified Communications or wildcard certificate. You have an Autodiscover A record registered for the domain, but it points to the wrong public IP. If the server at that IP is publishing an SSL site, you will receive a certificate warning:
Clicking “View Certificate” reveals that this is a completely different certificate than what is installed on the SBS server.
To resolve this, you need to update the host A record to point to the correct IP. You can launch nslookup from any machine that can query both external and internal DNS to check the IP address that the autodiscover record points to:
Name: autodiscover.contoso.com Address: x.x.x.x
You should query both the SBS server and an external forwarder to and compare the results; it is possible that the public zone is registered in both places. Also make sure there is no conflicting wildcard record registered for you domain.
SCENARIO 3: This scenario can occur internally with domain joined clients. A problem communicating with the Autodiscover virtual directory on the SBS 2008 server causes the client to seek the service elsewhere using DNS, where the above two scenarios can then occur.
The client initially queries Active Directory and retrieves the proper URL, but there is a communication problem with the directory itself. A recent example experienced by a customer occurred when the Autodiscover virtual directory was incorrectly configured to require client certificates during authentication, triggering the failure. The client then resolved an Autodiscover record on the internet that should not have been registered, and they received the mismatch error.
Resolving the DNS configuration in this scenario is the same as in the above scenarios. Fixing the communication problem with the virtual directory will involve troubleshooting both IIS and Exchange to varying degrees of depth and may require the help of Microsoft Product Support Services.
One tool that you can use is the “Test E-mail AutoConfiguration” feature that is built into Outlook 2007. It will generate a debug log of each connection attempt and the result. To access it, right-click the Outlook icon in your notification area (it will only launch if you have an Outlook profile configured already).
Using this log, we can see exactly how Outlook attempts to locate and connect to the Autodiscover URL. In the example specified above, the correct URL that Outlook found in Active Directory returned 0x80072F0C (ERROR_INTERNET_CLIENT_AUTH_CERT_NEEDED). Then it failed back to check domain.com and autodiscover.domain.com for the service using SSL, which is where the certificate warning was received because an Autodiscover Host A record was registered publicly:
I have found that the problem comes when SBS users want to make use of autodiscover from outside the LAN. Some DNS providers will not create SRV records and so autodiscover becomes the only option for these users.
UC certificates these days are reasonably priced and seems to me to be one of the best and most convenient way to configure Exchange in an SBS environment.
I believe wildcard certificates can cause issues with some mobile devices.
I'm wondering if my issue below is related to your article above?
I had Small Business Server 2008 setup with a self signed cert. Everything
was working, 3 Blackberry Internet Service (BIS) users connecting and working fine. The client wanted a
public cert so we bought the cert and replaced the self signed cert with the
public cert. Now none of the BIS users can connect. The 2 ActiveSync users
are not having any issues before or after.
The URL is https://remote.domain.com/owa but when put in IE the browser
changes it to
I put the connection info for each user into BIS manually but it says it
cannot connect. Perhaps the BIS interface is having an issue with the URL
above? Nothing in this document helps either:
As a last resort are there instructions for going back to a self signed