Outlook clients receive error 0x8004010f when downloading the Offline Address Book

EDIT 10/01/2008: To read the updated (and more comprehensive) guidance for troubleshooting errors 0x8004010f, please go here.

There are a multiple reasons for why an Outlook client can receive the 0x8004010f sync error. Unfortunately, 0x8004010f is just a generic MAPI error and will show up for a variety of problems.

Here is what the error looks like under err.exe (Microsoft Exchange Server Error Code Look-up Tool):

C:\WXP\system32>err 0x8004010f
# for hex 0x8004010f / decimal -2147221233
ecNotFound                                       ec.h
ecAttachNotFound                                 ec.h
ecUnknownRecip                                   ec.h
ecPropNotExistent                                ec.h
MAPI_E_NOT_FOUND                           mapicode.h
# 5 matches found for "0x8004010f"

This is what the error looks like from the sync log from within Outlook:

12:45:53 Synchronizing Mailbox <dgoldman>
12:45:53 Done
12:45:54 Microsoft Exchange offline address book
12:45:54 0x8004010f

Some of the most common reasons for Outlook clients to receive the 0x8004010f error with regards to downloading the OAB are listed below. Most of these are documented and I have linked articles to each of these to help everybody out. Please note that these solutions can change a small bit depending on unknown factors in a company's environment.

  1. An administrator decommissioned the last Exchange server in a site and never pushes replicas to another Exchange server.
  2. A new OAB is created in the active directory and the information store never reads the active directory during its maintenance schedule. This will result in the OAB files never being generated and the Outlook client will fail to download anything.
  3. The information store has an invalid EntryID that points to the legacy EX:/ folders. Again there is nothing for the client to download.
  4. An outlook client logging in from one domain to another domain and attempting to log in to another users mailbox.
  5. The OAB was never generated or some OAB folders are missing from the public folder store.
  6. Multiple OAB Version folders exist of the same type.
  7. Clients are attempting to download the OAB files from a public folder store that have not received the replicated updates.
  8. The offline address book list object has a missing address list.
  9. The offline address book list object has an incorrect address list.
  10. Send/As changes in the store affect users accounts with no mailbox full rights to another mailbox.

If you are seeing this error on an Exchange 2007 server and your OAB is generated by an Exchange 2007 server, please make sure of the following:

1. Make sure that you have added the replicas of OAB to the Exchange 2007 server

2. Make sure public folder replication is working.

3. Make sure the OAB is public folder enabled and you have OAB Version 2, OAB Version 3 and OAB Version 4 checked off so your legacy clients can download the OAB files from the public folder store.

4. Make sure that if you are using an Outlook 2007 client, your OAB is Web Distribution enabled and the OAB files have been replicated over to the Client Access Server. For more information on this process please see this blog:

http://blogs.msdn.com/dgoldman/archive/2006/10/23/outlook-client-fails-to-download-the-oab-with-error-0x8004011b.aspx and

5. If you are removing your last Exchange 2003 server from the org, please make sure that you follow our documentation on this process.

- Dave Goldman

