A while ago, the company I currently work for updated their servers to Exchange 2010. Ever since, I was unable to view other people’s calendar and free/busy information. The only error I got was a 'no connection’ message in the calendar tab.
I was using Outlook 2010 on a computer that was NOT part of the domain.
When searching the internet, I noticed that I wasn’t the only one suffering from this behavior, but I couldn’t find an answer for the problem.
I turned on logging in Outlook (File – Options – Advanced – Enable troubleshooting logging) and found that the log file (%temp%\olkdisc.log) was filled with error from the Autodiscover service)
This led me to this Outlook 2007 article on TechNet which explains the relationship between the Autodiscover service and the Availability service:
The Availability service for Microsoft Exchange Server 2007 provides calendar information for your users. This information is known as free/busy information. The Autodiscover service provides information for the Availability service by locating and providing the external and internal URLs for the Outlook 2007 client. If your Microsoft Office Outlook 2007 users cannot view calendar information for other Outlook 2007 users in your Exchange 2007 environment, the problem may involve a failure in either the Autodiscover service or the Availability service.
The article provides the following steps to test the Autodiscover service (the article is for Outlook 2007, but the steps are the same for Outlook 2010):
- While Outlook 2007 is running, hold down the CTRL key, right-click the Outlook icon in the notification area, and then select Test E-mail AutoConfiguration.
- Verify that the correct e-mail address is in the box next to E-mail Address.
- Clear the check boxes next to Use Guessmart and Secure Guessmart Authentication.
- On the Test E-mail AutoConfiguration page, verify that the check box next to Use AutoDiscover is selected, and then click the Test button.
I my case, the test failed because of the Autodiscover services could not be reached.
As it turned out, the Proxy server could not reach the Autodiscover service. I used Internet Explorer to add the url to the ‘Local Intranet’ zone, so the proxy server would be bypassed and everything worked perfectly.
Hi. Thanks for this solution. Can you explain in a bit more detail what you mean by 'As it turned out, the Proxy server could not reach the Autodiscover service. I used Internet Explorer to add the url to the ‘Local Intranet’ zone, so the proxy server would be bypassed and everything worked perfectly.' Assume I'm an idiot! thanks
ReplyDeleteThe free/busy information is provided by the Autodiscover service, which is usually accessed over an url like https:///autodiscover/autodiscover.xml
ReplyDeleteAs my computer was not part of the domain network, it did not consider the url as part of the local network, and therefor, it tried to access it over the proxyserver. And that proxyserver didn't have access to that url.
By putting the url in my 'Local Intranet' zone, it was no longer accessed throught the proxyserver but directly (and that worked for me)
One of our users with Outlook 2007 had the problem - used to be able to view other folks calendars connecting through Global Address Book, then started failing to connect. Failed to Connect message. Finally closed Outlook, opened Mail icon from Control Panel, deleted her account, then re-added her account and all calendars were available again. We use Exchange 2007, no .pst files, messages are stored on server.
ReplyDeleteYour steps to fix did not quite work for me.
ReplyDeleteBecause our email address's differ from the domain name I had to add an entry into the hosts file to resolve.
I tested this by turning on the logging as you suggest which confirmed which url was being used for the autodiscovery service.
I repeated this on a known working system to find a working autodiscover url.
I then tested again in a browser by navigating to working https://autodiscover.domainname.com ahhh a certificate popped up, then the non working one and it fails.
in a cmd prompt ping the autodiscovery of the working one.
and add an entry in the windows/system32/drivers/etc/host file for the working IP and the non working url ie
xx.xx.xx.xx autodiscover.domain.com
And the issue is resolved re test in a browser.