Cumulative Update 5 (CU5) for Exchange Server 2013 will be released soonTM, but before that happens, I wanted to make you aware of a behavior change in the Offline Address Book that is shipping in CU5.  Hopefully this information will aid you in your planning, testing, and deployment of CU5.

The Offline Address Book in Previous Releases

In all previous major releases, the Offline Address Book (OAB) was generated by a particular server within your organization based on an administrator defined schedule. This architecture provided flexibility as it allowed you to deploy OAB generation servers based on the needs within your environment, and depending on how you deployed your OABs, could even enable users to download the OAB from the closest CAS available.

Let’s apply this information to an example. Contoso operates as a distributed messaging environment, with offices in Redmond and Portland. Each site has an OAB generated based on the Default Global Address List, allowing the local users to download the OAB without traversing an expensive (and possibly highly latent) WAN. If the users travel, they download the OAB changes across the WAN link.

E2010 OAB
Figure 1: Exchange 2010 OAB Contoso Architecture

While this model provided flexibility, it unfortunately had a single point of failure – if the server failed, OAB generation stopped. This also meant that high availability architectures in Exchange 2010 did not provide any benefit to the OAB.

The OAB in Exchange 2013

Exchange 2013 has introduced dramatic changes to the OAB. The OAB is no longer generated by a server; instead, the OAB is generated by a special type of arbitration mailbox, known as an organization mailbox. The generation is controlled by a time-based assistant, OABGeneratorAssistant, which works in conjunction with the workload management infrastructure to ensure that the system is not burdened by the OAB’s generation.

This new infrastructure can also take advantage of the high availability architecture of Exchange 2013. The OAB mailbox can be deployed on a mailbox database that has multiple copies, thereby mitigating a failure mode that occurred in previous releases.

From a connectivity perspective, Autodiscover provides back an OAB URL for the site in which the user’s mailbox is located. That URL resolves to a Client Access server which attempts to proxy the request to an OAB mailbox within the local site. If there is no OAB generation mailbox located within the local AD site, CAS picks one in another site with the lowest site connection cost. If there is more than one OAB generation mailbox with same lowest cost, CAS will pick one at random.

However, this new architecture introduces some deficiencies.

  • Each OAB generation mailbox generates and stores all the OABs in the environment.

    Referring back to the previous example, now upgraded to Exchange 2013, Contoso’s administrator created an OAB generation mailbox in Portland, mirroring the Exchange 2010 architecture.  Both OAB generation mailboxes generate the Redmond and Portland OABs:

    E2013 OAB
    Figure 2: Exchange 2013 OAB Contoso Architecture - Multiple OAB Generation Mailboxes

    If Contoso contained more locations, each hosting its own OAB, then the number of OABs generated by the OAB generation mailbox increases proportionally. Each OAB generated increases the compute cycles and capacity requirements on each Mailbox server hosting an OAB generation mailbox.

  • Each OAB generation mailbox generates an OAB that is unique when compared to the same OAB generated by other OAB generation mailboxes.

    This tenet means that traveling users and single namespace designs are impacted. Referring back to Figure 2, with the environment now utilizing a single namespace across the two locations, there is a fifty percent chance that a user will hit CAS infrastructure that is not located within the same site as the user’s mailbox. CAS will utilize the local OAB instance vs. proxying between sites as the local site contains the closest OAB generation mailbox. As a result, users will download full OABs each time Outlook’s OAB synchronization request is processed in a different site when compared to the mailbox’s location.

    There’s another way this tenet can impact clients – deploying more than a single OAB generation mailbox in a site. For example, if the Redmond site had two OAB generation mailboxes, both OAB generation mailboxes would generate unique, separate instances of the Redmond OAB. Even if the Redmond users were always directed to the Redmond CAS infrastructure, because there are two OAB generation mailboxes, CAS could proxy to either mailbox. As a result, each time an Outlook client is directed to a different OAB download instance, a full OAB download is triggered. In other words, if there are two (or more) OAB generation mailboxes located within the same Active Directory site, a user could download either OAB, resulting in full OAB downloads each time the user accesses a different OAB generation mailbox’s OAB files.

    E2013 OAB 2 mailbox
    Figure 3: Exchange 2013 OAB Contoso Architecture - Multiple OAB Generation Mailboxes in a Single Site

These deficiencies led to the guidance of deploying only a single OAB generation mailbox per organization. While this guidance resolves the aforementioned issues, it is not practical in large distributed on-premises environments or in hosting environments because it forces the users to download the OAB over expensive (and often times, saturated) WAN links and it is a single point of failure – if connectivity to the site hosting the OAB generation mailbox is inaccessible, clients cannot retrieve updated OAB data.

Dedicated OAB Generation Mailboxes in Cumulative Update 5

CU5 moves away from the previous model where an OAB generation mailbox generates all the OABs in the organization. While an OAB generation mailbox can continue to generate multiple OABs (the default behavior when you deploy Exchange 2013), what’s new in CU5 is that an OAB can only be assigned to a single OAB generation mailbox.

