How Outlook 2007+ Clients Connect Using Autodiscover Internally…

I received an email few days back with a lot of questions around autodiscover. The sender 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 does Outlook 2007+ 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 had received.

First of all, when an Outlook 2007+ client is fired up, it queries AD for SCP object (explained here). 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 to which the Outlook clients connect to, for getting 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 you have more than one CAS, 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 you can configure this parameter with the url you are using for OWA internally, as it will hit the load balancer. Whichever url you 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 hew.local domain in my lab and I have configured an “A” record called “mail” which points to my load balancer VIP. I use “https://mail.hew.local/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.

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://mail.theucguy.net/autodiscover/autodiscover.xml”. The url “mail.theucguy.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 were 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.