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.
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:
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.
