Outlook 2010: Fixing "An object could not be found"

I just wasted most of a day troubleshooting Outlook 2010 giving me the error message, "The operation failed. An object could not be found."  I'd like to thank Malik Shadid, who wrote a long and very useful blog post that pointed me to the tools below that helped find the solution.

Important: There are MANY things that can cause this error, most of which I'm not remotely qualified to diagnose. Therefore, I cannot answer questions about these procedures. This post describes my experiences, yours may be quite different.

The symptoms were as follows:

• Outlook would give the "object could not be found" error when trying to download the Offline Address Book (OAB) from the Send/Receive | Send/Receive Groups | Download Address Book.
• Attempts to create a new profile in Outlook would hang for at least several minutes.
• Outlook 2007 and 2010 talking to Exchange 2007, all on a LAN.
• The LAN is a small business LAN that had a new provider and a new firewall/router. 
• Exchange was running under Hyper-V.
• Configured for direct RPCs, not RPC-over-http.
• The OAB did not have the latest changes from the GAL.
• The OAB had worked before the new router.
• The problem appeared on multiple computers.
• Outlook would connect and download mail/contacts/calendar successfully.

My first thought was that my firewall settings were wrong. Indeed, when I looked at the machine running Hyper-V, it had reset itself to be on a "Public Network" and was blocking many ports that it shouldn't have been. So this was the first thing I fixed. Unfortunately, this only made a minimal improvement.

 

HOSTS file

My next step was to check for DNS resolution. My domain was "abc.local" with the server name being "jupiter.abc.local". For the purpose of testing, I added abc.local, jupiter.abc.local, and jupiter to the HOSTS file in C:\Windows\System32\Drivers\Etc. After doing this, I pinged the host by the various names to make sure it worked. (You do not need to reboot after updating the HOSTS file.) Unfortunately, this didn't fix it either.

 

PowerShell

At this point it's important to understand that the OAB is a rather strange beast that sometimes uses a different set of protocols (and ports) than MAPI. The OAB can get the connection information from the Autodiscover.xml file, so it's critical that the Autodiscover.xml file be accessible, even in a small test environment. The actual process used to track down the AutoDiscover file is quite complex, as Malik describes in his TechNet blog.

To help find the Autodiscover file, there's an applet in the Exchange PowerShell called test-outlookwebservices that will give you ther URL, as well as telling you whether the server responds to basic "are you alive" tests. It's documented on this  TechNet Page. Here's an example:


[PS] C:\Documents and Settings\JimB>test-outlookwebservices | format-table -wrap -autosize
 
  Id        Type Message
  --        ---- -------
1003 Information About to test AutoDiscover with the e-mail address Administrat
                 or@abc.local.
1007 Information Testing server jupiter.abc.local with the published name http
                 s://jupiter.abc.local/EWS/Exchange.asmx & .
1019 Information Found a valid AutoDiscover service connection point. The AutoD
                 iscover URL on this object is https://jupiter.abc.local/Autod
                 iscover/Autodiscover.xml.
1006 Information The Autodiscover service was contacted at https://jupiter.abc
                 .local/Autodiscover/Autodiscover.xml.
1016     Success [EXCH]-Successfully contacted the AS service at https://jupiter
                 .abc.local/EWS/Exchange.asmx. The elapsed time was 31 millis
                 econds.
1015     Success [EXCH]-Successfully contacted the OAB service at https://hamme
                 r.abc.local/EWS/Exchange.asmx. The elapsed time was 0 millis
                 econds.
1014     Success [EXCH]-Successfully contacted the UM service at https://jupiter
                 .abc.local/UnifiedMessaging/Service.asmx. The elapsed time w
                 as 31 milliseconds.
1006     Success The Autodiscover service was tested successfully.

600 Error

To eliminate any firewall or routing issues, I first tried opening the Autodiscover URL in the browser on the server itself.

https://jupiter.abc.local/Autodiscover/Autodiscover.xml

This yielded the an error 600 with the following content:

<?xml version="1.0" encoding="utf-8" ?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response>
<Error Time="20:34:08.3587762" Id="147247660">
<ErrorCode>600</ErrorCode>
<Message>Invalid Request</Message>
<DebugData />
</Error>
</Response>
</Autodiscover>


A half hour of research indicated that the "600" error actually meant that it was working, but it wasn't authenticated. So the above result was actually good.

I tried the same URL from two client computers. It gave the same result in both cases. So all of this looked okay.

 

Connectivity Analyzer

Malik's blog also pointed me to a tool called the Microsoft Exchange Connectivity Analyzer (beta). (Requires .Net 4.5.) Get the tool from:

https://www.testexchangeconnectivity.com/

After starting the Analyzer, click the Client tab, download the file and install it.

The results of this finally showed me the problem, which was that autodiscover.abc.local wasn't resolved by DNS. I put that domain in the HOSTS file, tried the Connectivity Analyzer again and... it failed again. But it got further than last time.

I chased down the errors by clicking the little arrows under each error message in Analyzer. By drilling down, I discovered that it didn't like that my server certificate was for jupiter.abc.local instead of *.abc.local. Fortunately Outlook doesn't care about this, so Outlook works even if the Connectivity Analyzer does not.

The other domain names I mentioned at the beginning of this article also had to be in the HOSTS file, so that effort wasn't wasted.

Test E-mail AutoConfiguration

The next step was to go to a client and use an undocumented feature in Outlook 2007/2010 to test the Autodiscover resolution. Ctrl-right-click the Outlook notification icon on the right in Windows. Select Test E-mail AutoConfiguration. Enter your Exchange email address and your password. Make sure Use AutoDiscover is checked. Click Test.

If it's successful, you can switch to the XML tab and see the Autodiscover.xml file.

 

Wrapping Up

Finally I backtracked to find out why changing the router broke everything. It turns out that the old router was configured to forward all DNS requests to the Windows Server, which knew how to resolve *.abc.local to the proper server. Anything else was forwarded to Google's DNS. (Google's public DNS servers are blisteringly fast and are definitely worth using. Their IP addresses are 8.8.8.8 and 8.8.4.4)