Freigeben über

The case of Outlook Autodiscover and Error 0x80072ee4

  • Artikel

I had a customer who was having issues with a certain subset of Windows 7 machines. The issue presented itself as "users are unable to set out of office (otherwise known as oof) settings from within Outlook". Upon syncing up with the client, I had them do a quick test to see if we could see availability for other users when attempting to create a meeting request. We could not, so given the fact that both oof and availability were broken, this was a pretty clear sign that Autodiscover was not functioning properly for these Outlook 2007 clients.

These were domain joined machines, which means we would be contacting Active Directory to get our Autodiscover url. Since this problem was only affecting a small subset of machines, it was assumed that autodiscover was properly configured in the environment. So, from an affected client we hovered over the Outlook icon in the bottom right corner of the machine, held down the ctrl key and right clicked, and ran Test E-mail Autoconfiguration. Since this was a domain joined client there was no need to enter credentials, so we just unchecked the "Use Guessmant and "Secure Guessmart" boxes, and hit the Test button (there should be no need to change the default populated E-mail address OR enter a password on a domain joined machine).

During the test, Outlook contacted the SCP like it should, but then returned an error I had never seen before...0x80072ee4.

Looking this error up, I found the following information...

 ERROR_INTERNET_INTERNAL_ERROR                                  inetmsg.h
 ERROR_WINHTTP_INTERNAL_ERROR                                   winhttp.h
 ERROR_INTERNET_INTERNAL_ERROR                                  wininet.h

So, now I felt like we were getting somewhere, but I still wasn't quite sure yet "where" this was :)

Sometimes proxy configurations can interfere with Autodiscover communication, so we entered the autodiscover SCP value (in the form of https://exchangeservername.domain.com/autodiscover/autodiscover.xml) into the client's web browser, and we got the expected response (an xml page with a 600 error). I felt like this ruled out any possible proxy configuration issues (even though we excluded the proxy in other ways).

In the past I have seen non Microsoft programs cause this type of problem, so we decided to "clean boot" the machine as described here: https://support.microsoft.com/kb/331796

We also disabled all non-Microsoft Outlook add-ins as described here: https://office.microsoft.com/en-us/outlook-help/enable-or-disable-add-ins-in-office-programs-HA010034127.aspx

We then rebooted the machine but were still out of luck :(

Feeling like I was running out of options, I decided to do some netsh tracing, as described here: https://technet.microsoft.com/en-us/library/dd878517(v=WS.10).aspx, using the "internetclient" scenario. Upon reviewing the trace, I found that none of the traffic seemed to be getting past winsock.

As a last ditch effort, I had the client reset winsock by running the following from an administrative command prompt:

netsh winsock reset

This command requires a reboot, and after rebooting we found that Outlook was now able to successfully contact Autodiscover (which also fixed our oof and availability issues). It turns out that a program that had been installed on the affected machines had modified Winsock in such a way as to break Outlook communication over SSL back to Exchange.

Hope this information helps you out if you ever happen to run into this error :)

Comments

  • Anonymous
    July 16, 2013
    Thank You!

  • Anonymous
    March 25, 2015
    Bravo! Thank you.