See through Autodiscover

Published:
I find myself explaining the whole process of autodiscover so many times that I decided to write this down and share it for further reference.

Outlook relies on Autodiscover to retrieve a bunch of URLs and the user’s mailbox Server. To get that information, Outlook needs to find an .xml file called (surprise!) Autodiscover.xml.
 
If Outlook cannot find that file, then users will still be able to send/receive emails but will not be able to use the following features:
 
The Availability service >free / busy is not showing when scheduling a new appointment
Out-of-Office Assistant > not able to set OOF (fails with a “very” descriptive error – the server is currently unavailable. Try again later)
Download of the Offline Address Book
Access to the Online Archive
Outlook profile cannot be configured automatically
If the user is moved from one server to another server, autodiscover service will automatically detect and connect to new server and update the outlook profile. Think about DAG
If you are in any of the situations above you just need to find out why Outlook cannot “find” that Autodiscover.xml file.

Where is the Outlook client? (The answer of this question will solve 50% of your issue)

a)Internal (Domain joined machine)
  Internal Autodiscover
 b)External (Outlook Anywhere)
external Autodiscover

For Internal (Domain joined machine)


Outlook is looking for the Autodiscover.xml by querying the AD for a specific object (SCP) under :

CN=YourServer,CN=Autodiscover,CN=Protocols,CN=YourServer,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=YourOrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain,DC=com
 SCP
