This is an article written by Frank Plawetzki, a Senior PFE from Deutschland, and originally published on Opsvault.
Throughout the last weeks I have seen two different issues that prevented Outlook clients from downloading the OAB (Offline Address Book). One affected public-folder based OAB distribution and the other affected web-based distribution.
I want to provide some hints on things that need to be checked in order to follow the OAB generation and publishing process from the server to the client. While checking this list, the administrator can be sure that the OAB has been generated successfully and check if it has been published at the place where the Outlook client is expecting to find it.
At the end of this post, I will give a recommendation regarding the best way in my opinion for rolling out a new OAB to your whole user base, in case you face a situation where a full OAB download for all Outlook clients is necessary.
But let’s start with the OAB generation and publishing process.
Understanding the OAB Generation and Publishing Process
In case you want to start with a detailed understanding of the process, Dave Goldman has provided a detailed guidance on the client-server interaction when downloading an OAB in his post Understanding why error code 0X8004010F is thrown when trying to download an OAB.
While this info is great technical background, in this post I want to shed some light on the publishing of the OAB through Public Folders and through Web-based distribution, especially on where to look first.
It is important to note, that I am concentrating on a domain joined Outlook client. In case your client is not member of a domain, please see this article: Troubleshooting Error 0x8004010F When Outlook 2007 Clients Download OAB.
So how does this work? When you create a new OAB, you must at least specify the following attributes:
- Name of the OAB
- Which mailbox server is generating the OAB
- Which address list should be included in the OAB
- Enable public folder distribution (Y/N)
- Enable web-based distribution (Y/N)
In order to work through the process, you need to check a few first things first, as follows.
Check if the mailbox server is generating the OAB
From the properties of the OAB you can check which server is the generating server: in the EMC (Exchange Management Console) this property is called “Generating server”; in the EMS (Exchange Management Shell) you need to look for the “server” attribute.
Then you need to check the application event log for entries of source “MSExchangeSA” and category “OAL Generator”, so events like this one
In order to have the system log these events it is a best practice to have event logging level increased for this category on a permanent basis, because you might be missing important events otherwise in case OAB creation fails.
The flow of events will also show which version of the OAB has been successfully created and which have failed. In the case below OABv4 has been created successfully.
So at the end of the OAB generation process there should be a success event like the one above for every OAB version you generated.
After OAB generation has finished, the mailbox server publishes the OAB to the public folder database its private store is pointing to and / or is saving the OAB on the local disk, in order to enable the Client Access Servers (CAS) to pull it from there for the web-based distribution method.
Method 1: Web-based distribution of the OAB
We continue on the mailbox server that created the OAB. Just enter the server name into explorer and you will see the share with the local files:
After entering the ExchangeOAB directory, you see the GUIDs of the OABs and creation time stamps:
It is important to note that you can double-check this GUID for Outlook 2007 and older clients since they are using the web-based distribution method of the OAB. When you check the “Test E – Mail Autoconfiguration” in Outlook 2007 / 2010 and check on which URL the Outlook client is looking for the OAB, you will see which CAS server Outlook will query and also which OAB GUID it will be looking for on the CAS file share.
The CAS itself will use the “Microsoft Exchange File Distribution” service to pull the OAB from the mailbox server and will save the OAB in the path mentioned here:
If you generate a new OAB for troubleshooting purposes and it has been generated on the mailbox server, but is not available on the CAS, you can use the CommandLet “Update-FileDistributionService –Identity <server name> –Type OAB”, in order to force re-distribution of the OAB files.
So, in the end, as soon as Autodiscover is able to provide the OAB URL to the client and the OAB file is present to the CAS, the Outlook client should be able to pull the OAB via a HTTP-request and then using its own BITS service to copy it over to the client.
A nice method for testing if the client is able to reach the OAB-URL is using the URL you get back from Autodiscover
and adding /OAB.XML while trying access with a browser which should bring up something like this:
Now let’s check the other OAB publishing method.
Method 2: Public Folder distribution of the OAB
One of the most important events will tell you that the generation process has published the OAB to the public store. This event will also tell you the OAB GUID and, even more important, the OAB sequence number (1 in this case):
The mailbox server will use the public store it is pointing to for publishing the OAB. From there public folder replication will kick in and take care of replicating the OAB files to all public stores specified as replicas.
So you need to consider an additional delay here until a certain folders has been fully replicated to all public folder replicas.
A very useful tool at this point is MFCMAPI, which you can use to open the OAB folder within a certain public folder and check if the OAB files you want to see are present and in good shape.
In my example, it would be this folder:
By double-clicking this folder, you can see the OAB items it contains.
You can see the sequence number (“1”) in the end of the subject and when it was received (in my example I took the screenshot at a later date). The file in the screenshot is the full OAB file. When the OAB generation processes run over several days, you will also see the delta / differential OAB files.
In any case, the OAB files in this folder will have a continuous order of sequence numbers. So you can check very easily on which day which sequence number OAB file has been created.
Another very important property is the “size” of this OAB file item in that folder. The OAB file is compressed and will be downloaded by the client in a compressed format and the client will extract the OAB file afterwards. So the compressed file size should be meaningful and match your (compressed) GAL size.
I am stressing this point, since this was the root cause of the first case I was working on when public folder based OAB distribution failed. In that case OAB download failed with Outlook error 0x8004011B aka MAPI_E_CORRUPT_DATA. The root cause was that the 3rd party Antivirus solution at this customer replaced the data.oab file in transport (the HUB-Server sending the public folder replication message) with a text file. Certainly Outlook could not download this text file. The updated “text” data.oab was then replicated out by the public folder replication, since the file was newer than the original created data.oab.
So make sure to also check the file size of the relevant objects in that folder.
Mitigating the Impact of a Full OAB Download
It might happen that a full OAB download needs to be done by clients. During normal operations this will not occur, since modern clients will use the optimized OABv4 which only results in very seldom download of small delta files.
In cases where your OAB is corrupt and needs to be replaced with a new OAB, all Outlook clients in your organization will initiate a full download. This will happen in cases the clients find a new OAB with a sequence number not matching what they used to download in the past.
For more information on OAB improvements and full downloads see: Improvements for Offline Address Books, which recommends using the “OAB Bandwidth Threshold (KBps)” registry key in order to control the bandwidth an Exchange server can use to distribute an OAB. Please note that this is registry key is only valid for Public Folder based distribution of the OAB.
In many environments it can be challenging to find an appropriate setting for this key, since usually the network links in a corporate environment differ widely between the branch offices and the main office. In case you want to throttle Web-based distribution of the OAB you might want to think about OAB pre-staging or check the work that went into Exchange Server 2010 SP2 RU1, see the article It Takes a Long Time….
So, the methods above at a minimum require a lot of additional work, but there is a more straightforward option to help solve this problem:
In my experience the more elegant solution is to use the per database msExchUseOAB attribute. In other words, when you need to create a new OAB, you can select a single mailbox database and equip the users in that database with the new OAB by setting the “OfflineAddressBook” attribute:
You can use Performance Counters like “MSExchangeISOAB: Full Download Attempts” to check when the “download wave” for the first mailbox database is over and then step-by-step equip the other mailboxes databases with the new OAB one by one. After each step you wait until the download wave is over in order not to overload the network.
(Article by Frank Plawetzki, Senior Premier Field Engineer)
Cheers,
Rhoderick
