Outlook client fails to download the OAB with error 0x8004011B
Earlier today I saw a post on one of the aliases where a customer was having issues downloading the OAB with their Outlook 2003 clients. The Outlook client was failing with the error code of 0x8004011B. I asked a few questions in regards to the customers exchange environment, and I found out that they have an Exchange 2003 / Exchange 2007 mixed organization.
The first thing I did was dump out the error code 0x8004011B so I could see what it was. I used err.exe to dump this out.
C:\WXP\system32>err 0x8004011B
# for hex 0x8004011b / decimal -2147221221
ecCorruptData ec.h
MAPI_E_CORRUPT_DATA mapicode.h
# 2 matches found for "0x8004011B"
Ok, from this error I can see that we are possibly looking at either some corrupted data or the data is actually missing from the public folder information store. From looking at the application log events I was able to pull out the Event ID 27.
Event Type: Warning
Event Source: Outlook
Event Category: None
Event ID: 27
Date: 10/20/2006
Time: 4:24:56 PM
User: N/A
Computer: Computer
Description: OAB Download Failed. (Result code in event data).
For more information, see Help and Support Center at https://go.microsoft.com/fwlink/events.asp.
Data:
0000: 01 00 00 00 1b 01 04 80 .......€
0008: 01 00 00 00 18 02 00 00 ........
0010: 01 00 00 00 00 00 00 00 ........
0018: 00 00 00 00 00 00 00 00 ........
0020: e9 fd 00 00 57 f5 c9 dc éý..WõÉÜ
0028: 80 04 00 00 00 00 00 00 €.......
0030: 00 00 00 00 00 00 00 00 ........
0038: 00 00 00 00 00 00 00 00 ........
0040: 00 00 00 00 00 00 00 00 ........
0048: 00 00 00 00 5c 00 00 00 ....\...
0050: 00 00 00 00 03 00 00 00 ........
0058: 02 00 00 00 6c 69 61 7a ....liaz
0060: 6c 69 61 7a 00 00 00 00 liaz....
0068: 00 00 00 00 00 00 00 00 ........
0070: 00 00 00 00 00 00 00 00 ........
0078: 00 00 00 00 00 00 00 00 ........
0080: 00 00 00 00 00 00 00 00 ........
0088: 00 00 00 00 00 00 00 00 ........
0090: 00 00 00 00 00 00 00 00 ........
0098: 00 00 00 00 ....
Looking at the data above I can see two very interesting things:
- At offset 0000 the first byte is 01. Looking up this error code I know 01 means that you do not have any offline address book files on your client computer, or the offline address book files could not be opened.
- At offset 0090 there is not address list displayed.
From looking at offset 0090 I know that the possibility of corrupted data is slim, however does the OAB data actually exist? From here there are two things that needed to be checked.
- Was the OAB ever generated and do the OAB files exist in the form of a message and attachments in the information store?
- Is there an OAB associated with the customers mailbox store?
From here I suggested that the customer get me an OABInteg output with the two following tests (oabfldcheck and storealtest). Both of these tests will let me know the following:
- If the OAB has been generated and posted to the public information store.
- If the mailbox information store has an OAB associated with it.
- If there is corrupted data in the public folder information store OABInteg will fail to read the OAB messages and attachments, so this will allow us to rule out the possibility of data corruption.
The customer ran the following test c:\oabinteg.exe /s:SrvName /t:storealtest /v:2 /l (this creates a c:\OABInteg.txt file):
The output for this test showed the following:
OABInteg (Offline Address Book Integrity Checker)
Product Version 06.05.7839.0
OABInteg.exe
Microsoft Corporation, Copyright (C) 2006
Microsoft and Windows are registered trademarks of Microsoft Corporation.
=====================================================
c:\OABinteg.txt has been opened for writing.
Program started at: 08:53:12 AM
Running OABInteg on: Username\Server
LDAP has been initialized successfully.
Using ldap port: 3268
Trying to connect to: GC://DomainController
Initiating search for rootDSE attributes.
rootDSE attributes found and cached.
Starting Test 1 - Store Offline Address List Test
LDAP has been initialized successfully.
Using ldap port: 3268
Global Catalog Server Selected: DomainController
Path: GC://DomainController/CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain,DC=com
Binding to the active was directory successful.
Ldap Search Page Size: 64
Search filter to: (objectClass=msExchPrivateMDB)
Search attributes: cn, distinguishedName, msExchUseOAB
Search started at: 08:53:12 AM
Search ended at: 08:53:12 AM
Scan Completed
+--------------------+
Total information store address lists found: 0
So from this I can see that the information store on this server does not have an OAB associate with it. The customer then ran the following test c:\oabinteg.exe /s:SrvName /t:oabfldcheck /v:2 /l (this creates a c:\OABInteg.txt file):
The output for this test showed the following:
=====================================================
OABInteg (Offline Address Book Integrity Checker)
Product Version 06.05.7839.0
OABInteg.exe
Microsoft Corporation, Copyright (C) 2006
Microsoft and Windows are registered trademarks of Microsoft Corporation.
=====================================================
c:\OABinteg.txt has been opened for writing.
...<I cut the data out because we really care about what is below>...
Scan Completed
+--------------------+
Message Class Normal found: 3
Message Class Differential found: 80
Message Class Unknown found: 0
Message Attachments found: 0
Messages found but unable to read the properties: 0
System folders found: 4
Highest sequence number found: 538
Lowest sequence number found: 2
Biggest attachment found: 0 Bytes
Smallest attachment found: 36500 Bytes
Biggest message found: 2.2 MB
Smallest message found: 326 Bytes
From this output I can see that the OAB has been generated. If you look at the output above you can see that there are 3 normal message (OAB messages), 80 differential files and 4 system folders. So based on this output I know that the OAB was generated and posted to the public folder information store. Now we know the problem is there is no OAB associated with the mailbox information store.
The customer was able to verify and fix this by pulling up the properties of the mailbox information store and look to see what Offline Address List is assigned to this store. There wasn't one associated there. The customer then linked this mailbox information store to the OAB on the Exchange 2007 public folder store. The customer had an Outlook client login and they were able to download the OAB files.
Dave