In earlier versions of Exchange you can use the Autodiscoverredirect option to retrieve autodiscover information if your primary SMTP domain in your email address does not match the domain name of the autodiscover DNS record in your Exchange deployment. You’ll face this issue when your Client Access server is using webmail.contoso.com and autodiscover.contoso.com but your email address is firstname.lastname@example.org. In this case your Outlook client will automatically start looking for a DNS record called autodiscover.fabrikam.com which points to the autodiscover.contoso.com. As a result a certificate warning is presented since the name of the request does not match the name on the certificate.
In my blogpost Autodiscover Redirect and SRV option I explained how to use the AutodiscoverRedirect or the SRV records method to use Autodiscover when using multiple primary SMTP addresses in an Exchange 2010 environment.
This works fine as long as your Exchange server is connected directly to the Internet (behind a firewall of course) and you have the possibility to add public IP addresses to your Exchange Server. When using a reverse proxy solution like Threat Management (TMG) Server in front of the Exchange 2010 Client Access Server, all Exchange services are published to the Internet, and this requires a different approach for the AutodiscoverRedirect method.
First thing, the Client Access Server no longer needs to the autodiscoverredirect website since this is now handled by the TMG Server. So the Client Access Server can be used in a default configuration. In this environment a certificate with two FQDNs are used: webmail.exchange14.nl and autodiscover.exchange14.nl but now this environment is published using TMG 2010 SP1.
The TMG Server now intercepts all autodiscoverredirect traffic so a new rule with a new listener (on a separate IP address) needs to be created. Please note that this traffic is unencrypted, so HTTP (port 80) needs to be used for this listener. For the Client Authentication Method when creating the Web Listener select No Authentication.
The next step is to create a web publishing rule that uses this listener. This rule should deny all traffic and redirect it to the ‘normal’ autodiscover URL on the TMG Server, i.e. https://autodiscover.exchange14.nl/autodiscover/autodiscover.xml.
One thing to notice though, after creation of the web publishing rule you can select whether this rule listens to all requests or only for specific websites (select the Public Name tab). Also, don’t forget to change the redirection (select the Bridging tab) to port 80. Like the previous blog post you have to enter the autodiscoverredirect.exchange14.nl in the public DNS, and for other domain create a CNAME autodiscover record (again in public DNS) and point this to the autodiscoverredirect.exchange14.nl FQDN.
Now when you go to the Remote Connectivity Analyzer (www.testexchangeconnectivity.com) and test using another domain you’ll see that it again works, but now via the TMG Server.
The warnings in this screenshot is about root certificate not being able to verify. Also note that in this example the RCA doesn’t even try the SRV method since the redirect method is successful.
The autodiscover SRV records option I explained in my previous article works immediately through the TMG Server. This makes sense since the information is taken from public DNS directly and the autodiscover service is accessed directly without any redirection.
One thing I would like to mention. Quite a lot of people think that autodiscover fails because of the 3 failing attempts (in the above screenshot). While this is true autodiscover successfully finishes the fourth option so autodiscover is considered to be successful.
Now combine the autodiscover redirect and the SRV method with the Address Book Policies that will be available in Exchange 2010 Service Pack 2 and you’re one step closer to your own Exchange 2010 hosting solution.
To be continued, stay tuned…