This architectural change addresses the aforementioned deficiencies:

  • By allowing administrators to define where an OAB is generated.
  • By removing the capability to have multiple instances of the same OAB, mitigating the scenario where a client could hit a different OAB instance triggering a full OAB download. 

From a connectivity perspective, Autodiscover provides back an OAB URL for the site in which the user’s mailbox is located. That URL resolves to a Client Access server which proxies the request to the linked OAB generation mailbox that is responsible for generating the requested OAB.

As a result, Contoso can now deploy the following OAB architecture:

E2013 CU5 OAB
Figure 4: Exchange 2013 OAB Contoso Architecture

Redmond users will now only download the Redmond OAB from the Redmond AD site and Portland users will only download the Portland OAB from the Portland AD site.  Neither set of users will have an OAB full download as a result of traveling between locations because the users will always be referred back to the Mailbox server hosting the OAB generation mailbox that contains their OAB.

What happens to my existing OABs when I upgrade to CU5?

When you upgrade to CU5, all existing OABs are linked to the system arbitration mailbox, SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}, regardless of whether there are additional OAB generation mailboxes within the environment. This ensures that all OABs are still generated after CU5 is installed. This has two implications:

  1. If you were not aware of our guidance of deploying only a single OAB generation mailbox per organization, and instead, deployed multiple OAB generation mailboxes, those mailboxes will no longer generate OABs after the servers hosting their databases are upgraded to CU5. This means that Outlook clients will perform a full OAB download (as they are now accessing a different OAB instance).
  2. Once you dedicate an OAB to a specific OAB generation mailbox, this will be a new OAB instance and thus, will trigger a full download for the Outlook clients.

Note: Users will not experience full OAB downloads after CU5 is deployed if your deployment does not contain multiple OAB generation mailboxes.

Does upgrade order of roles matter?

The upgrade order of the roles only matters if you have multiple OAB generation mailboxes deployed.  In CU5, the HTTP proxy logic in the Client Access server role was updated to ensure that an OAB request is routed to the correct OAB generation mailbox. Therefore, it is important to upgrade your Client Access servers prior to upgrading your Mailbox servers if you have multiple OAB generation mailboxes deployed in your environment. If you upgrade your Mailbox servers to CU5 before upgrading your Client Access servers, users will potentially be routed to OAB generation mailboxes that are not responsible for the OAB the user is requesting, resulting in failed download requests.

How do I dedicate an existing OAB to specific OAB Generation Mailbox?

Once CU5 is deployed, you can dedicate existing OABs to specific OAB generation mailboxes by executing the following command, utilizing the GeneratingMailbox parameter:

Set-OfflineAddressBook "Portland OAB" –GeneratingMailbox "CN=OAB Mailbox 1,CN=Users,DC=contoso,DC=com"

Important: If your OAB generation mailboxes are deployed in DAGs, upgrade all Mailbox servers to CU5 before dedicating an OAB to a specific OAB generation mailbox. If you do not, when the database hosting the OAB generation mailbox is activated on a server running an older version, the OAB assistant will generate all OABs.

The GeneratingMailbox parameter only accepts the distinguished name value of the OAB generation mailbox; other identity types (e.g., domain\account, UPN, alias, etc.) do not work. One way around this is to utilize the following process:

$mbx = get-mailbox oabmbx1 –arbitration
 
Set-OfflineAddressBook "Portland OAB" –GeneratingMailbox $mbx.Identity

Once you have linked the OAB to an OAB generation mailbox, you will need to execute Update-OfflineAddressBook:

Update-OfflineAddressBook "Portland OAB"

How do I create a new OAB and an OAB Generation Mailbox?

When creating new OABs you need to specify the GeneratingMailbox property:

New-Mailbox -Arbitration -Name "OAB Mailbox 3" -Database DB4 -UserPrincipalName oabmbx3@contoso.com –DisplayName "OAB Mailbox 3"
 
Set-Mailbox "OAB Mailbox 3" –Arbitration –OABGen $true
 
New-OfflineAddressBook -Name "Bel Air OAB" –GeneratingMailbox "CN=OAB Mailbox 3,CN=Users,DC=contoso,DC=com" –AddressLists "Default Global Address List"

Note: GeneratingMailbox is not a required parameter when creating an OAB. If the GeneratingMailbox parameter is not specified, the Exchange Management Shell will return the following warning: GeneratingMailbox is null; this OAB will not be generated until GeneratingMailbox is set to an arbitration mailbox with the OABGen capability.

Once you have created the OAB in your environment, you will need to execute Update-OfflineAddressBook:

Update-OfflineAddressBook "Bel Air OAB"

Summary

We have heard your feedback loud and clear that the Exchange 2013 OAB architecture does not meet the needs of distributed messaging environments. Dedicating OABs to specific OAB generation mailboxes is the first step in improving the capabilities of the OAB in the on-premises product. I won’t go into specifics at this early stage of development, but we are not finished with improving the OAB architecture. As the plans finalize, I will share more.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Updates

  • 5/19/14: Added guidance on upgrading CAS to CU5 before MBX.