If you would like to read the next part in this article series please go to Exchange Autodiscover (Part 2).
When Microsoft released Exchange Server 2007, one of the new features it included was Autodiscover. Autodiscover allows you to automatically configure Outlook 2007 clients, but, there is a lot more behind the Autodiscover functionality. When you have issues with the Out-of-Office or Free/Busy information in Outlook 2007 in combination with Exchange Server 2007 (or Outlook 2010 and Exchange Server 2010) it is likely that it is caused by a misconfiguration in the Autodiscover configuration. To make things more complex, the SSL certificates are involved here as well.
The Autodiscover process for Exchange 2007 and Outlook 2007 is practically the same as for Exchange 2010 and Outlook 2010. In this article I will use Exchange 2010 and Outlook 2010.
Autodiscover information is stored in a so called SCP or Service Connection Point. You can view this SCP using Active Directory Sites and Services after you have enabled the “View Services Node” option:
Figure 1: The Service Connection Point of the Client Access Server in Active Directory
When installing the Client Access Server (Autodiscover is part of this Server Role) the SCP is automatically created in Active Directory and configured with the default values. If you have multiple CAS Servers there will be multiple SCP’s as well.
When Outlook 2007 is installed on a domain joined workstation then the Outlook client will query Active Directory for the Autodiscover information. Active Directory will return a list of SCP’s and the Outlook client will automatically select the first SCP in this list. Using the information found in the SCP the Outlook client will contact the Client Access Server for its configuration information and the Outlook client will be configured automatically.
Non-domain clients are a bit trickier to configure since they will not query the Active Directory. Because of this non-domain clients try to retrieve information using the Autodiscover website. The FQDN that the Outlook client will use is based on the SMTP address that is used when starting the Outlook 2010 client the first time. So, when an e-mail address email@example.com is entered, the Outlook client will start trying to connect to the Client Access Server using HTTPS. There are several URL’s that Oulook will use, but the most important is https://autodiscover.exchange14.nl.
Please be aware that this is the (Internet facing) Client Access Server. So besides the normal Outlook Web Access URL like https://webmail.exchange14.nl the same Client Access Server is also contacted using https://autodiscover.exchange14.nl. This is exactly the reason a Unified Communications (UC) or SAN certificate is needed. SAN is an abbreviation for Subject Alternative Names (and has nothing to do with your storage solution BTW). A SAN certificate contains besides the standard name other names as well. According to Microsoft knowledge base article 929395 the following UC certificate partners are officially supported:
There are more 3rd party vendors for UC certificates and these certificates work fine as well, but the three above are officially supported by Microsoft.
You can check your certificate by browsing to the Outlook Web App site and request the properties of the certificate:
Figure 2: Subject Alternative Names in a Unified Communications certificate
Besides the possibility to configure the Outlook 2007 and higher clients using the Autodiscover process there’s more information, “hidden” behind this process:
Offline Address Book download information;
Unified Messaging information;
Exchange 2010 personal archive (for Outlook 2010 clients);
In Exchange Server 2010 the properties related to these settings are configured during setup of the Client Access Server when entering the “this is an external facing Client Access Server” option. When you do not select this option, or in Exchange Server 2007 you have to configure these properties manually using the Exchange Management Shell:
Set-OWAVirtualDirectory –Identity 2010CASHUB02\OWA (default web site)
Set-OABVirtualDirectory –Identity 2010CASHUB02\OAB (default web site)
Set-WebServicesVirtualDirectory –Identity 2010CASUB02\EWS (default web site) -ExternalURL https://webmail.exchange14.nl/ews/exchange.asmx
Set-ActiveSyncVirtualDirectory –Identity 2010CASHUB02\Microsoft-Server-ActiveSync (default web site)
This setting is only valid for Exchange Server 2010:
Set-ECPVirtualDirectory –Identity 2010CASHUB02\ECP (default web site)
The last step is to configure the external DNS. Both the webmail hostname as well as the Autodiscover hostname need to point to the external facing Client Access Server.
When you start up Outlook 2007 or Outlook 2010 you can automatically configure your profile, just by entering your e-mail address and password. When Outlook is configured it can take some time before Outlook is synchronized, but after some time you should be all set. If all goes well you should be able to set your out-of-office settings and check other mailboxes free/busy information.
How do you check if all works well? If you start Outlook you can see the small Outlook icon in lower right corner of your (Windows) PC. Press the Control key together with a right mouse click, there you have two options:
Test E-mail AutoConfiguration
Figure 3: Testing options in Outlook 2010
The connection status shows the various connections that are initiated between the Outlook client and the Exchange server. With the ‘Test E-mail AutoConfiguration’ there is the possibility to test the Autodiscover configuration.
Fill in your e-mail address and password, and to check the Autodiscover functionality only deselect the “Use Guessmart” and “Secure Guessmart Authentication”. When you click Test the Outlook client will check the full Autodiscover functionality (be aware that this can take up to 60 seconds) and the results will be shown on the Results tab:
Figure 4: The results of testing the Autodiscover options in Outlook 2010
Another way, especially when troubleshooting your Autodiscover configuration, is the Remote Analyzer that is available on the Internet. Go on to www.testexchangeconnectivity.com. This site is developed by a few guys from the Microsoft Exchange Product Team. This site can help you troubleshoot all kinds of remote connectivity issues and gives detailed results after checking.
Figure 5: The Exchange Remote Connectivity Analyzer on the Internet
Navigate to http://www.testexchangeconnectivity.com and select “Outlook AutoDiscover”, click Next to continue. Fill in the values for e-mail address, password and check that you understand the acknowledgements and so on. When done, enter the verification code. When you click Next the actual tests are conducted and if all goes well you should see the results in approximately 30 seconds:
Figure 6: Successful test of the Autodiscover functionality
The red cross indicates something went wrong, the green arrow indicates the tests are successful. Please note that not all steps need to be successful. In Figure 6 for example the Autodiscover test in the root domain fails, but the FQDN Autodiscover.exchange14.nl is successful.
Besides Autodiscover the Exchange Remote Connectivity Analyzer has a number of options to test, the ActiveSync Connectivity Test for example is very powerful for testing your Windows Mobile environment. It immediately shows if the ActiveSync configuration is working properly. As a side note, when checking the ActiveSync configuration you can use the Windows Mobile emulator which can be found on the Microsoft download site.
Multiple SMTP namespaces
The above mentioned solution is pretty easy as long as one and only one SMTP namespace is used. It is not uncommon however that companies use multiple SMTP namespaces. I am currently working with a customer that has over 12 SMTP namespaces and there are hundreds of mailboxes using different SMTP domains. This makes life a bit more complicated.
As explained earlier, the Outlook client tries to connect to the Autodiscover website using the SMTP address of the particular user. For example, the Exchange 2010 organization used in this article also hosts mailboxes for ‘wesselius.info’. When Outlook contacts the Exchange server for a mailbox firstname.lastname@example.org, it uses a FQDN based on the e-mail address, so it wants to use Autodiscover.wesselius.info. This FQDN points to the same Exchange Server2010 Client Access Server as the Autodiscover.exchange14.nl. Needless to say that these server names are not listed in the certificate that is configured on the Client Access Server as shown in Figure 2, so Autodiscover.wesselius.info will result in a certificate error message. And since the certificate error functions like Autodiscover, Out-of-Office and Free/Busy will not function correctly. So a solution needs to be implemented to get around the certificate restrictions, but without losing the security provided without SSL.
Microsoft has released a whitepaper where all options regarding the Autodiscover functionality and their options are explained, this is the Autodiscover Whitepaper. One solution I’d like to explain here is the redirection method to get the multiple SMTP namespace issue fixed (Scenario 4 in the Autodiscover Whitepaper).
Outlook’s Autodiscover will try several methods to retrieve the Exchange configuration information. After trying several HTTPS options Outlook will switch back to an HTTP option, so without the SSL security, and this gives a possibility to create a multi-namespace solution. An additional website is created on the Client Access Server, without the SSL implementation and this is a redirect website. The only downside of an additional website on your server is that an additional IP address is needed. For the default website of www.exchange14.nl the IP address 188.8.131.52 is used, for the redirect website (autodiscoverredirect.exchange14.nl) the IP address 184.108.40.206 is used. An additional website is created in the Internet Information Server (IIS) Manager:
Figure 7: The two websites are clearly visible in the IIS Manager of the Client Access Server
To change the IP address that’s bound to the Autodiscoverredirect website, right click it and select “Edit Bindings” and add the additional IP address to this website.
The Autodiscover directory underneath the Autodiscoverredirect website does not point to a directory on the local disk like a default website, but it is redirected to the default website. The redirection however is configured using SSL, so in the end an encrypted connection between the Outlook client and the Exchange Client Access Server is created.
Figure 8: Redirection from the autodiscoverredirect website into the default website
How do we connect additional SMTP namespaces using the redirect option? By using CNAME records in the public DNS. For example, the public IP entry for Autodiscover.wesselius.info is a CNAME entry pointing to autodiscoverredirect.exchange14.nl. From there it is redirected to the default website. And this works like a charm, both for Exchange Server 2007 (like in the whitepaper) as well as for Exchange Server 2010.
Is there no downside on this solution? Yes, but in my opinion a small one. When users connect their Outlook 2007 to Exchange Server 2007 or Exchange Server 2010 they get a warning that Outlook is redirected to another website.
Figure 9: The redirect warning that Outlook 2007 users will receive during initalization of their mailbox
Autodiscover can be quite challenging in an Exchange Server 2007or Exchange Server 2010 environment, especially when you have multiple SMTP namespaces in use in your Exchange environment. When not configured properly this will result is strange behavior with respect to Out-of-Office functionality and Free/Busy (availability) information. In this article I tried to explain how to get around these issues. If you’re facing difficulties using Autodiscover please do not hesitate to contact me on email@example.com. Till next time!
If you would like to read the next part in this article series please go to Exchange Autodiscover (Part 2).