/var/log

For the longest time, it was a burr embedded in my side.

With ISA servers standing guard in front of our Exchange Server 2007 installation and having a UCC (or SAN) SSL certificate installed, Outlook (2003 and 2007) users on Windows XP were having the hardest time getting access to Exchange via Outlook Anywhere.

As it turns out, the problem turned out to be simple enough: one simple little check box.

The problem has to do with the unique combination of Outlook, ISA 2006 SP1, Windows XP and Exchange Server 2007. Our UCC/SAN SSL certificate has the principal name of mail.company.com but also has owa.company.com and autodiscover.company.com on the same certificate.

ISA was set up to have the public name of autodiscover.company.com “redirected” by a rule to the protected, internal web farm name of mail.company.com. When Outlook clients presented themselves for connections through Outlook Anywhere (RPC over HTTP) to the ISA box by using autodiscover.company.com, they obtained the SSL certificate for mail.company.com.

With the check box checked, Outlook clients compared the SSL certificate they got (mail.company.com) to the URL to which they were connecting (autodiscover.company.com) and summarily rejected any connections but there was no error beyond prompting over and over and over for credentials.

Initially, I didn’t think there was a problem because my box which is running Vista didn’t have a problem. I think Vista was able to handle SAN SSL certificates.

I’m not sure; requires some research.

Whatever the case, I have instructed all users attempting Outlook Anywhere access to uncheck that box and life’s all right. Of course, if I’d been the one to set up the ISA firewalls, I’d have ensured that the web farm field was set to autodiscover.company.com and had the same as the principle principal name on the SSL certificate.