How Outlook 2007 & 2010 clients Connect Using Autodiscover Internally

Published by Ed

My colleague asked me the other day few questions about Autodiscovery and how it works internally as he was having some issues connecting his Outlook client to the exchange mailbox server internally. My colleague was confused about a number of facts around autodiscover service. This has prompted me to write “to the point articles” about this wonderful service.

How do Outlook 2007 and 2010 clients connect using autodiscover service internally? What is needed and what should be configured? Do we need an “A” record for autodiscover.ADdomain.local? These were few of the questions I got.

First of all, when Outlook 2007&2010 clients are started, they query AD for SCP object (will explain in a separate blog). Every CAS server in the environment will have a corresponding SCP object. The SCP object has an attribute named “serviceBindingInformation” which is an HTTPS URL, normally pointing to the CAS server itself.



We can configure this url using the Exchange Shell, by setting the “AutodiscoverServiceInternalURI” parameter of the CAS server. It is this url which the Outlook clients connect to, to get the urls for Exchange services (OAB, OOF, Availability Service etc) provided by the autodiscover service.

So, the first step in configuring autodiscover internally is to set “AutodiscoverServiceInternalURI” parameter of the CAS server. If there are more than one CAS server, then it has to be set on all servers. Normally, we point this url to the load balancer and cover it in the SAN/UCC certificate. This means that we can configure this parameter with the url we’re using for OWA internally, as it will hit the load balancer. Whichever url we go for (a new one or use existing internal URLs), it has to be in the SAN/UCC certificate.

The url doesn’t have to have the format of autodiscover.ADdomain.local. There is no specific format for this url, it is just a url that can be routed internally. For example, I have claytonutz.net domain in my lab and I have configured an “A” record called “webmail” which points to my load balancer VIP 172.32.16.21. I use “https://webmail.claytonutz.net/autodiscover/autodiscover.xml” as my “AutodiscoverServiceInternalURI” and I have this url as part of my SAN/UCC certificate. I ran the command below to configure it.

As a good practice that I ran the Get-ClientAccessServer cmdlet to make sure you’re getting the entire CAS server in your AD site. Get-ClientAccessServer | Set-ClientAccessServer –AutoDiscoverServiceInternalUri https://webmail.claytonutz.net/autodiscover/autodiscover.xml

To make sure your command was excuted correctly, you need to get the autodiscover service internal url by typing

Get-ClientAccessServer | fl autodisc*
If you have split-DNS (which means that your OWA urls are same internally and externally), you can configure “AutodiscoverServiceInternalURI” parameter to be your OWA url. If I had split-DNS, I would configure it to be “https://webmail.claytonutz.net/autodiscover/autodiscover.xml”. The url “webmail.claytonutz.net” will be in my SAN cert, as that is the same url for all my Exchange services like OWA, EAS, OA. I think you get the point.

In short, you can configure “AutodiscoverServiceInternalURI” parameter of the CAS server to be any url, as along as it reaches the CAS server (either directly or through load balancing) and is covered in the SAN certificate. You don’t need a split-dns model just to have autodiscover working internally. I think this is where most of the admins are getting confused. Split-DNS is something “nice to have”, so that users will use the same urls irrespective of whether they are internal or external for OWA, ECP, EAS, OA and the SAN cert will only have public urls.

Once the autodiscover url is set internally, you need to set the internal (and external for external access) urls for the different Exchange virtual directories, like ActiveSync, WebServices, OWA, OAB, UM etc. I hope this clear the doubts of many exchange admins.

Note: You can use an internal PKI certificate covering “AutodiscoverServiceInternalURI” url and a third party certificate in your reverse proxy like TMG.

Cheers,
Ed