OAB Improvements in Exchange 2013 Cumulative Update 5

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.

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:

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.

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:

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:

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).

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:

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:

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.

@Martijn Westera – Yes, those blog articles do mention per-site (I will have them updated). However, the guidance we’ve been communicating at TechEd, MEC (the link I provided in the article), and Ignite training is one per-organization.

@Jeff – I misunderstood your question. With CU5 you can have multiple OAB generation mailboxes in the same site because an OAB can only belong to a single OAB generation mailbox. This means that you can have multiples OABs within a single site and not
have to worry about random client full downloads.

Thinking about the preferred architecture; any plans to allow oab mailboxes in two different ad sites both with the same GUID? This would allow clients to download the oab local to the ad site that the web request came into regardless of where the mailbox is located thus preventing back hall across the wan.

@Jeff – If by OAB arbitration mailbox, you mean the SystemMailbox, then no, you don’t have to configure anything. CU5 will link all OABs to the SystemMailbox. If you have other OAB generation mailboxes in the environment, you will have to configure them
manually after CU5 is deployed.

Prior to CU5, all OABs are generated in each OAB generation mailbox, so if in your scenario, all the OABs are generated by the SystemMailbox, then after you install CU5, all OABs will be continued to be generated by that mailbox, and thus no full download will
occur. If on the other hand, you have multiple OAB generation mailboxes in a site today, (see the 2nd deficiency), your users already having multiple full downloads today, so when CU5 is deployed on those servers, they will experience another full download
(as they will now be pointed to the SystemMailbox).

@ActionXP – We agree, the current E2013 design (CU1-CU4) is not ideal. That’s why we are changing the design, bringing it back to a similar design that existed in prior releases. Unfortunately, changing the design requires some customers to have to experience
a full OAB download. Out of the box, Exchange 2013 only creates a single OAB generation mailbox. If you or any customer is operating in that configuration, CU5 WILL NOT introduce a full OAB download, until you create additional OAB generation mailboxes and
assign new OABs. The only customers affected by the CU5 change are customers that have multiple OAB generation mailboxes today as they will experience full OAB downloads to get to the desired CU5 state.

Keeping multiple OAB mailboxes in same AD site , is always efficient Method of OAB distribution. Because I know Some AD sites have large number of user mailboxes deployed. Instead of recommending to deploy single OAB mailbox, can we think of an architecture where, OAB multiple OAB mailboxes keeps track of users, when they download OAB. Something like a checkpoint. ( few bytes of info) and Sync the Checkpoint across all OAB mailboxes. Discard the checkpoint once in 24 hrs or 48hrs. Checkpoint can be an indication that user has already downloaded the OAB .. Ignore another download.

So if i understand correct: for every oab in you exchange org you need to create a mailbox?
like company 1: oab 1 > oab mailbox 1?
company 2: oab 2 > oab mailbox 2?
and so on? (created with the snell commands you gave us)

so 100 offices/company’s is also 100 mailboxes in cu5? (and you need to create them manually?
as this is now only one mailbox (arbitration mailbox in 1 of your dag database.)

i understand for large environments (multiple sites) why, but if a customer has 1 site 1 dag with 3 members, do you need to use the "mailboxes-per-oab structure"?