This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
The thing that prompted publishing of this blog post is a recent on-premises customer support case. We figured it is a good case study to help illustrate the OAB (Offline Address Book) generation process and how to troubleshoot it if a need arises.
The situation was that Outlook users were always getting full download of the OAB, whether downloaded manually or automatically, which was causing a lot of network traffic on the Exchange Server and was causing unwelcome performance overhead.
Previous blog posts on OAB in Exchange Server 2013 and Managing OAB in Exchange Server 2013 explain what an OAB is and how to manage it. In this article, we will dig a little deeper in to the OAB generation process, the files that are involved, what happens in case of a failover, and how that was linked to this specific scenario (Or was it? Read on to find out!)
OAB files on the server and the client
Before we get into troubleshooting details, we want to go over how OAB files that are generated on the server map to OAB files that are downloaded by the Outlook client.
In Exchange Server 2013 onwards, the mailbox server hosting the OAB Generation mailbox is the one responsible to generate the OAB. OAB files are generated and stored under %ExchangeInstallPath%\ClientAccess\OAB\ in a folder named with a <GUID>. This GUID1 is the same one that’s on the OAB object.
Inside this GUID1 folder, you will find files ending with extensions LZX, FLT and one file called OAB.XML. The LZX files contain the actual OAB, delta changes, language and OS specific changes. These are compressed files stored in the following location of the server that hosts the OAB generation mailbox server: “%ExchangeInstallPath%\ClientAccess\OAB\<guid>\”. Each LZX file has a randomly generated GUID2 associated with it. The OAB.XML file is called a Manifest.
OAB files downloaded by the Outlook client are stored under %LOCALAPPDATA%\Microsoft\Outlook\<GUID>. The GUID folder on the client has the same name as that of GUID2 observed on the names of the LZX. The GUID2 on the OAB generation file plays a crucial part in determining if full or incremental download is needed. Any time this GUID2 changes, the result will be a full OAB download on clients.
The GUID2 is maintained even during database failover, in an interesting way. Let’s see how!
OAB generation workflow
Let’s now see how the OAB generation workflow happens.
These are the OAB properties:
As an example, let’s look at the output from the LDP tool, after the Region1oab is created:
So, what really happens under the hood? Let us have a look at the OABGenerator log (stored on the server under %ExchangeInstallPath%\Logging\OABGeneratorLog), which shows the generation flow:
This then results in the following directory on the server:
At this step, if one logs into the OAB Generation mailbox (using MFCMAPI), it will look like the following (there is no OAB folder, because the generation is not complete):
Continuing with reading of the log:
Now you can see the OAB folder got generated inside the mailbox, and inside the folder we have a mailitem of type IPM.FileSet with the subject as the GUID of the OAB:
The file inside:
Following along in the log:
Now the manifest file is getting created:
Once OAB files are generated on the disk, they are uploaded to the OAB gen mailbox:
Once that’s successful, a confirmation is written to the log:
Finishing the process:
Here is the output from LDP, after OAB is generated:
You might ask yourself: why upload those OAB files to the OAB generation mailbox at all? The answer is that this is how we maintain the continuity of OAB generation GUID2 in case of database switch/failover to another node.
So, what happens if the database fails over to another node?
At first client request for OAB download, the OABAssistant logs on to the OAB generation mailbox and then extracts the LZX files to %ExchangeInstallPath%\ClientAccess\OAB\, based on the manifest.information in the manifest file (OAB.xml).
To summarize a few points here:
- OAB files generated on the disk are uploaded to the OAB generation mailbox
- The files from the OAB generation mailbox are used if the database hosting OAB generation mailbox is switched/failed over.
Therefore, if the OAB manifest files cannot be (for any reason) copied from OAB generation mailbox, the OAB generation is triggered again, causing the reset of GUID2.
In our support ticket, whenever a failover happened, we observed the LZX files were stamped with a new GUID2, triggering the full OAB download on the clients.
Now that we know the OAB generation process, we can see that a new GUID at every failover can be caused by the manifest file not getting uploaded to the OAB generation mailbox.
To solve the mystery of missing OAB manifest file in the OAB generation mailbox, we checked our old friend the OABGeneratorLog and found that the manifest file was not getting uploaded to the OAB generation mailbox:
Hence, whenever there was an OAB request, the OAB generation would create a new GUID.
So, why was the Manifest file not uploaded? During the troubleshooting, we figured out that a setting called MaxSendSize on the OABGen mailbox was set to Unlimited. Well, it is interesting to note that the literal meaning of “unlimited” doesn’t apply here. This defaults to the transport config settings for the MaxSendSize, which was in this case set to 75 MB. But the size of the manifest file was 100 MB, therefore, over this limit.
This error was also reported in the OABGeneratorLog:
The solution here was to set the MaxSendSize on OABGen mailbox to a higher limit, to accommodate the size of the manifest file.
Hope the information here was useful in understanding and troubleshooting OAB generation and download issues!