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)
b)External (Outlook Anywhere)
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
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:
All required services should be running
> Test-OutlookWebServices firstname.lastname@example.org |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 email@example.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):
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 firstname.lastname@example.org |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
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.
= 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
* SSL cert generation
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.
Planning Client Access to Exchange 2010
Understanding the Autodiscover Service