If you would like to read the first part of this article series please go to:
- The Offline Address Book (Part 1)
- The Offline Address Book (Part 3)
- The Offline Address Book (Part 4)
Introduction
This is the second part of an article series looking at the Offline Address Book (OAB) generation process in Exchange 2010. In part one of this article series, we examined the properties of the default OAB that is generated when Exchange 2010 is installed. Let’s now turn our attention to understanding how the OAB files are generated and distributed to the client machines running Outlook. Here in part two, we’ll start looking at the generation process.
Generation Process
You may remember from part one of this article series that the mailbox server LABMBX is currently configured to generate the OAB data; you can confirm this by examining the Server attribute in Figure 5 back in part one; the Server attribute is the second attribute listed from the top. On the server LABMBX, it is possible to navigate to the \Program Files\Microsoft\Exchange Server\V14\ExchangeOAB folder to view the actual OAB files as you can see in Figure 6.
Figure 6: Contents of the ExchangeOAB Folder
It can be seen from Figure 6 that the actual ExchangeOAB folder contains a sub-folder named with a Globally Unique Identifier (GUID) and that the actual OAB files are contained within this sub-folder. This GUID is the actual GUID of the OAB called Default Offline Address Book in the lab environment and you will see later that it can be used during the diagnostics logging process to confirm which OAB is being referenced when troubleshooting. You can also see that the folder contains many OAB files that have filename extension of .LZX. These files contain the OAB information that will be downloaded by the Outlook client. The .LZX extension is derived from the fact that the files are compressed using the LZX compression algorithm. You will also notice that the .LZX file names shown in Figure 6 have the string “lng” in them, followed by a four-digit hexadecimal value. The lng string represents OAB file types for Windows, whilst a string of “mac” (not shown in Figure 6) represents OAB file types for the Mac. The four-digit hexadecimal value represents the language locale ID. For example, 0409 represents English (US). Also seen in Figure 6 is the file named OAB.XML which is used by Outlook to determine which of the OAB information files are to be download to the client.
Temporary Files
Before the OAB data is written to the files found in the Exchange OAB sub-folders, it is actually constructed in the %TEMP% folder first. By %TEMP%, we are referring to the system variable and not the user variable; on the lab mailbox server, this means that %TEMP% is set to C:\Windows\Temp and in Figure 7 you can see the OAB LZX files appearing in the %TEMP% folder during an update. Although these temporary files are cleaned up after the generation process has finished, there are a couple of scenarios where additional planning is required. For example, very large deployments where the OAB itself will be large or deployments that have minimal disk space left on drive C: may encounter disk space issues when the temporary files are created. Consequently, you should plan for these scenarios unless you plan on changing the location where the temporary files are generated.
Another important consideration regarding the folders and files found below the ExchangeOAB folder on the mailbox server responsible for generating the OAB is to ensure that they are all excluded from any file-level antivirus scanning. Please take the time to ensure that this configuration is in place.
Figure 7: Contents of the %TEMP% Folder
To change the location where the OAB temporary files are generated, please see Dave Goldman’s blog post here. If you have not seen Dave’s blog before then I’d highly recommend that you bookmark it now, as it is contains a wealth of information not only on topics like the OAB, but also areas such as address list segregation.
As we have already seen in part one of this article, the OAB update is scheduled to occur once per day at 5am by default. As an administrator, you may need to manually update the OAB files on the mailbox server when you need a new address to appear sooner than the next scheduled update. Or perhaps you need to troubleshoot why a new address is not appearing in the OAB. Manually updating the OAB can be achieved either via the Exchange Management Console or via the Exchange Management Shell. In the Exchange Management Console, simply right-click the Offline Address Book object as seen in Figure 1 in part one of this article and choose the Update option. You will then be presented with a warning dialog box informing you that the process can take several minutes, which depends largely on the size of your infrastructure. In the Exchange Management Shell, run the following cmdlet to update the OAB named Default Offline Address Book:
Update-OfflineAddressBook –Identity “Default Offline Address Book”
To see what is happening behind the scenes during an update, it is useful to increase the diagnostics logging levels for the OAB generation process so let’s now have a look at this and discover what we can expect to see in the event logs.
Offline Address Book Diagnostics Logging
As we stated in part one of this article series, it’s the Microsoft Exchange System Attendant service that is responsible for generating the OAB files on the mailbox server. To increase the diagnostics logging level for the OAB generation process using the Exchange Management Console, first navigate to the Server Configuration node and then select the Mailbox node found underneath it. Then, in the top pane select the particular mailbox server in question and with this server selected, choose the Manage Diagnostics Logging Properties… option from the action pane. Doing so will bring up the Manage Diagnostics Logging Properties wizard and on the opening screen scroll down until you find the MSExchangeSA entry, which represents the Microsoft Exchange System Attendant service. Expand this entry and select the OAL Generator category, which itself represents the offline address list generator process of the system attendant. Ensure that you set this category to at least the medium level as you can see from Figure 8.
Figure 8: Setting Diagnostics Logging Levels
Once you’re happy with the configuration, click the Configure button followed by the Finish button to close the wizard. It is also possible to use the Exchange Management Shell to examine and set the diagnostics logging level for this service. To examine the current diagnostics logging level for the MSExchangeSA service on the server LABMBX, use the following cmdlet:
Get-EventLogLevel –Identity LABMBX\MSExchangeSA\*
With the specified Identity parameter, you can see that the server name is included in order to ensure that we’re setting the logging levels on the correct server. Since there are multiple categories found under the MSExchangeSA service, the wildcard character is used to list all categories.
To set the diagnostics logging level to Medium using the Exchange Management Shell, the following cmdlet is run:
Set-EventLogLevel –Identity “LABMBX\MSExchangeSA\OAL Generator” –Level Medium
With the diagnostics logging levels increased, it is now possible to rebuild the OAB and check the application event log on LABMBX. Many event log entries will be recorded, from informational events through to warning and error events as you might expect. Examples of informational events include those that inform you the OAB generation process has started and completed, whilst warning events cover a variety of situations and issues including the fact that one or more entries may not have been included in the OAB. The error events logged in the event log will help you to diagnose if any particular mailbox is not appearing in the OAB. For example, consider Figure 9 where you can see that a particular mailbox is not appearing in the OAB due to an invalid SMTP address issue. Here you could proceed to investigate and rectify this issue by examining the properties of this mailbox to see what this user’s SMTP addresses were set to. Once any required changes had been made, the OAB could then be rebuilt again.
Figure 9: Diagnosing Problematic OAB Entries
One interesting warning event log entry recorded on Exchange 2010 mailbox servers is shown in Figure 10 where it would appear that, according to the event description, one or more properties for the mailbox belonging to the Administrator mailbox have been truncated or dropped due to size limit restrictions. It’s likely that you are seeing this on your Exchange 2010 server and if that’s the case then you need not worry. In his blog posts here and here, Dave Goldman from Microsoft explains that this message is by design and can be safely ignored. He goes on to say that this is an issue with the Release To Manufacturing (RTM) version of Exchange 2010 and that in the timeframe for Exchange 2010 Service Pack 1, the event log entry will be reclassified as an informational event rather than a warning event.
Figure 10: Event 9359
Summary
That completes the second part of this article series on the OAB generation and distribution process, where we have seen how the OAB data is generated on a mailbox server. Additionally, we have seen how to configure diagnostics logging for this process to allow us to troubleshoot issues. In part three, we’ll start our look at the web-distribution method and specifically look at how the OAB data is transferred to the Client Access Server role.
If you would like to read the first part of this article series please go to:
