There have been many improvements in the Exchange Offline Address Book (OAB) architecture, configuration and processes in Exchange 2013 when compared to Exchange 2010. These need to be understood by anyone responsible for the architecture of an Exchange 2013 deployment as well as the ongoing administration of this deployed infrastructure. The main changes to be aware of include:
- OAB version 4 is now the only version generated
- OAB generation is no longer tied to a specific mailbox server
- The OAB generation schedule control is different
- Web-based distribution is the only supported distribution method
In this article, these changes will be discussed in more detail.
In previous versions of Exchange, different versions of the OAB were generated and made available to clients. For example, the OAB versions generated included version 2 for Outlook 98 SP1 or earlier clients, version 3 for Outlook 98 SP2 or later clients, and version 4 for Outlook 2003 SP2 or later clients. It was possible for the Exchange administrator to select which versions were made available for clients to use. This client support functionality for an Exchange 2010 server can be seen in Figure 1-1.
Figure 1-1: Client Support Options in the Exchange 2010 OAB
Compare Figure 1-2 below with Figure 1-1 above. Figure 1-2 shows the details of the OAB properties in Exchange 2013, as retrieved using the Get-OfflineAddressBook cmdlet and filtering for the Versions parameter. Here, it can be seen that only version 4 of the OAB is provided. For Exchange 2013, OAB version 4 supports Outlook client versions from Outlook 2007 upwards.
Figure 1-2: Client Support Options in the Exchange 2013 OAB
Arbitration Mailboxes and OAB Generation
How the OAB is generated in Exchange 2013 has changed when compared to previous versions of Exchange. In Exchange 2010 for example, the Generation Server property of the OAB indicated which particular mailbox server was configured to generate it. Things are different in Exchange 2013. When Exchange 2013 is installed, a number of arbitration mailboxes are created. Arbitration mailboxes have an attribute called PersistedCapabilities that indicates the different functionality that the arbitration mailbox performs. To see a list of the arbitration mailboxes together with their persisted capabilities, the following command can be run:
Get-Mailbox -Arbitration | fl Name,PersistedCapabilities
An example of the output when running this command can be seen below in Figure 1-3.
Figure 1-3: Showing the PersistedCapabilities Parameter of Arbitration Mailboxes
It can be seen from Figure 1-3 that some of the arbitration mailboxes have what are known as organization capabilities and these mailboxes are themselves known as the organization mailboxes. One of these persisted capabilities is called OrganizationCapabilityOABGen and it is this persisted capability that controls whether this arbitration mailbox can generate an OAB. Aside from viewing the properties of the arbitration mailboxes, it is also possible to get the properties of the OAB via the Get-OfflineAddressBook cmdlet and check the value of the GeneratingMailbox parameter to see which mailbox is listed. Figure 1-4 shows the output of running this cmdlet, where it can be seen that the GUID of the system (arbitration) mailbox seen when running the Get-OfflineAddressBook cmdlet matches that seen above in Figure 1-3 when viewing the details of the arbitration mailboxes.
Figure 1-4: Viewing the GeneratingMailbox Parameter of the Get-OfflineAddressBook Cmdlet
Exchange 2013 OAB Architecture Changes
While on the subject of the OAB generation mailboxes, it is a good time to mention the major architectural changes that have occurred to the OAB since the original release of Exchange 2013 as these changes form important background information to understand. Prior to the release of Exchange 2013 Cumulative Update 5 (CU5), the guidance from Microsoft was to only deploy a single OAB generation mailbox per organization. This was due to some scenarios where clients could trigger full OAB downloads, such as when a single namespace was used across two locations and a users’ mailbox was in a different location to the Client Access Server responding to the OAB synchronization request. In that scenario, the OAB generation mailbox ‘local’ to the client was used, resulting in a full OAB download to that client. Microsoft addressed this in Exchange 2013 CU5 by enforcing the configuration that an OAB was tied to a specific generation mailbox, thereby ensuring that multiple instances of an OAB were not possible. It is important for Exchange architects and administrators to understand this scenario in greater detail by reading the Exchange Team Blog post titled OAB Improvements in Exchange 2013 Cumulative Update 5.
Further enhancements to the OAB architecture were made in Exchange 2013 Cumulative Update 7 (CU7), as this particular update introduced OAB Shadow Distribution. As its name suggests, OAB Shadow Distribution allows for a shadow copy of an OAB tied to a specific generation mailbox to be stored on a different generation mailbox. The idea is that OAB downloads can be optimized to avoid clients downloading OABs across WAN links. Again, it is important for Exchange architects and administrators to understand this scenario in greater detail by reading the Exchange Team Blog post titled OAB Improvements in Exchange 2013 Cumulative Update 7.
OAB Generation Location in Exchange 2013
In Exchange 2013, the OAB is first generated in the arbitration mailbox so understanding which database houses this arbitration mailbox is key to understanding the server that is currently responsible for generating the OAB. Once generated, the OAB is then later copied as a series of files to the \ClientAccess\OAB folder on the mailbox server. For example, if the mailbox server role has been installed into the C:\Program Files\Microsoft\Exchange Server\V15 folder, the OAB files will be copied to C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\OAB. Specifically, the OAB files will be copied into a sub-folder that is named with the Globally Unique Identifier (GUID) of the OAB object. Inside this sub-folder, a number of files with the extension LZX will be created along with an XML file. You may even notice that the OAB files are in fact first processed in a temp folder that is also created below the ClientAccess\OAB folder before they are copied to the GUID sub-folder. An example of the contents of the files in the GUID sub-folder is shown in Figure 1-5.
Figure 1-5: OAB Files Found in the GUID Folder
OAB Generation Schedule
Perhaps the next logical question might be to ask how often the OAB is generated before the files are copied to the ClientAccess\OAB folder. In previous versions of Exchange, the OAB was generated on a schedule defined by the administrator. This was achieved by accessing the properties of the OAB itself, an example of which can be seen in Figure 1-6. This particular example is taken from Exchange 2010.
Figure 1-6: OAB Schedule in Exchange 2010
However, in Exchange 2013 this schedule-defined generation of the OAB is no longer used. There are two parameters of the Set-MailboxServer cmdlet that are used to control the generation schedule of the OAB in Exchange 2013, namely the OABGeneratorWorkCycle and OABGeneratorWorkCycleCheckpoint parameters. For full details on these two parameters and how to set them, see the detailed documentation provided by Microsoft in the topic titled Set-MailboxServer in the main TechNet library. Like many other processes in Exchange 2013, the OAB generation is throttled and therefore the overall workload being generated against the Exchange 2013 server will affect when the OAB is generated. One key thing to note for administrators is that it is still possible to see the legacy schedule details when viewing the properties of an Exchange 2013 OAB, even though this is no longer used to control the OAB generation schedule. An example of this can be seen in Figure 1-7, where the Exchange 2013 OAB properties have been displayed using PowerShell. This is a potential cause of confusion for any administrators that are familiar with previous versions of Exchange yet are now also responsible for an Exchange 2013 infrastructure.
Figure 1-7: OAB Schedule Parameters for Exchange 2013 Displayed in PowerShell
Finally, it is important to understand the only OAB distribution method available in Exchange 2013. Older versions of Exchange such as Exchange 2007 and Exchange 2010 provided two different options for the distribution of the OAB files, namely the public folder and web-based distribution methods. By using web-based distribution, a number of advantages were obtained over the public folder distribution method such as a reduction in the amount of bandwidth used during the distribution process. However, Exchange 2013 only supports the web-based distribution method so clearly Exchange architects and administrators should not go looking for the public-folder distribution method that previously existed.
As has been seen in this article, there have been many improvements in the Exchange 2013 OAB architecture, configuration and processes when compared to previous versions such as Exchange 2010. These need to be understood by anyone responsible for the architecture or administration of an Exchange 2013 deployment.