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" -MaxSendSize 1GB
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"


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


  • 5/19/14: Added guidance on upgrading CAS to CU5 before MBX.
  • 1/24/17: Added MaxSendSize parameter to creation of OAB arbitration mailbox example
Not applicable
Thank You Ross. Great article!!
Not applicable
Hi, When will Exchange Server 2013 CU5 be released?
Do not see it on The Exchange Team Blog.
Not applicable
Just out of curiosity,

Why is it that you can only specify identity using distinguished name ?

Not applicable
Great Article, Thank you Ross!!!
Not applicable
Hi Anon -1 and team who is waiting for CU 5 is over now ,here is the link and what other problem it will resolved.


Not applicable
When it is ready, Anon-1.
Not applicable
Thanks, Ross.

I was hoping that CU5 would bring improvements that would also allow for multiple OABs in the same site. We don't deploy them now for the reason you specified, and it sounds like we still shouldn't.

Not applicable
@krisasmith - Like I said in the summary section, we aren't finished yet with optimizing the OAB for distributed on-premises environments. Stay tuned.
Not applicable
@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.

Not applicable

You mention: 'These deficiencies led to the guidance of deploying only a single OAB generation mailbox per organization'

As far as I know recommendation was one organization mailbox per AD site:

http://blogs.technet.com/b/exchange/archive/2013/01/14/managing-oab-in-exchange-server-2013.aspx: Hence, current guidance is to plan organization

mailbox placement such that you will have one organization mailbox active in an AD site.


Not applicable
@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).

Not applicable
Thanks Ross !!!
Not applicable
Great article with useful details. Thanks Ross!
Not applicable

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.
Not applicable
I would guess this requires an update to the Schema? Any idea when Public Folders will be improved? Thanks
Not applicable
Ross - You rock. This is definitely a great improvement.
Not applicable
@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.

Not applicable
How does this new behavior affect multiple OABs in the same site? It seems that users in that site would still do a full download.

Will we need to set the GeneratingMailbox parameter on our existing OAB arbitration mailbox or will CU5 do that for us?

Not applicable
@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.
Not applicable
@Devgl - Yes, a schema update will be required with CU5.
Not applicable
After performing the above change after CU5 will the Outlook client choke the network bandwidth on getting the OAB download completely....or will it be an increamental update...
Not applicable
@Grzegorz Wierzbicki - The reason is because GeneratingMailbox requires a value that maps to the ADObjectID class (http://msdn.microsoft.com/en-us/library/office/microsoft.exchange.data.directory.adobjectid(v=exchg.150).aspx).

It's not ideal, so in a future update, we will change it so that you can use any identity value (MailboxIdParameter -



Not applicable
Also wanted to Thank you Ross for writing great Exchange Server Articles. Hands down you write one of the Best Exchange On-Premises Articles in The Exchange Team Blog, Hail Ross ;)
Not applicable
Great article, thank you so much. I just updated my provisioning scripts, after the CU5 update, cause of the WARNING.

Please correct the following command in your article, which does not work for me:

$mbx = get-mailbox oabmbx1 –arbitration

Set-OfflineAddressBook "Portland OAB" –GeneratingMailbox $mbx.Identity

Change to:

Set-OfflineAddressBook "Portland OAB" –GeneratingMailbox $mbx.DistinguishedName

Seems like a typo.

Thank you!

Not applicable
Which one is more painful to client?

a. OAB generation stopped due to server down or service crash, the admin has to manually change OAB generation server.
b. Force users to re-download OAB, and download OAB cross WAN during travel

To be frank, I am more preferring the Ex2010 design. What are you guys thinking?
Not applicable
Ross thanks for the information.
Not applicable
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.

only exception when user creates new profile / multiple profiles / manual full download.

Not applicable
Great Article...Always you're awesome...Thank you very much... :)
Not applicable
Will CU5 require SP1 or can we just go straight to CU5?
Not applicable
I agree with krisasmith, the propose changes still don't meet our distributed site requirements where we need to have the same oab published to multiple sites (and avoid oab downloads over the wan).
Not applicable
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"?

a lot of questions, but i hope you can answer them,



Not applicable
So, since we followed recommendation to have one generated mailbox per site described in

http://blogs.technet.com/b/exchange/archive/2013/01/14/managing-oab-in-exchange-server-2013.aspx, how can we avoid full oabs downloads after CU5?

Should we simply remove OAB generating capabilities from the mailboxes we created?

Another question: How it is possible that there are 2 articles in Exchange Team blog with completely different recommendations regarding OAB generating mailboxes, one per org or one per site?

Not applicable
Great article. Thanks Ross
Not applicable
There's a space that shouldn't be there between "Address" and "Lists" in the New-OfflineAddressBook command in the next to last command box.