Sign in
You Had Me At EHLOExchange Server 2010
Home
Library
Forums
Wiki
TechCenter
Follow us on Twitter Follow us on YouTube

OAB Improvements in Exchange 2013 Cumulative Update 7
Ross Smith IV Ross Smith IV 29 Oct 2014 6:00 AM 8
Note: Cumulative Update 7 (CU7) for Exchange Server 2013 will be released soonTM.
Back in May, I discussed the changes we introduced in Exchange 2013 Cumulative Update 5. Specifically with CU5 and later, an OAB can only be assigned (or linked) to a single OAB generation mailbox. This architectural change addressed two deficiencies in the Exchange 2013 OAB architecture:
Enabled administrators to define where an OAB is generated.
Removed the capability to have multiple instances of the same OAB.
However, this change did not improve user accessibility in a distributed messaging environment. For example:
CU5 Behavior

Let’s say the blue user, whom we shall now call Scott Schnoll, has his mailbox located in Redmond. Due to a clause in his work contract, Scott needs to work out of the Portland office for the next six months.
In order to keep Scott’s address book up to date, Outlook will trigger an OAB download every 24 hours (based on the time it was last successfully downloaded), connecting to the Redmond CAS infrastructure which proxies the request to the Redmond Mailbox server that hosts the OAB generation mailbox that generates the Redmond OAB.
Having Scott’s OAB files downloaded across the WAN is not an optimal experience. Obviously, the administrator could point Scott’s mailbox to the Portland OAB instance; however, that would require Scott’s client to undergo a full OAB download. Unfortunately, prior to CU7, this is the only way to mitigate this scenario.
Shadow Distribution in Cumulative Update 7
Exchange 2013 Cumulative Update 7 introduces the capability for an OAB generation mailbox to host a shadow copy of another OAB. This functionality enables additional Mailbox servers to be an endpoint for OAB download requests. By default, this feature is disabled and is configurable per OAB.
CU7 Behavior

