November 2009

In my post “Exchange 2007… Better Later than Never” I mentioned one of the post-deployment difficulties I faced was getting the "AutoDiscover” function to behave the way it was designed. For those unfamiliar with the feature, it allows for automated discovery and configuration of various connectivity methods to an Exchange Server. Exchange MAPI clients, Exchange HTTP/RPC clients, and mobile devices using ActiveSync all can use AutoDiscover in some form or another.

While it wasn’t critical for the transition itself, AutoDiscover was vital for our future deployments of “Outlook Anywhere” and “ActiveSync.” I figured skimming over a few TechNet articles and blog postings, and I’d be quickly onto the next project. That began my long ugly journey getting AutoDiscover to work.

It became clear that the ingredients for AutoDiscover to work correctly was a properly configured ISA Server, SSL certificates, namespace/DNS accommodations, and of course, Exchange. What was really interesting about this particular project was that I was dealing with very mature products, yet, I never ran across so much contradicting information on how to make it work. Perhaps some of that stems from so many valid topologies and configurations, or possibly big changes between the RTM versions of Exchange and ISA and their first service packs. Still, it seemed odd. I sifted through postings from desperate IT Administrators in similar situations who had no more hair to pull out. You could sense the defeat in their words. Now I understand.

One guideline mentioned quite often was the need for a special SSL certificate that allowed for more than one FQDN to be assigned to it. You’ll see it referred to as a Unified Communication Certificate (UCC or UC) or a Subject Alternative Name (SAN) certificate. The purpose is the same, but the names and the references are different. While UC certificates are not technically a requirement, it is best to think of it that way. For AutoDiscover, the names needed on a UC cert would look something like:

mypubliccompanyname.com
autodiscover.mypubliccompanyname.com
mail.mypubliccompanyname.com
internalmailservername
internalmailservername.myprivatelanname.lan

I went with a UC cert from DigiCert, but any of the larger commercial CA’s should work. However, a word of warning. Exchange doesn’t like self signed certificates, and many mobile phones have troubles with private certificates as well as those from smaller commercial CAs. You should be fine if you run Certificate Services internally (or so I’m told), and your namespace checks out okay. Don’t forget look at your ISA server and make sure you are running SP1 or later, due to limitations on how the RTM version handled UC certificates.

Speaking of namespaces, time for a thorn in my side to come back and sting me. My internal namespace is not a name that we own (a legacy issue I should have taken care of long ago). Certificate Authorities will not issue standard or UC SSL certificates to names you do not own for obvious reasons, even if the references are private. Fortunately, I was able to work around this by making absolutely sure the simple name was used in any Exchange configuration settings that usually accepted the internal FQDN. Disaster averted.

Now for the dirt on how I was able to make it work. My as-built design is modeled somewhat after Jason Jones’ method of Publishing Exchange 2007 Services with ISA 2006. Following the construct of:

Not using the existing listener created for OWA, and creating a separate listener for Outlook Anywhere (OA)/Autodiscover, and binding UC cert to that listener. Using HTTP authentication with Integrated/Windows Auth (aka NTLM). This would provides HTTP/Integrated auth from the client to the FW, then basic auth from the FW to the Exchange server.
Allowing the ISA server to utilize Kerberos constrained delegation (KCD) by way of changes in AD.
Creating a single Publishing rule for OA , where KCD is used.
Setting internal and external URL’s to their respective internal and external locations (internalmailservername and autodiscover.mycompanyname.com)

After configuring it as above, AutoDiscover worked internally, but not externally. Continually getting failures with the /rpc directory when testing internally (via test-outlookwebservices) and externally (via testexchangeconnecivity.com). I found a post that gave the missing piece of the puzzle, and modified my configuration per the recommendations http://forums.isaserver.org/m_2002041377/mpage_2/key_/tm.htm:

Create a 2nd Publishing rule for OA, sitting on top of primary OA publishing rule.
- Only /rpc/* is published
- Auth Delegation is set to "No Delegation, but client may authenticate directly"
- Set to "all users" instead of "authenticated users"
- Changing "EXPR" Outlookprovider to msstd:mail.mycompanyname.com so that the certificate mutual authentication test passes.

Under the conditions described above, Outlook Anywhere with Autodiscover functions as desired.

As Jason Jones put it best, “The reason for the need of a separate listener is that Windows Authentication (NTLM) and Forms Based Authentication (FBA) are mutually exclusive. It is not possible to use a single web listener for all Exchange 2007 publishing and achieve transparent authentication within Outlook anywhere.” Thus the need to create a dedicated listener to be used exclusively for Outlook Anywhere and associated services.

I did have to make one other adjustment that is rarely brought up in the AutoDiscover deployment scenarios. We know that AutoDiscover wants to look at your TLD name (e.g. yourpubliccompanyname.com) when doing it’s discovery process. However, you may have simply had an “A” record of “yourpubliccompanyname.com” pointing to your web server to catch those users who forget to type in “www” before your domain name. It’s also not a far fetch to assume you had an SSL certificate bound to that web server as well. This is exactly what I had, so I had to make the following changes:

1. Have our ISP (or whomever has authoritative control on the DNS zone file for “mypubliccompanyname.com”) change the “A” record from my public web server IP address, to my autodiscover address.

2. In ISA, add a new “DENY (REDIRECT)” rule for mypubliccompanyname.com that does, well, a deny, and a redirect www.mypubliccompanyname.com. This sits right above the web publishing rule for www.mypubliccompanyname.com

The original setup was a carryover from an earlier time. The configuration above is the way I should have set it up. Nice to do a little cleanup along the way.

I can’t tell you how relieved I was in getting this to work, no matter how many hoops I had to jump through. I also have a complete set of as-built notes in case I need to recreate or debug the existing configuration. It’s been stable since, but I have a feeling I’ll be looking at this again as soon as we transition to Exchange 2010.

Month: November 2009

Discovering AutoDiscover in Exchange 2007