Troubleshooting the Outlook Send/Receive with error 0x80040119
Another problem I have seen in the newsgroups and floating around on the Internet is that people are getting 0x80040119 when they try to download their Offline Address List.
Ok, so lets start by troubleshooting this guy.
One good troubleshooting step is to examine the HRESULT code that was returned and see what it is. I used err.exe on the error code 0x80040119, and what is returned is the following:
C:\WINXP\system32>err 0x80040119
# for hex 0x80040119 / decimal -2147221223
MAPI_E_EXTENDED_ERROR mapicode.h
# 1 matches found for "0x80040119"
Well, that was not too helpful this time, all we got back was an extended error. Since this is a rare instance where err.exe was not helpful with the error code, I need to reply on my knowledge of the Outlook client.
Since I know the inner workings of the Outlook client when it comes to OAB, I know that the client needs to obtain the correct Entry ID to the OAB system folders before it can download the OAB files. This Entry ID is called the PR_ADDRBOOK_FOR_LOCAL_SITE_ENTRYID. Once the Outlook client has this Entry ID it can then call OpenEntry and try to access the OAB message and attachments. Now for what ever reason if the Outlook client can not access the OAB Folder it was trying to download from (let's say OAB Version 4), it will fall back will try the OAB Version 3 and then OAB Version 2.
For more information on what your Outlook client did the last time it downloaded the OAB, see this blog: Is your Outlook client downloading an ANSI or Unicode OAB?
I know that there are two ways for an Outlook client to find out what Offline Address List it needs to go after.
1. Use the msExchUseOAB attribute that is stamped on the user account object in the Active Directory. This tells the client which OAB to download.
2. Read this attribute off of the mailbox store that my mailbox resides on. You can very this from the properties of the Mailbox Store using the Exchange System Manager.
NOTE: In the hosting world we use the msExchUseOAB attribute to override the default store Offline Address List. The reasoning for this is that in hosting there are multiple companies and each user needs to download their own specific OAB. Now If you populate this attribute on a user account, this will override the mailbox store default settings. This can also cause problems if the attribute is populated but not pointing to a valid Offline Address Book.
Well, since we are not in a hosting environment, I do not have that attribute populated on my user account in the Active Directory. This data points me to one location, my mailbox store.
So the next step in troubleshooting is to look at the mailbox store to see if there is a Default Offline Address List associated with it. This can also be done two ways:
1. Open the ESM (Exchange System Manager) and navigate down to the server and mailbox store. From here you can retrieve the properties for the mailbox store. If there is no Default Offline Address List populated, then I can then fix it there by selecting one and populating this. This will stamp the msExchUseOAB attribute on the mailbox store.
2. From your Exchange server you can run OABInteg /s:GCName /t:storealtest /v:2 /l and look at the c:\OABInteg.txt file and check all the mailbox stores for this association.
Now I can see that my mailbox store has no Default Offline Address List associated with it I have found the problem. Now I just need to populate one to fix this. Before I can download the Offline Address list I need to log out of Outlook, and then log back in. This is a necessary step because the Outlook client reads this information during the login process. Once I am logged back in, I can then Send/Receive and download my OAB.
What if your information store has a Default Offline Address List associate with it?
If you happen to have a Default Offline Address List associated with your Mailbox Store, it is very possible that your Outlook client is reading some stale or incorrect information from its previous settings. Creating a new profile usually fixes this problem, however there are additional steps we can take to verify this before we do so.
1. From either your Exchange server or Outlook client run OABInteg /s:exchsrvrname /t:hierarchylist/v:2 /l (creates a c:\oabinteg.txt file). \
NOTE: This will get all of the Entry ID's from the system folders on your Exchange server.
2. FROM YOUR CLIENT run OABInteg /s:exchsrvrname /t:oabfldcheck /v:2 /l (creates a c:\oabinteg.txt file).
NOTE: This will simulate an Outlook client logon. You can get the search the OABInteg.txt output for the following MAPI property: PR_ADDRBOOK_FOR_LOCAL_SITE_ENTRYID. Once you have found it, copy it and then search for in the hierarchy list output. This will show you what server and folder in the replica list your Outlook client is trying to open. If the Entry ID returned to the client is not the correct one, your Outlook client will be going to the Ex: folder which is the default because we had no Entry ID to give back to the client.
So in short:
- Make sure that the OAB did in fact generate, you can see this with diagnostic logging turned to max. See this blog: How to troubleshoot the OAB Generation process
- Make sure your information store is stamped with a Default Offline Address List.
Last but not least you can *try* to create a new profile. ANSI profiles will not be upgraded to Unicode profiles, which are needed for downloading the OAB Version 3 and OAB Version 4. Exchange 5.5 uses OAB Version 2.
Dave