Exchange 2010 and Autodiscover Part I
Autodiscover is a feature in Exchange Server 2010 and higher which is being used by Outlook 2007 or higher. Due to the number of question I get on Autodiscover I’ve created a number of blog posts that explain the Autodiscover functionality:
- Autodiscover Part I – Introduction Autodiscover and Outlook on a domain joined client (this post);
- Autodiscover Part II – Outlook on a domain client (connected externally);
- Autodiscover Part III – 3rd party certificates or an internal PKI environment;
- Autodiscover Part IV – Using different SMTP domainnames (yet to be written).
Autodiscover is a very useful feature in Exchange 2007 and Exchange 2010 that makes it possible to automatically create Outlook 2007 and Outlook 2010 profiles.
The first time Outlook is started you only have to enter your name, E-mail address and password and the rest is configured automatically. But there’s more that most people don’t know…. If you don’t have configured autodiscover correctly chances are that you are facing some weird unexplained errors like people not being able to set their Out-of-Office for example, or not being able to see free/busy information from other people in the organization, or you will error messages in your inbox regarding the OAB download… Oh, and don’t forget the dreaded “The name on the security certificate is invalid or does not match the name of the site” error message….
Suppose we install an Exchange Server 2010 Client Access Server in an Active Directory domain contoso.com. For the external facing domain name the FQDN webmail.contoso.com is used. This is the FQDN that’s being used by external clients to access the Client Access Server.
The installation of the Client Access Server automatically creates a “Service Connection Point” or SCP in Active Directory. For this post I’ll start with a default installation without any further configuration changes.
The SCP will be read by Outlook clients from Active Directory and this SCP contains configuration information regarding the Client Access Server. The SCP is not visible using standard tools like Active Directory Users and Computers but only with Active Directory Sites and Services (enable the “View Services Node” option) or using ADSIEdit:
Figure 2. The SCP of the CAS server in Active Directory
Note: if there are multiple Client Access Servers you’ll see multiple SCP’s in Active Directory.
The SCP has a property named ServiceBindingInformation and the value of the Autodiscover URL of the Client Access Server is stored in this property. In our example it will be https://AMS-EXCH01.contoso.com/Autodiscover/Autodiscover.xml.
When looking at this URL you can see that autodiscover is a service offered by the Client Access Server. During installation an Autodiscover virtual directory is created in IIS which is (of course) visible in the IIS Manager on the Exchange Server:
Figure 3. The autodiscover virtual directory on the CAS server
Autodiscover is not a one off action performed by the Outlook client. Outlook will try to autodiscover the Client Access Server every hour to check for changes in the infrastructure. If found the Outlook profile will be changed accordingly.
Outlook on a domain joined client
Let’s start with a Windows PC that’s a member of the Active Directory domain where we installed the Exchange Server 2010. The Active Directory domain is named “contoso.com” and in our example the SMTP address is the same (also “contoso.com”). I will discuss other scenario’s in future blog posts.
During the installation of the Client Access Server a self-signed certificate is created. The “distinguished name” of this certificate is the NETBIOS name of the Client Access Server, but in the “Subject Alternative Names” field of the certificate you’ll find the Fully Qualified Domain Name (FQDN) of the Client Access Server:
Figure 4. The self-signed certificate with the SAN attribute
The self-signed certificate is meant primarily for testing purposes and will not be accepted by default by any client. So, if we use the browser to navigate to https://ams-exch01.contoso.com/owa the well known error message will be shown:
Figure 5. The security certificate presented was not issued by a trusted certificate authority
Just click on “Continue to this website (not recommended)” and you can logon to OWA. The certificate icon/message in OWA will still tell you something’s wrong with the certificate:
Figure 6. The certificate error message is clearly visible in OWA
The next step is to start Outlook. A domain client has read access to Active Directory and thus be able to look for the SCP. During startup Outlook will query Active Directory for the SCP and once found it will check for the Autodiscover URL in the ServiceBindingInformation property as explained earlier. Once found Outlook will send an HTTP POST request to this Client Access Server which in our example is https://AMS-EXCH01.contoso.com/Autodiscover/Autodiscover.xml. As you can see this is an SSL connection so the certificate on the CAS server is going to play an important role in this step.
Outlook is going to contact this URL, but since a self-signed certificate is installed Outlook will generate an error message. This error message is only shown in Outlook 2010, Outlook 2007 will ignore the error and continue with the next step.
Figure 7. Certificate error message shown during autodiscover process in Outlook 2010
Outlook will perform an http POST request on the Autodiscover URL and this request is intercepted by the Autodiscover Service and passed to the Outlook Provider. The Outlook provider is able to check whether the request is from an RPC/MAPI client (and thus an internal client) or from an Outlook Anywhere client.
Figure 8. The Autodiscover service and related services in the CAS Server
The Outlook provider passes the request to the Services Discovery Service which retrieves the information from Active Directory. The information is returned to the Autodiscover services, an XML package is create and this XML package is sent back to the Outlook client. Once received Outlook will use this XML package to generate the Outlook profile and Outlook can be restarted. But during this restart a certificate warning will still be shown:
Figure 9. Certificate warning while starting the Outlook client
Outlook will still function properly with all expected services like Autodiscover, Availability Services (free/busy), MailTips, Offline Address Book downloads and the Exchange Web Services (EWS).
How to this test?
When Outlook is runing you’ll see a small Outlook icon in the system tray. Right click this Outlook icon and select “Test E-mail AutoConfiguration”:
Figure 10. Testing Autodiscover functionality in Outlook 2010
Enter your E-mail address and password and uncheck the “Use Guesssmart” and “Secure Guesssmart Authentication” options. When you click the Test button Outlook will test the Autodiscover functionality and show the results after approx. 15 to 20 seconds:
Figure 11. Results of an Autodiscover test in an Outlook 2010 client
This functionality is the same in Outlook 2007 although i twill return less data:
Figure 12. Results of an Autodiscover test in an Outlook 2007 client
To setup a connection with the Exchange server Outlook will use the MAPI protocol and this will only be used for e-mail information. Other services like Autodiscover, Availability, Out-of-Office, MailTips or Offline Address Book downloads the HTTPS connection with the CAS Server will be used.
The next step is to use Outlook Anywhere (previously known as RPC over HTTPS), assuming that Outlook Anywhere is enabled and the FQDN AMS-EXCH01.contoso.com is used for the proxy server. Unfortunately this will not work straight away: the operating system where the Outlook client is running (Windows 7 in our example) will not allow the HTTPS traffic based on the wrong certificate (security is not guaranteed) and show an error message:
Figure 13. Outlook Anywhere will show a certificate error message, even on a domain joined client
The solution here is to store the CAS Server’s self-signed certificate in the certificate trusted root store of the client where Outlook is running. The client will now trust the certificate and also Outlook Anywhere will work as expected. Another advantage of this is that the certificate warning messages in OWA and plain Outlook will disappear as well.
To store the self signed certifcate on the domain client open OWA, accept the certificate warning and logon to OWA. In the upper right corner (see figure 5) the certificate warning is shown, click on this warning and open the certificate. Now click on the Install Certificate button. Please note that this option is only available on domain joined clients. If a non-domain client is accessing the self-signed certificate the Install Certificate button is NOT shown.
Figure 14. Store the self-signed certificate on a domain joined client
Follow the wizard, when asked for the certificate store select the ‘Trusted Root Certification Authorities’ using the Browse button. Another warming is shown (makes sense, Windows cannot validate the certificate) but just finish the Wizard.
Figuer 15. A warning message due to the untrusted cetificate being stored.
Now when OWA is started the certificate warning is gone. Since the self-signed certificate is stored in the Trusted Root the certificate is automatically accepted. Outlook Anywhere will now work as well and setup a connection via HTTPS:
Figure 16. Outlook Anywhere now works with the self-signed certificate
(Important) Note. Although this might be working it is not a best practice to do in a production environment (but I have seen customer do this). A better option is to use a wildcard certificate or a UC Certificate from an internal Active Directory Certificate Services CA (Certificate Authority) or a 3rd party certificate. I’ll get back on this in the part III of this series of blog posts.
Conclusion Part I
Autodiscover is a service in Exchange 2007 and higher that is offered via the Client Access Server. Outlook 2007 and higher will automically use this new services. During installation of the Client Access Server the autodiscover service is automatically configured in Active Directory and Exchange and in a (very) simple scenario like outlined in this article it will work, although you’ll see some warning messages in OWA and in Outlook.
Domain joined clients will retrieve the Autodiscover information from Active Directory through the Service Connection Point (SCP) and access the appropriate Client Access Server to retrieve all Exchange related information and build an Outlook profile. Once running Outlook will use the Autodiscover functionality on an hourly basis to check for changes in the infrastructure.
In my next blog I’ll show what happens on a non-domain client, or a domain client that has no access to Active Directory.
Follow me on Twitter: @Jaapwess