I am always amazed by the amount of customers running Exchange 2007 or Exchange 2010 and NOT using Autodiscover. Their response is always “we don’t need it” and “we configure the Outlook profile manually”. In Exchange 2007 and Exchange 2010 you can get away with this (you cannot with Exchange 2013 and Autodiscover is mandatory) but when you want to implement a hybrid scenario with Exchange online you really need Autodiscover since Exchange Online uses Autodiscover to find relevant information regarding your on-premises Exchange environment.

Recently a customer with Exchange 2010 wanted to build a hybrid environment with Exchange Online, and one of my first findings was the lack of Autodiscover. So, after configuring their Exchange environment and creating the necessary DNS records Autodiscover was working properly as shown in the following picture:

For those that have a closer look at this figure and it’s warning message on ‘Attempting to test potential Autodiscover URL’, this is caused by the validation of the certificate trust so nothing to worry about.

After running the Exchange Hybrid Configuration wizard we started testing and soon found out that free/busy was not working properly. Retrieving free/busy information from Exchange 2010 on-premises to Exchange Online was working fine, but retrieving free/busy information from Exchange Online to Exchange 2010 sometimes failed. For some users on-premises it worked fine (spread across the company, not just one or two departments, it seemed totally random) but for some users it failed and no free/busy information was shown at all, just the grey and striped bars…

Autodiscover for this particular user was working fine as shown in the first two pictures, but when running the Microsoft Exchange Web Services Connectivity Tests on the Remote Connectivity Analyzer an error was raised saying The remote name could not be resolved ‘ams-exch01.labs.local’.

This is odd since this is the internalURL on the Exchange Web Services while all externalURL settings were configured correctly.

Going back to the original Autodiscover test using the Remote Connectivity Analyzer I found that the XML response returned from the Exchange 2010 Client Access server to the Outlook client was missing information as shown in the following figure:

The EXCH and WEB nodes are returning the correct (internal) information, but the external information that’s typically shown in the EXPR node for Outlook Anywhere was not available.

When asking the customer about this it turned out that Outlook Anywhere was only enabled for a limited set of users and that it was disabled for most users. This was a security requirement to make sure that users would not access the Mailbox using Outlook (and thus creating an OST file) on a non-managed PC. Outlook Anywhere was disabled on a per-user basis using the Set-CASMailbox command.

When enabling Outlook Anywhere for a user with the Set-CASMailbox $alloweduser -MAPIBlockOutlookRpcHttp:$False command I did another test with the Remote Connectivity Analyzer. Clearly visible is that the Client Access server returns all information that’s needed by the Outlook client and that all nodes contain the proper information as shown in the following figure:

Note. The WEB node is not shown for readability purposes.

When testing the free/busy information with this information I found that free/busy information was not available for users that had Outlook Anywhere disabled. The solution for this was to enable Outlook Anywhere for all users. So, not only Autodiscover is mandatory for a hybrid scenario, so is Outlook Anywhere.

Update November 5, 2014: Michael van Horenbeeck pointed me to the following Microsoft knowledgebase article that describes this issue as well: http://support2.microsoft.com/kb/2734791