Comments (11)
  1. jbourget says:

    excellent post!

  2. ashrond says:

    make shure that you bound the offline address list to the primary storage group, under

    server configuration, mailbox, database management.

    this held me up for two weeks and it was the only issue not gone over anywhere i looked, i accidetly stubled accross it in a blog.

  3. Dev says:

    Here’s what worked for me:

    Assuming all the following are true, the problem is likely a public DNS issue:

       * You have configured the OAB for web distribution correctly.
       * The client computers having this issue are located across a security device or outside your corporate network (The Internet, etc.) where your internal DNS records are not replicated.

       * These clients are using the Outlook Anywhere feature in OL2007.  

    Apparently, the OAB download activity is handled by the Autodiscover feature in OL2007.  When downloading the OAB, Outlook tries to connect to a web services Url found on the Client Access Server that resides in an IIS virtual directory called "autodiscover",
    and access a file called "autodiscover.xml".  If the OAB is not configured correctly for web distribution, this file will likely not exist, and your day will be ruined.  On the other hand, if the file exists, then you should be able to test client connectivity
    to the web service by doing the following:

      1. From the client machine, open a web browser.
      2. Navigate to http://<mail-server&gt;.<your-email-domain-name>.<ext>/autodiscover/autodiscover.xml.

      3. Enter your credentials when prompted.

    You will get a 600 error.  This is ok.  It means you are connecting to the autodiscover service, and that you don’t have an issue with access to the web service from the client.

    By default, Outlook will look for and try to connect to the following preset Autodiscover web service Urls in this order when looking for the "autodiscover.xml" file:

       * https://<your-email-domain-name&gt;.<ext>
       * http://<your-email-domain-name&gt;.<ext>

    In a nutshell, if you don’t have a public DNS "A" record for "autodiscover.<your-email-domain-name>.<ext>", then your OAB downloads will fail miserably, and you will get "0x8004010F" synch errors in Outlook.  Since public DNS records take 24 to 48 hours to
    replicate and become effective, you will likely need a workaround during that time.  The easiest interim fix is to modify the client computer’s hosts file to include an entry for the autodiscover host name, binding it to the ip address of the CAS or mail server.
     For example:         autodiscover.your-email-domain.com

    This is just an educated guess, but it is likely that the reason internal clients (domain member computers) that are configured to use Outlook Anywhere (like laptops) don’t have this issue is because of the integrated nature of DNS and Active Directory.  Even
    though you probably don’t have an "A" record for the "autodiscover" host internally, Outlook still seems to connect to the web service just fine.  I would be interested to know if my thoughts on this are accurate, but I have already spent enough time on this

    Good luck!

    To test autodiscover follow this
    Test-OutlookWebService mean in outlook 2007 "Test E-mail Auto configuration.." . In system tray on outlook icon Ctrl+right click outlook icon and select test email configuration…….

    In Email Address please type any email address which in exchange 2007 mailbox and password run test.

    When finished please check the log see the autodiscover and web service is success or not.

  4. John Jankowski says:

    After several weeks of troubleshooting and reading, my problem was finally resolved by doing what "ashrond" above suggested.  Simply selecting the respective Offline Address Book as follows resolve my error 0x8004010F when clicking Send/Recieve in Outlook 2003 with an Exchange 2007 server:

    RESOLUTION: Bonded offlne address list to primary storgage group; Exchange Management Console=>Server Configuration=>Mailbox=.Database Management tab=>

    First Storage Group Properties (right click and select properties)=>Client Settings tab=>Offline Address Book field=>click browse button and select the respective OAB defined on the system.

    Thank you very much . ..

  5. Daniel says:

    You don’t want to select First Storage Group, you want to select Mailbox Database.  Otherwise you won’t see the Client Access tab.

  6. David W. says:

    Thanks ashrond  worked like a charm!

  7. Daniel says:

    What do you mean by

    1. Make sure that you have added the replicas of OAB to the Exchange 2007 server

    How do I do that

  8. tom says:

    I am getting a different error message on my Exchange 2007 box that states:

    9:10:52 Microsoft Exchange offline address book

    9:10:52 Not downloading Offline address book files.  A server (URL) could not be located.

    9:10:52 0X8004010F

    I followed all the steps above to no avail. The error hits once a minute and I now have 20,847 error messages in my Outlook 2007 Sync folder.

    Has anyone been able to resolve these?

  9. JailBreak says:

    I had the same problem, but the solution from John Jankowski works for me.

    But he only problem that i have now is i cannot receive emails from account that i created from the Exchange 2007.

    I have no errors, just don’t receive any. But i can send with no problem


  10. The error "A server (URL) could not be located." is a bit different with regards to the Outlook client looking for an OAB URL and not getting one. Outlook 2007 clients use the Autodiscover service to retrieve the URLS for the services (OOF, OAB, etc). I would turn up logging for Outlook and restart the client then check your %temp% and look for the oldisk.log file. In addition to that I would run the Get-ClientAccessServer cmdlet and see if something is misconfigured. http://technet.microsoft.com/en-us/library/bb124785.aspx

    Also if you are trying to download the OAB externally you need to set up the External URL and Outlook Anywhere services.

  11. Sebastian Wolter says:

    I think I have found a 11th reason.

    If the client profile is created while the senders email address domain is not the one in the certificate, this error will occur.
    It can be changed again to any domain once Outlook has downloaded the OAB.
    Don’t know i fit will be updated than, cause we don’t use it.

    Tested with Outlook 2007 and Exchange 2007 on a DynDNS server with selfcert.

    For more details (german) see my post on http://www.mcseboard.de/post10-714897.html

Comments are closed.

Skip to main content