With the introduction of Exchange 2007, Microsoft introduced a new model for making free/busy information available to clients. While older, down-level clients (Outlook 2003 and older) still access free/busy by pulling it from a system Public Folder, newer clients such as Outlook 2007 retrieve free/busy information by making use of the SOAP-based Availability Service. This works quite well for most situations, thus paving the way for the eventual deprecation on Public Folders, but their are certain situations where this model is somewhat…lacking. The most common scenario where the limitations of this approach are made manifest is the case where the Outlook 2007 client is running on a workstation which is not bound to the Active Directory domain where Exchange is hosted. Unfortunately, this is a common situation for many departments in our environment.
The problem is as follows. When the Outlook 2007 client tries to access free/busy info from a workstation that is not bound to the domain, the free/busy fields will remain grayed-out for several minutes as the client tries and fails to invoke multiple paths to get to the data, with each attempt eventually timing out. Finally, assuming that a valid redirect has been setup to allow the client to reach the AutoDiscover/Availability Service (more on this below), a dialog box such as this will eventually appear:
Autodiscover Redirect Dialog
If the user hits “Cancel” to dismiss this dialog box, the free/busy info will not appear. Hitting the “Allow” button will promptly cause free/busy to work for the remainder of that Outlook session. (Remember to check the “Don’t ask me about this website again.” checkbox to keep from getting nagged.) The next time Outlook is started up and an attempt is made to access free/busy info, the cycle starts anew with a long delay (approximately one minute) waiting for the timeouts to take place and for the dialog box to appear (the latter only if the aforementioned checkbox was not checked).
The problem is rooted in how the client software goes about determining where to find the Availability Service. The Availability Service is web-based, and the client needs to know what URL to connect to in order to swap the relevant SOAP/XML requests. To find this, the client must first determine the SOAP/XML URL for the AutoDiscover service. Once that is found, the AutoDiscover Service can be queried to determine the Availability Service URL. (I’ve previously written an overview of the AutoDiscover Service here.) By default, Outlook 2007 will try each of the following in turn:
1) First, the client will query the Active Directory to find the Service Connection Point, which is an object in AD which contains the URLs for each service discoverable by AutoDiscover, including the Availability Service and the AutoDiscover Service URL itself. Obviously, for a client which is not bound to the relevant domain, this will fail. (If the workstation is bound to a different domain, and an SCP is defined in that domain, the wrong AutoDiscover service URL will be returned.)
2) Next, the client make a stab in the dark and guess that the AutoDiscover URL is of the form https://<smtpdomain>/Autodiscover/Autodiscover.xml and tries to post to that URL. In general, this will also fail unless the network administrators have done some rather bizarre DNS and webserver redirect trickery. At this point, a delay is introduced waiting for the https query to time out.
3) Next, the client makes another guess, this time guessing that the URL is of the form https://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml by attempting to post to it.
4) If this fails, the client will check for a redirect by performing a GET request against the URL http://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml , which paves the way for the workaround we have implemented in our environment, described below. (This is where the aforementioned dialog box gets invoked in our environment, as Outlook must ask the user if the redirect can be trusted.) Again, each failed URL guess results in another delay as the client waits for the attempt to timeout and fail.
5) If each of the previous methods have failed, and if the Outlook 2007 client is equipped with the update rollup described in KB940881, then the client will finally check DNS for an SRV record of the form _autodiscover._tcp.<smtpdomain>. (In our environment, we have recently put this SRV record in place, although the client never reaches this as long as the redirect is in place).
Once Outlook 2007 retrieves the correct AutoDiscover URL and is able to query it, all is well. The problem is that it can take a while to get to that point because of the successive times as each mechanism for guessing the Autodiscover URL fails.
Silly DNS and Redirect Tricks
So what is all of this about redirects? The trick here is getting http://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml to point to http://<CASfqdn>/Autodiscover/Autodiscover.xml. Ideally, this would be implemented by using a Subject Alternative Name certificate on the CAS roles (front-end client access servers) which provides a valid cert for both blah and blah, then setting up a CNAME entry in DNA to point https://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml to http://<CASfqdn>/Autodiscover/Autodiscover.xml . This approach is described here and would negate the appearance of the dialog box described above since the correct AutoDiscover URL would be found on step 3 rather than step 4 (and the process would be slightly faster, since there would be one less timeout involved). However, at the time that we first deployed Exchange 2007, our Managed SSL certificate infrastructure did not give us the option of purchasing Alternative Name certificates (a situation which has since changed – more on that shortly), so we had to do something a bit… different. Specifically, we followed the tip found here. Now, when step 4 listed above is attempted by the client, the following sequence of events takes place:
1) DNS resolves http://autodiscover.<smtpdomain>/Autodiscover/Autodiscover.xml resolves to an IP address on our Netscaler load-balancing appliances.
2) The NetScalers pass the GET request to one of our CAS boxes, but on different IP addresses that the one used by other CAS functions. A separate site in IIS on the CAS servers listens specifically on these IP addresses.
3) Within the custom website, the /Autodiscover/Autodiscover.xml structure exists, but the empty xml file has a redirect assigned to it pointing to http://<CASfqdn>/Autodiscover/Autodiscover.xml .
4) When this redirect is encountered, the client is presented with the dialog box mentioned earlier. Once the client accepts, the redirect takes place, and the proper AutoDiscover URL on the CAS boxes is finally found.
Improving the Situation
There are several steps we can take to improve our setup. The first step has already been taken by adding an SRV record for the AutoDiscover server. That way, AutoDiscover clients will still be able to find the correct service URL even if the other methods fail for some reason. But the biggest step, which I hope to perform in the near future, would be to replace our existing CAS cert with a Subject Alternative Name cert containing our regular CAS alias name, the Autodiscover URL name, plus an additional legacy name for our CAS servers which will come in handy during the eventual transition to Exchange 2010. Once this is deployed, we will be able to eliminate the redirect step and have proper resolution of the AutoDiscover URL in step 3 as enumerated above. This will at least eliminate one timeout from the process. Alas, some timeout delay is inevitable for non-domain clients. If only Microsoft would modify the query order to try the SRV record right after the SCP check….