Here Outlook finds the URL from where it can download the Autodiscover.xml
(https://YourCasServer.domain.com/Autodiscover/Autodiscover.xml)

The same information you can see in Exchange management shell :
>Get-ClientAccessServer | fl *uri AutodiscoverInternalURI  
Now if you open IIS management console you will find a virtual directory called Autodiscover and the URL above is just pointing to it! Autodiscover virtual dir
To troubleshoot what is going on from the client side click Test –E-mail AutoConfiguration :
(Press the Ctrl key with a right mouse click on the Outlook icon in lower right corner next to the clock)Click Test AutoConfiguration  
You will see that Outlook is trying to access the above mentioned URL. If for some reason it fails (Proxy settings, Network issue, Blocked 443 port, DNS issue ... etc.), then obviously your autodiscover is not working.

In your client browser, enter the above URL(https://YourCasServer.domain.com/Autodiscover/Autodiscover.xml) and after a credential prompt you should receive an error 600 if everything is OK

From the server side, the following cmdlets are your best friend:
>Test-ServiceHealth
All required services should be running

> Test-OutlookWebServices affected.user@domain.com |fl  
Would give you a descriptive error if any

For External (Outlook Anywhere)

When Outlook is not on a domain joined machine and therefore cannot query the AD then it is hard coded to search for a DNS A record which will point to an internet facing CAS server.
 
Let say your email address is user@domain.com
Outlook is taking the part after the @  i.e >>>domain.com

Then it tries the following to retrieve his .xml file. Step by step in the following order (simplified):

1

https://domain.com/Autodiscover/Autodiscover.xml

2

https://autodiscover.domain.com/Autodiscover/Autodiscover.xml

3

Looks for an SRV record pointing to another name which is trusted in certificate (I write about SSL certificate a bit later) http://support.microsoft.com/kb/940881
Usually the first step will fail because domain.com A record is pointing to the company’s web site.
Then Outlook tries autodiscover.domain.com which hopefully points to the CAS server

Using the wonderful MS tool on https://www.testexchangeconnectivity.com/ you can examine which step (exactly) is failing the whole process.

Again remember we are talking here simply about retrieving the autodiscover.xml file which provides some necessaries URLs.

When creating a new profile in Outlook you can very well configure manually all the server addresses without relying on Outlook looking for a SCP in AD or an external DNS A record. However in that case Outlook won’t necessary find the famous .xml file and therefore it won’t be able to use features like OOF … etc. But still mailflow will work!

Inside the Autodicover.xml file and SSL certificate

We can see the URLs that Outlook uses when it finally gets the Autodiscover.xml file. Again click Test –E-mail AutoConfiguration on Outlook or use > Test-OutlookWebServices affected.user@domain.com |fl on the server
 Result Test AutoConfiguration
From the exchange management shell inspect the URLs set on you virtual directories:
>Get-WebServicesVirtualDirectory | fl *url  
>Get- OABVirtualDirectory | fl *url  

If there is a need to be changed, set the internal and external URLs like this :
>Set-WebServicesVirtualDirectory -ServerName\*  –InternalUrl “https://internal.domain.local/EWS/Exchange.asmx” –ExternalURl “https://external.domain.com/EWS/Exchange.asmx
>Set- OABVirtualDirectory -ServerName\*  –InternalUrl “https://internal.domain.local/OAB” –ExternalURl “https://external.domain.com/OAB

Here comes the most common issue > SSL certificate. There is a simple rule, while inspecting the URLs on your virtual directories, ALL of them should appear in your SAN certificate.

So taking the above example: internal.domain.local and external.domain.com should be there. Also the autodiscover.domain.com should be in the certificate for external clients.

The main difference between internal and external clients is that domain joined machines will just give you a pop-up warning when the name is not OK ("The name of the security certificate is invalid or does not match the name of the site") or the certificate chain is not trusted.  However external clients (Outlook Anywhere) will simply not able to connect until you sorted out your certificate.

Here are some useful links on how to configure an internal certificate authority and how to use the exchange 2010 wizard to generate a certificate request. Also setting a split DNS for simplifying names in your certificate is a good idea as well.

*Split DNS = create an internal DNS zone with the same name as your external (ExternalName.com) and pointing an A record (for example “mail”) to your local IP address of exchange CAS
> http://exchangemaster.wordpress.com/tag/split-dns/

* SSL cert generation
> http://exchangeserverpro.com/configure-an-ssl-certificate-for-exchange-server-2010
> http://exchangeserverpro.com/how-to-issue-a-san-certificate-to-exchange-server-2010-from-a-private-certificate-authority
In order clients to trust the generated SSL certificate you need to import the certificate chain on the client machine. Otherwise you will receive certificate warnings.
http://support.microsoft.com/kb/940726

Reference:
=======
Planning Client Access to Exchange 2010
http://mscerts.programming4.us/application_server/planning%20client%20access%20to%20exchange%202010%20(part%201).aspx
Understanding the Autodiscover Service
http://technet.microsoft.com/en-us/library/bb124251.aspx
4
16,278 Views

Comments (5)

endital1097Customer Engineer

Commented:
in the autodiscover lookup methods you forgot the HTTP redirect method which happens after https://autodiscover.domain.com. this is an important method when considering hosting environments which are becoming more popular.

Author

Commented:
@endital1097 : You are perfectly right and that's why I wrote "simplified"
Whenever I mention the additional method to connect to the Autodiscover URL by using HTTP, people get confused and start to think that they can forget about SSL.
I've tried to keep things as simple as possible and using the Autodiscover Service with Redirection deserves a whole article for itself.
Glad, you noticed the missing step!

Commented:
Good artickle .
thanks
Your comment
"Usually the first step will fail because domain.com A record is pointing to the company’s web site."
is not entirely complete.

What if it does not fail but keeps prompting you with an untrusted web certificate for domain.com.
How does it bypass the website cert and goto autodiscover.domain.com for Outlook anywhere clients??

Author

Commented:
Well, with Outlook Anywhere and with the process for autodiscover, it won’t prompt for a certificate, it won’t give you any error or warning, it will simply fail and will continue with the next steps.
If you perform the test on https://www.testexchangeconnectivity.com/, you will see that if it finds that domain.com is listening on port 443 but fails on certificate check or any other checks, then it will continue silently to test autodiscover.domain com .
Outlook is hard coded to perform these steps to “auto discover”, failing on step 1 will not stop it to continue testing step 2 .. etc.

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.