See through Autodiscover

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:
  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)

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
 
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  
Now if you open IIS management console you will find a virtual directory called Autodiscover and the URL above is just pointing to it!
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)  
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
 
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