Community Pick: Many members of our community have endorsed this article.

Troubleshooting Outlook Certificate Errors

endital1097Customer Engineer
Published:

Introduction

A common issue after installing Exchange 2007 or 2010 users get certificate errors when connecting opening Outlook to access their mailboxes. There are a few possible reasons for this issue: 1) the certificate does not have the appropriate subject names; 2) missing DNS records; or 3) Exchange settings are not configured correctly.

Troubleshooting steps

The first step is to collect configuration information from your environment. You need to determine the subject names configured on your certificate and compare these values to the FQDN values assigned to your URLs.

Get the subject names configured on the certificate assigned to the Exchange server
Get-ExchangeCertificate | where { $_.Services.ToString().Contains(“IIS”) –eq $true } | fl Cert*

Open in new window


Get the service connection point URL used by Outlook to locate the Autodiscover service
Get-ClientAccessServer CasServerName | fl AutoDiscoverServiceInternalUri

Open in new window


Get the Exchange Web Services URL values
Get-WebServicesVirtualDirectory | fl *Url

Open in new window


Get the Offline Address Book URL values
Get-OabVirtualDirectory | fl *Url

Open in new window


Get the Autodiscover URL values
Get-AutodiscoverVirtualDirectory | fl *Url

Open in new window


Get the Outlook Anywhere FQDN
Get-OutlookAnywhere | fl External*

Open in new window


Here is an example of results:
CertificateDomains :             {mail.contoso.com, autodiscover.contoso.com}
                      AutoDiscoverServiceInternalUri : https://mail.contoso.com/Autodiscover/Autodiscover.xml
                      InternalUrl :                    https://mail.contoso.com/EWS/Exchange.asmx
                      ExternalUrl :                    https://mail.contoso.com/EWS/Exchange.asmx
                      InternalUrl :                    http://mail.contoso.com/OAB
                      ExternalUrl :                    https://mail.contoso.com/OAB
                      InternalUrl :
                      ExternalUrl :
                      ExternalHostname :               mail.contoso.com

Open in new window


Note: The Autodiscover virtual directory results can be empty

If you need to update any of the Exchange settings you can run the following:
Set-ClientAccessServer CasSrv AutoDiscoverServiceInternalUri 
                      Set- WebServicesVirtualDirectory CasSrv\ews* -ExternalUrl –InternalUrl
                      Set- OabVirtualDirectory CasSrv\oab* -ExternalUrl –InternalUrl

Open in new window


Note: After each ExternalUrl and InternalUrl you need to include the appropriate URL value, use the format from your Get cmdlets as a guideline.

Next you need to verify your DNS records both internally and externally. There must be an A record on your internal DNS server for the FQDN value used in all of the InternalUrl values, the AutoDiscoverServiceInternalUri, and the ExternalHostname. You can use the nslookup utility to validate (nslookup autodiscover.contoso.com).

Your external DNS server records are dependent on your certificate domain names. Typically your certificate should include autodiscover.yourdomain.com and you should have an associated A record. If your certificate does not include autodiscover.yourdomain.com, then your DNS server must support SRV records. The SRV record should then be configured as follows:
Service = _autodiscover
                      Protocol = _tcp
                      Port = 443
                      Hostname = (a certificate domain name value = existing A record)

Open in new window


There are several web sites you can use to verify your external DNS records (http://www.dnsquery.org/).

Verification

Once your configuration is complete you can test your system externally using https://testexchangeconnectivity.com/
Test Remote Connectivity
You can test your system internally by opening Outlook, then using the combination of Right Ctrl and Right-click on the Outlook icon in the taskbar, and select Test E-mail AutoConfiguration. Your e-mail address should auto-populate. Remove the Guessmart options and press Test.
 Outlook Test E-Mail AutoConfiguration
3
13,402 Views
endital1097Customer Engineer

Comments (13)

Doug ManleyIT Director

Commented:
Oops, please disregard the previous comment. I was using the local admin instead of network admin credentials. I think it's time to go home...
Doug ManleyIT Director

Commented:
When I try to get the service connection point URL for the Autodiscover service, it comes back with nothing (literally nothing, it just goes to the next prompt). So I'm not quite sure what my next step should be. Would I just run...

Set-ClientAccessServer CasServerName | fl https://mail.domain.com/Autodisver/Autodiscover.xml

The only reason I ask is because this is a production server (though it is after-hours here), and I'm new to the organization, so I'm still famliarizing myself with the network layout, and I'm not sure if it's safe to assume that is the correct location.

Also, the issues I'm having related to free/busy information not being available via Outlook unless the OWA is used. I know this may be related to EWS, but I'm not sure if EWS specifically needs added to the SSL cert. Should I be seeing it in the list of Certificate Domains?

Thank you kindly for any assistance you may be able to provide. Your article was already quite helpful, so I very much appreciate the time you put into it.
Doug ManleyIT Director

Commented:
P.S. (Sorry, it doesn't look like I can edit a comment.) I should specify that the free/busy information is only un-available for resources and only through the Outlook client. Free/busy information for regular users displays just fine, which makes it all the more puzzling.
endital1097Customer Engineer

Author

Commented:
To get the SCP you run Get-ClientAccessServer
Your comment shows a Set-* cmdlet which should be
Set-ClientAccessServer CasServerName -AutoDiscoverServiceInternalUri https://CasFqdn.domain.com/Autodiscover/Autodiscover.xml

the CasFqdn.domain.com can be an Fqdn as long as it either resolves to the Cas server or a load balanced IP
Doug ManleyIT Director

Commented:
It turns out, my specific issue is only if the user isn't joined to the domain. They can view everyone else's calendars but not the calendars of resources (unless they're using Citrix or the OWA). Should I start a new topic on the issue?

View More

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.