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 jaap@wesselius.info, 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 194.165.34.155 is used, for the redirect website (autodiscoverredirect.exchange14.nl) the IP address 194.165.34.156 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