<

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x

Troubleshooting Outlook Certificate Errors

Published on
31,440 Points
12,640 Views
3 Endorsements
Last Modified:
Approved
Community Pick

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
Author:endital1097
  • 6
  • 4
  • 3
13 Comments

Expert Comment

by:dndally
Using testexchangeconnectivity.com, it returns this error when attempting to retrieve XML AutoDiscover response from url autodiscover.mydomain.com/AutoDiscover/AutoDiscover.xml.  To reconfirm, I do have a valid SAN cert with all of the necessary names.

Error: A Web Exception occurred because an HTTP 401 - Unauthorized response was received from Unknown
0

Expert Comment

by:dndally
Even though I get the error that I referred to in my last comment, I think I have resolved the issue.  Originally, the external URL was an alias which was in the SAN cert and had a valid public IP address that NATd to the correct CAS.  I went ahead and changed the external URL to the real FQDN, for which we also have in the SAN cert and had a valid public IP address. Now I am able to see free/busy information through Outlook Anywhere connections.

But, at the same time, I also added the local IP addresses for port 443 to the iplisten table in IIS.  However, I don't think this had an impact considering I was able to access OWA over 443 before making this change, but I figured it was worth mentioning.

I'm going to test out a few more clients to make sure it wasn't a fluke.  I will also role back the changes I made to see if it breaks again, this way I can confirm what actually resolved the issue.
0
LVL 32

Author Comment

by:endital1097
the HTTP 401 error is a permissions error most likely due to the authentication settings on the Autodiscover vdir, ensure that Anonymous, Basic, and Windows Integrated is enabled
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Expert Comment

by:dndally
Permissions look intact, with the exception of Anonymous being enabled.  I went ahead and enabled Anonymous and now I get a 403 error from the testexchangeconnectivity.com site.

An HTTP 403 forbidden response was received. The response appears to have come from Unknown. Body is: You do not have permission to view this directory or page.

Here are the permissions of the autodiscover vdir:

Name                          : Autodiscover (Default Web Site)
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated}
BasicAuthentication           : True
DigestAuthentication          : False
WindowsAuthentication         : True
0

Expert Comment

by:dndally
IGNORE 401 AND 403 ERRORS

The test account I was using was locked out.  After unlocking the account everything passed with autodiscover using testexchangeconnectivity.com.
0

Expert Comment

by:1919ITSupport
I assume these commands are supposed to be input in the Exchange Shell; correct? When I enter the first command, I get the following error:

'Get-ExchangeCertificate' is not recognized as the name of the cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:24
+ Get-ExchangeCertificate <<<<
      +Category Info                  : ObjectNotFound: (Get-ExchangeCertificate:String)
      [ ],  ComandNotFoundException
      + FullyQualifiedErrorId : CommandNotFoundException
0
LVL 32

Author Comment

by:endital1097
Yes, these commands are used in the EMS
If you are running Exchange 2010, you will need to ensure that the account you are logged in with has the appropriate permissions thru RBAC
The easiest way to determine if it does is to type Get-ExchangeC<Tab key> and it will autocomplete the cmdlet
0

Expert Comment

by:1919ITSupport
It very well may be an account permissions issues since the specific admin account I was using was just recently set up and still isn't completely configured correctly.

Anyway, I used the primary admin account, and as soon as I open the the shell, I get the following errors:

ss1
ss2
Any advice?
0

Expert Comment

by:1919ITSupport
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...
0

Expert Comment

by:1919ITSupport
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.
0

Expert Comment

by:1919ITSupport
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.
0
LVL 32

Author Comment

by:endital1097
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
0

Expert Comment

by:1919ITSupport
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?
0

Featured Post

Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

how to add IIS SMTP to handle application/Scanner relays into office 365.
In this video I will demonstrate how to set up Nine, which I now consider the best alternative email app to Touchdown.

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month