Autodiscover HTTP Redirect Method using ISA instead of a second web site

Many customers that are hosting multiple SMTP domains need to use one of our Autodiscover "redirect" methods to deploy autodiscover instead of the pre-defined URL approach.  When customers choose a "redirect" method they have two options.  Below is a chart with both options and some Pro's and Con's of each.

The DNS SRV Record method was introduced by an Outlook 2007 Post-RTM hotfix and is also included in Outlook 2007 SP1.:
940881 A new feature is available that enables Outlook 2007 to use DNS Service Location (SRV) records to locate the Exchange Autodiscover service
https://support.microsoft.com/default.aspx?scid=kb;EN-US;940881

This method is great except for its few drawbacks.  First, you have to make sure all of your clients have this fix or SP1. In some environments, control of the client is not possible so this may discount this option immediately.  Another consideration with the SRV record method is whether or not *client* environments support the DNS SRV records.  For instance, if your only internet access and/or name resolution is through a proxy (or ISA Firewall Client), you have no way of resolving SRV records.

 With these drawbacks in mind, I wanted to bring light to the original method of redirecting autodiscover clients, the HTTP redirect method.  The implementation of this method via IIS is discussed in by Jason Mayans at https://blogs.technet.com/jmayans/archive/2006/09/07/454716.aspx.

After reading that, you should have a good idea that load balancing and hosting this extra redirect IIS site can be a nightmare.  Luckily, you can do it ALL at ISA!  Well 04 and 06 at least, I don't care if ISA 2000 can do it or not.  You still need an extra public IP, but the ISA redirection works great and if you have an array of ISA servers, it's automatically load balanced!

First, bind that new public IP to ISA.  Then start by creating a new Web Publishing Rule.

The Rule action will actually be set to Deny (We'll configure the redirect later)

The rest of this stuff is mostly irrelevant since it's a Deny Rule.  I chose:

"Publish a single Web site or load balancer"
"Use non-secured connections to connect to the published Web server or server farm"
"this.does.not.matter" for the "Internal Site Name"

Set the path to the actual Autodiscover.xml file: /autodiscover/autodiscover.xml

For the public name, you can set it to either the first of your hosted SMTP domains or just set the "Accept Requests for:" to "Any".

You'll want to create a new HTTP web listener, call it something like Autodiscover Redirect Listener.

Choose "Do not require SSL secured connections with clients" (very important as this redirect must be HTTP).

Select the new IP you bound to ISA for the Autodiscover Redirect listener.

Choose "No Authentication" as these requests will always be anonymous.

Ensure your new listener is selected in the wizard.

For the Auth delegation, you can choose "No delegation, and client cannot authenticate directly"

The rule cannot require authentication, so ensure "All Users" is selected.

Complete the rule.

You'll need to bring up properties on the rule and proceed to the "Action" tab.  It should be set to deny.  Put a check in the "Redirect HTTP requests to this Web Page" and enter the full HTTPS URL (matching your certificate), a which you have autodiscover published.  Mine was https://mail.wingtiptoys.com/autodiscover/autodiscover.xml.

On the "Public Name" tab, you will need to add autodiscover.<each hosted smtp domain>

Finally in each hosted SMTP domain's public DNS zone, create an A record for Autodiscover and point it to this new IP on the redirect site.

You can test this by browsing to https://autodiscover.hosteddomain.com/autodiscover/autodiscover.xml in your browser. 

It should redirect you to the URL you specified in the rule.

On launch of Outlook 2007, you should end up with a one-time dialog asking the user to allow this URL to configure their Outlook profile if you've done this right.