OAB Improvements in Exchange 2013 Cumulative Update 7

Note: Cumulative Update 7 (CU7) for Exchange Server 2013 will be released soon^TM.

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:

1. Enabled administrators to define where an OAB is generated.
2. 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: 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. 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 <E15OAB> -VirtualDirectories $null
Set-OfflineAddressBook <E15OAB> -GlobalWebDistributionEnabled $true

Prior to enabling shadow distribution, you should deploy an OAB generation mailbox in each Active Directory site where Exchange 2013 infrastructure is deployed (assuming CU7 or later is deployed in each site).

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

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

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