Technology for Mortals

To put it plainly, someone completely forgot to document Exchange 2007. The OAB (Offline Address Book) issues that were present in previous editions are still there. The sad part is, the problem is documentation, not technical. Over the last month or so, I have been wrestling with OAB issues for at least 20 hours per week. About 30 minutes ago, I conquered them for good. Here is everything that I have learned along the way, hopefully it will spare you some trouble.

The error that we usually get in Outlook is “an object cannot be found”. The Synchronization Log shows that it could not get the Offline Address Book (to see the log, go to the “Folders” view and select the “Sync Issues” folder). Additionally, you’ll possibly get an error code of 0x8004010F during a Send/Receive. Here are some of the causes I have found for this:

The OAB does not exist at all
Verify that the OAB has been created. Turn up the logging level on OAB in Exchange and force a re-creation of it. Verify that there are no errors. If there are errors, fix them.

The OAB is in the wrong place or inaccessible
After creating an OAB, you need to restart Outlook to get the new location. If you still get the error, check the IIS logs on the server hosting the Exchange Mailbox role. Look for entries trying to do a GET on /OAB/* which will be Outlook trying to get the OAB. If there are errors, fix them. A few common problems with this:

• The OAB directory requiring SSL; all of the other Exchange directories require SSL, but OAB should not.
• The OAB virtual directory is pointing to the wrong spot. I deleted the default OAB and created a new one, but the new one was in a physical path different from the physical path of the old one (not just the GUID of the OAB, but the entire path was different!). I had to re-target the OAB virtual directory in IIS to get it looking in the right spot.

The path is being blocked by a firewall/ISA
If your problem only crops up when the user is trying to get access via “Outlook Anywhere” (or RPC or HTTP), make sure that what you’ve published in the firewall or ISA server is allowing the path /OAB/* through to the correct server.

Missing entry for autodiscover in DNS
This was my final “gotcha” to overcome. After spending hours doing packet captures, I noticed that on a clean DNS table and a fresh Outlook start (in other words, close Outlook 100%, do “ipconfig /flushdns” and start Outlook) I saw that Outlook was trying to lookup “autoconfigure.domain.com” as a host, and when that failed, it was hitting “_autoconfigure._tcp.domain.com” as an SRV record. Making an A or a CNAME record for autoconfigure.domain.com is silly, since I would need to spend money on another SSL certificate for it. Actually, that is debatable, since the only clients trying to hit that address should be clients that already trust my internal root CA, so I could self-issue one. But I digress. To make things slightly less chaotic (do I really need to publish Yet Another Host Name in ISA anyways?), I simply added an SRV record for “_autoconfigure._tcp.domain.com” with the data of “0 0 443 mail.domain.com” (mail.domain.com is the external address for the Exchange server, which already has a cert on it and it is the name of the Exchange proxy server, etc.). Once I did that, the last of the problems were solved.

I hope this helps someone. I’ve seen some of these items listed elsewhere (sadly, the bits on autoconfigure turned up on my final search, in tabs that I checked after I resolved the problem!), but never all of them in one spot.

J.Ja