The AutoDiscover service is a brand new feature for Exchange 2007. The service allows new Outlook 2007 clients to have their profiles automatically generated using nothing more than a user’s email address and password. The information here can be found elsewhere with greater depth but there really doesn’t seem to be any source that paints a complete and succinct picture about what an Exchange Engineer will face when facing the necessary configuration.

AutoDiscover will return to the client configuration information such as the name of their mailbox server, Outlook Anywhere (RPC/HTTP) info and connection protocol. The service has much greater function and is actually an integral part to the functionality to an everyday user on Outlook 2007.

I recently completed a migration of all of a company's mailboxes from Exchange 2003 to a production Exchange 2007 system. The Exchange 2007 system was configured with all three primary roles (mailbox, client access, hub transport) on a single machine and client access was published by ISA 2006.

Last week I found a problem in that a new employee did not show up in my address book. Because the client I was testing from was in cached mode, I tried to force a download of the address book which subsequently failed with error “Object could not be found” and code 0X8004010F. I then tested Free/busy access, which also failed. I thus concluded I had issues accessing Public folders and because I had not received complaints also concluded that the problem was unique to the profile I was testing.

When a couple of other people claimed to have similar issues I knew then that it might be bigger than I thought. The first thing I did was to verify the Exchange configuration of the profile and access to public folder data. All was well.

I fired up Outlook on another workstation and lo and behold --- there were no evident problems!

The only difference I could find was that the workstation was joined to the domain while my laptop was not. After looking at all the security contexts involved I could not see any security settings that would preclude connection from a client that was not in the domain. I checked around with other users and found that this was indeed the case company wide. Only domain joined systems were able to download the OAB and see F/B data.

The problem behind it all was a result of failing to properly configure the AutoDiscover service. Outlook 2007 needed AutoDiscover to find the path to the OAB and FreeBusy data. The reason behind the failures for non-domain joined PC’s was because of the logic and steps taken by Outlook 2007 to find the AutoDiscover agent.

There are three scenarios to take into account when configuring the AutoDiscover service.

1. The first one was the simplest and will work off the bat. When a domain joined client tries to find the AutoDiscover agent it will take the domain account and look for Service Connection Point within Active Directory the will return the location of the agent. So a user on a Mail server named MyServer will get back https://Myserver.domain.net/autodiscover/autodiscover.xml . This scenario will work right out of the box because the IIS directory is created during deployment of Exchange.
2. But the complication lies where a client is unable to look in Active Directory such as the case for remote clients and non-domain joined PC’s. When Outlook 2007 is unable to find the path in AD it will, by default, look in two paths. Outlook will take the user’s SMTP domain and use it to search for AutoDiscover. It will first parse the domain and try https://domain.net/autodiscover. When that attempt fails it will try https://autodiscover.domain.net/autodiscover.
3. This logic failed for internal non-domain machines because I did not have a dns record for autodiscover. Once I added this record, the agent could be found but after viewing my Outlook log I could see that it was given a http 404 error which is “access denied”. Because all Exchange 2007 systems use SSL by default I concluded that the problem lay with the certificate.
4. Pointing to autodiscover.domain.net was not good enough because the URL would be invalid for the certificate using MyServer.domain.net.

   The solution is to use Subject Alternative Names in the certificate.

   Subject Alternative Names allow a single certificate to be used for multiple URL’s. In this case I used the CMDLET New-Exchange.

   New-ExchangeCert New-ExchangeCertificate -DomainName Myserver.domain.net, autodiscover.domain.net, autodiscover.domain.com -GenerateRequest:$True -privatekeyExportable:$true

   I specified the hostname MyServer.domain.net and added autodiscover.domain.net as well as autodiscover.domain.com. After generating the request, I submitted it to our CA and used it to replace to existing certificate.

   The same method could be used for remote access as well where I have published the CAS as email.domain.net. The customer had purchased a Thawte certificate during the deployment that would be used by ISA to complete the SSL connection. Unfortunately, because publicly trusted certs that use Subject alternative names cost more than twice the amount as Thawte’s basic Web server certificate, the customer decided that purchasing the required cert was not an option. What to do?

   I decided to create an entirely new listener on ISA that would handle the request for AutoDiscover. To do this I added another public IP to ISA and published a client access rule just for Autodiscover and generated a certificate on our domain CA for the proper URL.

   This solutions was somewhat of a compromise because of the fact that I had to use my own CA to generate the cert and any new systems will need to have the trusted root certificate added. Basically this senerio is most likely going to be faced by many administrators.

   Chris Dearie
   Network Engineer
   Azaleos Corporaiton