Referring back to our previous example, once shadow distribution is enabled for the Redmond OAB, Scott’s Outlook client, via the Autodiscover response his client gets from the Portland CAS (which as we know is actually going to be generated on the mailbox server in the Redmond site, as that’s where Scott’s mailbox is), will now access the Redmond OAB using a URL resolving to the Portland CAS infrastructure (https://pmail.contoso.com/oab/redmond oab guid/); this is accomplished by Autodiscover leveraging the X-SourceCafeHeader value specified in the HTTP proxy request. The first time an attempt is made to access this OAB will result in a 404 response as the OAB files do not exist on the Portland Mailbox server that hosts the OAB generation mailbox, OAB Mailbox 1. This event invokes the OABRequestHandler, which initiates an asynchronous transfer, via BITS, of the Redmond OAB files to the Portland MBX server hosting the OAB generation mailbox. During the next attempt to synchronize the OAB, Scott’s Outlook client is able to download the necessary OAB files locally.
How do I enable shadow distribution?
The GlobalWebDistributionEnabled and VirtualDirectoriesproperties of an OAB are still used by Autodiscover to determine which CAS OAB virtual directories are eligible candidates for distributing the OAB. Given the architecture in Exchange 2013, any CAS can proxy an incoming OAB request to the right location, therefore, with CU7 and later, the recommendation is to enable global web distribution for all OABs hosted on Exchange 2013.
Set-OfflineAddressBook -VirtualDirectories $null

Set-Mailbox “OAB Mailbox 3” –Arbitration –OABGen $true
Once global distribution is enabled and OAB generation mailboxes are deployed, you can then enable shadow distribution on a per-OAB basis:
Set-OfflineAddressBook “Redmond OAB” -ShadowMailboxDistributionEnabled $true
How do I disable shadow distribution for an OAB?
You can disable shadow distribution on a per-OAB basis:
Set-OfflineAddressBook “Redmond OAB”
-ShadowMailboxDistributionEnabled $false
Does accessing a shadow copy trigger a full OAB download?
As discussed in OAB Improvements in Exchange 2013 Cumulative Update 5, the reason we moved to having a single OAB generation mailbox generate an OAB was to ensure that the OAB instance remained unique within the organization. Prior to CU5, all OAB generation mailboxes generated their own unique instances of the OABs, which resulted in full downloads any time a client was proxied to a different OAB generation mailbox.
The shadow copy is only distributed on-demand and is an exact duplicate of the OAB that is generated by the “master” OAB generation mailbox. As a result, an Outlook client will not be forced to perform a full download upon accessing the shadow copy files. The OABv4 conditions in Using Offline Address Books describes the conditions that can trigger a full download of an OAB.
What does the client experience when a shadow copy is triggered?
If the OAB files do not exist on the Mailbox server hosting the OAB generation mailbox, then the Outlook client will report error 80190194 (BG_E_HTTP_ERROR_404).
Error in Olk

How does a shadow distributed OAB get updated?
As soon as a new OAB is generated and published on the “master” Mailbox server, all the Mailbox servers hosting shadow copies will stop distributing their now-outdated copies. The first user who requests access to the OAB will trigger a full synchronization of the OAB to the shadow copy. The following events are reported:
Event ID: 102
Source: MSExchange OABRequestHandler
Description: The OABRequestHandler has begun downloading the OAB 9cc998e8-6226-4b60-957c-0125f8eabb57 from the server red-mbx-01.contoso.com.
Event ID: 103
Source: MSExchange OABRequestHandler
Description: The OABRequestHandler has finished downloading the OAB 9cc998e8-6226-4b60-957c-0125f8eabb57.
The OABRequestHandler will make up to three subsequent attempts to copy the OAB files from the Mailbox server where the master OAB generation mailbox is located. If all three attempts fail, the OABRequestHandler will retry the transfer after one hour.
Event ID: 104
Source: MSExchange OABRequestHandler
Description: Download of the OAB 9cc998e8-6226-4b60-957c-0125f8eabb57 failed. The job will be re-submitted. The error was: BG_ERROR_CONTEXT=BE_ERROR_CONTEXT_REMOTE_FILE; error code=0x80190194
Event ID: 105
Source: MSExchange OABRequestHandler
Description: Download of the OAB 9cc998e8-6226-4b60-957c-0125f8eabb57 has failed too many times. The job will not be resubmitted for the next hour.
What happens if I enable shadow distribution for an OAB, but there is no OAB generation mailbox in the site where the user is located?
When shadow distribution is enabled, Autodiscover will return the OAB URL for the site from which the user request initiated. If there is no OAB generation mailbox within that site, then CAS will simply proxy the request back to the Mailbox server hosting the OAB generation mailbox that is responsible for generating the OAB.
Summary
Shadow distribution completes our work on improving the OAB capabilities in the on-premises product and hopefully satisfies the requests from our customers that deploy distributed messaging environments. As always, we welcome your feedback.
Ross Smith IV
Principal Program Manager
Office 365 Customer Experience
Updates
11/12/14: Added additional information on client experience and application events on download.
On premises, Client Access, planning and architecture, Outlook, Exchange 2013
Share on Facebook Share on LinkedIn Share on Reddit Share on Twitter More
Leave a Comment
Name

Comment

Post
Comments
Exchange Queries Exchange Queries 29 Oct 2014 4:55 PM #
Great Article Ross….Quick Question…if we have multiple Mailbox Server on Portland site, is it possible to customize or configure Shadow Copy OAB to specific server..or we can able to move this shadow OAB to different server…during maintenance/shutdown activity/hardware failure and also for HA
Ross Smith IV Ross Smith IV 29 Oct 2014 5:07 PM #
@Exchange Queries – The only Mailbox servers that can become a shadow distribution point are those servers that host an OAB generation mailbox. HA is provided via the mailbox database. When the database copy that hosts the OAB generation mailbox is activated on a different Mailbox server, it can become a shadow distribution point the next time it is accessed via CAS proxy.
Jeff Guillet [MCM, MVP, Author, Blogger] Jeff Guillet [MCM, MVP, Author, Blogger] 29 Oct 2014 6:08 PM #
Nice example, Ross. 🙂 http://bit.ly/1FW1MXY

It sounds like the first user to request the shadow copy of the OAB might have a delayed download of the OAB, since the local copy is updated on demand, is that right? Anything we should be aware of here?
billroland billroland 30 Oct 2014 4:08 PM #
You guys realize that OAB with MAPI over HTTP is broken by the October Outlook 2013 update (KB2986204), right?
William Yang [MCM_MVP_Partner] William Yang [MCM_MVP_Partner] 30 Oct 2014 4:59 PM #
“The first user who requests access to the OAB will trigger a full synchronization of the OAB to the shadow copy”. Does it mean that the first user will fail to get latest OAB to download in first try? So shall we write some Powershell script to trigger that shadow distribution time by time to avoid this?