Last post May 14, 2009 09:56 AM by DmitriG
Apr 09, 2009 11:26 AM|benjamin.bell|LINK
We are currently setting up HMC 4.5 - Have run into a problem with the Autodiscover redirection, we have followed the HMC 4.5 documentation, and so have three separate IP Addresses on the Exchange Client Access Server:
* AutodiscoverRedirect - Port 80 only, no certs
* Autodiscover, - 443 - certificate for autodiscover
* Default Web Site - 443 - certificate for owa/oa etc
On ISA Server, we have three listeners with three public IP addresses
* AudiscoverRedirect - No Authentication, Port 80 Only, listens for AutodiscoverRedirect.hostingdomain.com
* Autodiscover - HTTPS (basic) Authentication, 443 only, listens for Autodiscover.hostingdomain.com
* Exchange 2007 - HTTPS, FBA Authentication, 443 only, listens for owa.hostingdomain.com
All SSL certs are assigned as required. We have rules for all the services, the one for AutodiscoverRedirect listens for AutodiscoverRedirect.hostingdomain.com and reverse proxies back to the Exchange 2007 CAS Server, and correct IIS
website for the redirection.
For a hosted client a CNAME exists for Autodiscover.clientdomain.com -> AutodiscoverRedirect.hostingdomain.com
So far, everything such as Outlook Anywhere, OWA etc work okay when manually configuring the client. BUT Autodiscover does not work.
The Outlook client drops back to the http redirect, and then fails. Reviewing the ISA event log, the traffic is coming to the right IP address of the redirect listener, and the traffic is http on port 80, but the URL being requested
is denied, as it is still the original URL of autodiscover.clientdomain.com - if the rule is changed to accept the public URL of autodiscover.clientdomain.com then it all works as expected with no errors and the client is autodiscovered/configured/working.
But we don't want to have to add every client domain to that rule on the ISA boxes, surely the redirect method does not require this? Also, have tested doing the URL redirection within the ISA AutodiscoverRedirect rule, which worked,
but once again, only when explicitly putting the customers domain name in the rule.
Has anyone got this working correctly, and if so, how do you do it?
Apr 12, 2009 06:01 AM|fjdreyer|LINK
I have got this working, the way I did it is pretty similar to your's except I have assigned a different IP address to each listener on the ISA server, you do not mention having done this.
Hope that this helps.
Apr 12, 2009 08:00 PM|benjamin.bell|LINK
Yes, each listener has a different IP address - the problem is that the outlook client always seems to be using the client domain url when requesting the autdiscover.xml - thus ISA is denying the URL, even though it has done the CNAME lookup to actually
reach the right ISA IP address for the autodiscoverredirect listener....
Apr 13, 2009 09:46 AM|DmitriG|LINK
Try to replace "AutodiscoverRedirect.hostingdomain.com" with public IP address in HTTP publishing rule.
Apr 14, 2009 05:45 AM|benjamin.bell|LINK
Okay - so I put the Public IP address on the rule - makes no change - the request is still denied, as the outlook client is still sending a GET of the client's hosted domain name rather than the CNAME results.... am I just missing something really simple
- has no one else ever encountered this issue? If I put the clients domain in the public name of the redirect rule - then it all works, but it does not seem feasble to put every hosted domain in the firewall rule....
Note: Only port 80 is enabled on the autodiscoverRedirect listener, only 443 is enabled on the Autodiscover listener.
Denied Connection [ISA Server Name] 14/04/2009 10:30:55
Log type: Web Proxy (Reverse)
Status: 12202 The ISA Server denied the specified Uniform Resource Locator (URL).
Rule: [Enterprise] Default rule
Source: Internal [client ip address)]
Destination: (ISA AutodiscoverRedirect IP Address)
Filter information: Req ID: 0784e756; Compression: client=No, server=No, compress rate=0% decompress rate=0%
Client agent: Microsoft Office/12.0 (Windows NT 5.1; Microsoft Office Outlook 12.0.4518; Pro)
Object source: (No source information is available.)
Cache info: 0x0
Processing time: 1 ms
Apr 14, 2009 06:01 AM|fjdreyer|LINK
Possibly a bit of a redundant question, but have you set the "Users" in the publishing rule to "All Users" ?
Secondly (this shouldn't affect it but you can try anyway) can you check that you have "Allow client to Authenticate over HTTP" enabled on the listener under the Authentication / Advanced Options?
Apr 14, 2009 06:39 AM|benjamin.bell|LINK
Hi, yes, "ALL Users" and I have changed the authentication option, but no change in behaviour....
Note, that the request is not even getting to the AutodiscoverRedirect publishing rule, as the client request that Outlook is sending does not contain either of the public names (Public IP Address and AutodiscoverRedirect.hostingdomain.com) that the rule
is listening for - so everything is being dumped by the default enterprise deny rule.....
Thanks for all the suggestions, but this almost seems like more a Outlook problem, as the Outlook is just not changing the HTTP GET request from the client hosted domain to the CNAME result - if I do a packet capture on the client machine, the following
is the http request...
Http: Request, GET /autodiscover/autodiscover.xml
And this is the URL that ISA is rightly denying.... really not sure what the solution is to this.
Apr 14, 2009 08:34 AM|benjamin.bell|LINK
Okay - found a "workaround" - No idea if this is how it should be done or not.
1. Autodiscover as a seperate website on the Exchange 2007 CAS Server
2. Default website on the Exchange 2007 CAS Server for all things not Autodiscover
3. No requirement for a dummy autodiscoverRedirect website on the Exchange 2007 CAS Server
On the ISA Server
Three Listeners, each with their own IP address in the DMZ which is NAT'd to a public IP address
1. Exchange 2007, 443, FBA Authentication, Main listener for all OWA/RPC etc
2. Autodiscover, 443, HTPP authentication - a publishing rule uses this for autodiscover.hostingdomain.com/autodiscover/autodiscover.xml
3. AutodiscoverRedirect, 80, no authentication - a deny publishing rule uses this for all urls and redirects them to the above URL
The only way I found I could make this work is to accept requests for ANY DOMAIN when creating the deny rule, and then redirecting that to the
This appears to work - but I don't feel it is the most graceful way of achieving this.
May 07, 2009 07:40 PM|amos.max|LINK
I realize this thread is kinda old, just wanted to add something to it:
...then it all works, but it does not seem feasble to put every hosted domain in the firewall rule....
...then it all works, but it does not seem feasble to put every hosted domain in the firewall rule....
That's the only way it will work though.
The Outlook Autodiscover process attempts to connect to http(s)://autodiscover.clientdomain.com/... (tries SSL connection first), so there's no way around putting the clientdomains on the listener - otherwise ISA will reject the connection (I would definitly not
put "Any" on the publishing rule !!).
To make things easier you could script adding the client domains/Urls to the ISA rule and execute the script when the email domain gets provisioned.
Alternative: use dns srv records and make sure all clients have KB939184 installed (->
Rgds - Marcus.
May 13, 2009 11:44 AM|PowerK6|LINK
Outlook 2007 autodiscover service check URL as following sequence:
If all above failed, it will try to use DNS SRV records.
The first 2 URLs are SSL. When SSL is required, we must make sure that a valid security certificate is installed for the Web site that matches the site name. So,if you have 1000 customer domain names, you might need to purchase 1000 unique valid security
certificates and 1000 autodiscover websites? That's a nightmare!
So this 3rd http URL comes in. It redirects the Outlook to another HTTPS Autodiscover URL. That's the reason why you see in the Deployment Guide, we have to create an additional Web site in IIS just to do this redirection. And you will receive a security
alert when it redirect you to https://autodiscover.alpineskihouse.com/autodiscover/autodiscover.xml to auto-config your Outlook profile.In some case, your users will see a dismissible warning messaging asking them to verify that they are being redirected to
a trusted URL, you must advise them to accept this warning message and allow Outlook to connect to this trusted URL.(Check 'Don't ask me about this website again',then click allow button)
Please ref to Exchange 2007 Autodiscover Service White Paper:
May 13, 2009 05:47 PM|benjamin.bell|LINK
A couple of points... as people seem to be stating the primay steps of such a configuration which I think are well known and well documented, the issue is within the more complex detail and really relate to working ISA into the HMC deployment which is left
off the deployment walk through and thus kind of a hard to figure out....
This is a solution required for hosting, so we have to ignore the first HTTPS searchs for the autodiscover website, as it is not possible to have a ssl cert for every hosted email domain as stated by others here.
This leaves us with the HTTP option (and also the SRV) - and this HTTP option is where the ** issue ** is and only with ** ISA **
1. Outlook clients looks up autodiscover.clientsmtpdomain.com and gets a CNAME result pointing to autodiscoverredirect.hostingdomain.com
2. The outlook client should then post a GET for
3. The result of this, is a REDDIRECT to a SSL site,
4. The Outlook client will notify the user that it is redirecting, and will ask the user if this is Ok....
Okay - so the above is how it should work.... and if ISA is NOT there - that is how it works. The redirect website is held on the CAS Server on another IP address, is http only, and everything works, the client does a DNS Lookup on the autodiscover, receives
a CNAME response, looks up the result of that, finds the HOSTA pointing to the IP address of the HTTP 80 site on the CAS Server, gets a redirect instruction, and heads off to the hosting companies autdiscover SSL website and job done.
Put ISA in between the Outlook client and that http redirect website, and capture the TCP packets, and you find that ISA never pushes the request to the http autodiscoverredirect because it never receives a http GET for the **** result of the cname ****
it only ever gets the http GET request for the orignal client smtp domain, even though it using the IP address which has resulted from the CNAME and then the resulting HOSTA.... so this is the problem.....ISA never sees a request for autodiscoverredirect
website, and nothing works.
The only solution as I stated above - is to get any request for /autodiscover/autodisover.xml at ** any domain ** and redirect at the ISA Server to the SSL Autodiscover web site - thisd works - but it took a lot of head scratching, and I don't think it is
graceful nor best practice.
May 14, 2009 09:56 AM|DmitriG|LINK
you find that ISA never pushes the request to the http autodiscoverredirect because it never receives a http GET for the **** result of the cname **** it only ever gets the http GET request for the orignal client smtp domain,
Why do you think it MUST happened? Did you trace network without ISA? Try and you will see that Outlook NEVER use your CNAME as a host header in GET request for redirect check. It is always "autodiscover.clientsmtpdomain.com".
CNAME does matter ONLY for DNS, for name resolution to IP address. Period. You can't convince Outlook to treat CNAME differently since it is not even Outlook business to do name resolution, it's DNS client responsibility. All what Outlook wants is to connect
To make you ISA setup work, you have to accept ALL HTTP requests without checking host header. In you web site publishing rule, go to "Public Name" tab and select "This rule applies to: All requests".