Tag Archives: AutoDiscover

Outlook 2007/2010 on Windows XP Cannot Connect to Availability Service with Exchange 2007/2010

I ran in to an interesting issue recently with some users reporting that they could not see Free/Busy information. Upon further discovery, I found out that they couldn’t use the Out-of-Office Assistant either. The immediately tipped me off that we had some sort of issue Availability/AutoDiscover.

We narrowed it down to our users using Windows XP and Outlook 2007. Our Windows 7 Users with Outlook 2010 and our Windows XP users with Outlook 2003 were unaffected.

This coincided with our deployment of some additional Client Access Servers in a new site. It seemed like it had to be related, but I couldn’t immediately think of how.

All of our Exchange 2010 AutoDiscover tests were successful, and the Best Practices Analyzer didn’t reveal anything telling. The Application Log was clear as well.

So, if our Exchange 2010 infrastructure was testing out fine, and there really wasn’t anything apparently wrong with the client PCs either, then what could be the problem?

The answer came when I tried to browse directly to the /owa virtual directory on one of the new client access servers via HTTPS. I got “Page cannot be displayed” and nothing else, even though it worked fine from Windows 7.

It turns out there is a “gotcha” when creating CSR’s with Windows Server 2008 R2.
 
When the original SSL certificate request was created for the new Client Access Servers, it was created using Windows Server 2008 R2 using the non-default “Legacy Key” custom request. This causes the private key to be stored in Microsoft’s Legacy Cryptographic API framework.
 
However, Internet Information Services, under Windows Server 2008 R2, will try to process the request using its brand new Cryptographic Next Generation (CNG) framework… which works with the Legacy Key, but has some limitations. Specifically, it will only support two AES cipher suites:

  1. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  2. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

…and those two AES cipher’s are not supported by Windows XP by default.
 
Therefore, an SSL certificate that is the product of a Legacy Key CSR will result in an SSL failure between Windows XP and Server 2008 R2.
 
To fix it, you need to generate a new CSR using the default “CNG Key” (which supports numerous ciphers under Server 2008 R2) instead of “Legacy Key” and issue the certificate with your favorite signing authority. Then just apply it to your Client Access Servers and you should be good to go. Don’t forget to assign the IIS services to the new certificate using the Exchange Management Console/Shell.
 
Be careful though, not everything in your Exchange 2010 technology stack is compatible with a CNG-based certificate request. I know that because I ran into issues when I chose the default selection “CNG Key” for a certificate on Threat Management Gateway 2010 and found that it was not compatible.

So, having already been through troubleshooting that during the deployment of TMG, “Legacy Key” seemed like the safe (and logical) choice when generating CSR’s for use with our Client Access Servers.

Had I not done that though, I wouldn’t have had this problem, and I wouldn’t have written this article… which means you would still be looking for a solution.

Critical Commands to get Autodiscover Working Properly in Exchange 2010

The AutoDiscover server in Exchange 2007/2010 can be particularly troublesome, and since it effects just about everything in Outlook 2007/2010 (such as the Out of Office Assistant and Free/Busy Status), it’s absolutely critical to get right.

When you break it all down though, there are really just three steps to ensuring your AutoDiscover service is configured correctly in Exchange.

Helpful Hint: I would highly suggest using separate SSL certificates on for your External servers (such as TMG) from your internal servers.  We used a public SSL certificate (GeoTrust) on our TMG servers for webmail (with a subject like mail.ExternalDomain.com).

However, on our internal Exchange servers, we used an internally signed cert that not only contained mail.ExternalDomain.com, but also contain alternative names with all server names in the Exchange organization… short names and FQDN’s.  This allowed everything to work together happily.

Contrary to popular belief, even if you are using multi-role 2010 servers, there is absolutely no requirement that the mail.ExternalDomain.com certificate be the same as the one installed on TMG.

Back to the subject at hand.  First, check the settings for the AutoDiscoverServiceInternalUri by running this command:


Get-clientAccessServer | fl Name,AutoDiscoverServiceInternalUri

Everything look right for how you think Outlook should see the server?  If not, then use this command to set it right:


Set-ClientAccessServer -Identity ClientAccessServerName -AutodiscoverServiceInternalUri https://ClientAccessServerName.InternalDomain.local/autodiscover/autodiscover.xml

Now, let’s look at the Offline Address Book.  This is actually available in the Exchange Management Console, so it’s easier to see the current settings or adjust it there.  However, if you want to be doubly sure, you can set it from the Exchange Management Shell with these commands:

Internally…


Set-OABVirtualDirectory -Identity " ClientAccessServerName\oab (Default Web Site)" -InternalUrl https://ClientAccessServerName.InternalDomain.local/oab

…and Externally


Set-OABVirtualDirectory -Identity " ClientAccessServerName\oab (Default Web Site)" -ExternalUrl https://mail.ExternalDomain.com/oab

Finally, the one that is most vexing and poorly documented, the Exchange Web Services themselves.  First, check the settings for the WebServicesVirtual Directory by running this command:


Get-WebServicesVirtualDirectory | Select name, *url* | fl

Everything look right?  Probably not… this one is a mess out of the box, and while you would think the settings would be copied from the EMC settings, but they are not.  To correct them, use these commands:

Internally…


Set-WebServicesVirtualDirectory -Identity "ClientAccessServerName\EWS (Default Web Site)" -InternalUrl https://ClientAccessServerName.internaldomain.local/ews/exchange.asmx

And Externally…


Set-WebServicesVirtualDirectory -Identity "ClientAccessServerName\EWS (Default Web Site)" -externalUrl https://mail.ExternalDomain.com/ews/exchange.asmx

Hopefully I’ve saved you some hours of beating your head against the wall like I did!