How OAB Distribution Works in Exchange 2013

Back in May 2009 I wrote an article entitled "How OAB Distribution Works" which covered in detail how OAB distribution works in Exchange 2007/2010.  Over the past years this article has received great feedback and has been referenced in multiple online articles, blogs and forum posts.  The article can be found under the following URL:

http://clintboessen.blogspot.com.au/2009/05/how-oab-distribution-works.html

In Exchange 2013, OAB Distribution has changed significantly removing a single point of failure to OAB Distribution and minimising the performance impact OAB Distribution has on an Exchange Server.  In this article we will be covering the new OAB Distribution in Exchange 2013

Exchange 2013 OAB Distribution

The Offline Address Book is an offline copy of the address lists within Exchange for Outlook clients running in cached Exchange mode.  The Offline Address Book is important within Exchange environments as not only does it allow Outlook clients to see the address lists when offline but also it significantly reduces the amount of address book lookups decreasing Exchange server work load.

In Exchange 2013 there are 3 components which make the OAB Distribution work:

• OABGeneratorAssistant
• OAB Virtual Directory
• Autodiscover

The OAB Virtual Directory and Autodiscover components work similar as they did in Exchange 2007/2010 however the OABGen process in Exchange 2013 has been completely rebuilt into the new OABGeneratorAssistant component.

OABGeneratorAssistant

In Exchange 2007/2010 the OABGen was located under C:\Program Files\Microsoft\Exchange Server\V--\Bin\OabGen.dll.  This dynamic link library was invoked by the Exchange System Attendant service according to the OABGen schedule configured.  The primary problem with OABGen in Exchange 2007/2010 was each offline address book was bound to one mailbox server responsible for generating the OAB, a single point of failure.

The new OABGeneratorAssistant process in Exchange 2013 no longer uses the OabGen.dll dynamic link library, in fact this file has been completely removed.  The OABGeneratorAssistant is actually a mailbox assistant which runs as part of the Microsoft Exchange Mailbox Assistants service.  As with other mailbox assistances, the Microsoft Exchange Mailbox Assistants service will throttle the OABGeneratorAssistant process to ensure it does not utilise 100% of the server CPU and run at times when the server has least work load.

To get around the OABGen single point of failure which existed in Exchange 2007/2010, Microsoft now leverage Database Availability Groups (DAGs) in Exchange 2013 for OAB Generation.  Instead of generating the OAB to a folder on a mailbox server and copying the OAB to every client access server for distribution, the OAB is now stored inside an Arbitration mailbox which has been enabled for OABGen.  By default, the only Arbitration mailbox which is configured to hold the OAB is the default System Mailbox with the following GUID:

SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}

By leveraging Database Availability Groups (DAGs), whichever server holds the database containing the default Arbitration mailbox (configured with the OrganizationCapabilityOABGen capability), will be responsible for generating the offline address books.  This server can change depending on which mailbox server is holding the Active copy of the mailbox database containing the OrganizationCapabilityOABGen Arbitration Mailbox.

When the OABGeneratorAssistant runs it performs the following core tasks:

• Generates the OAB files to the OrganizationCapabilityOABGen Arbitration Mailbox
• Copies the files from the OrganizationCapabilityOABGen Arbitration Mailbox to %ExchangeInstallPath%\ClientAccess\OAB\.

Important: The OAB is no longer "distributed" to Client Access Servers for distribution, a result the Exchange File Distribution Service was removed in Exchange 2013.  I will explain how clients gain access to the OAB files in the next section "OAB Virtual Directory".

Like before, OAB Generation runs according to a schedule which is now defined on the mailbox servers.  The default schedule is to process the OAB every 8 hours over a period of 1 hour.

• The OABGeneratorWorkCycle parameter specifies the time span in which the OAB generation on the specified server will be processed.
• The OABGeneratorWorkCycleCheckpoint parameter specifies the time span at which to run OAB generation.

It is important to set these values across all Mailbox servers the same to ensure in the event a database failover occurs, the new server responsible for generating the OAB will continue to adhere to the set schedule.

It is also possible to force OAB Generation.  Despite a complete architecture change in OAB Generation, Microsoft was nice enough not to change the command which generates the OAB.  To forcefully generate all Offline Address Books across your environment, simply run the following PowerShell command:

Get-OfflineAddressBook | Update-OfflineAddressBook

 

As mentioned above OABGeneratorAssistant will first generate to the OrganizationCapabilityOABGen Arbitration Mailbox and then copy the files to the mailbox server performing running OABGeneratorAssistant.  Depending on how many users it may take a few minutes to complete and copy to the mailbox server.

 

Like before, each OAB will be represented by a GUID.  You will know when the process finishes as the Date modified on the OAB files will update.

 

 

If you would like to track the generation process simply look at the event logs for the following events upon an OAB Generation.

 

 

 

By default in a new installation of Exchange 2013 there is only one mailbox which contains the OAB as mentioned above SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}.  Companies however can create additional Arbitration mailboxes which have the OAB Gen capability.  This can be done for redundancy encase the SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c} became corrupt or for servicing users which are geographically distributed.  For example, a company with offices in Australia and Europe will want the OAB Generated locally in each continent and ensure users are not downloading OABs across international links.

 

When there are multiple Arbitration mailboxes which are configured with OrganizationCapabilityOABGen, multiple mailbox servers hosting the active databases will be responsible for performing OAB Generation.

 

To configure additional Arbitration mailboxes with the OrganizationCapabilityOABGen simply use the following PowerShell command:

 

New-Mailbox -Arbitration -Name "OAB Australia" -Database Leeming-DB1 -UserPrincipalName OABAustralia@avantgardetechnologies.com.au –DisplayName "OAB Mailbox for Australia"

 

Next to configure the OrganizationCapabilityOABGen ability, run the following PowerShell command against the mailbox.

 

Set-Mailbox -Arbitration OABAustralia -OABGen $true

 

 

This pretty much sums up the new OABGeneratorAssistant in Exchange 2013.  I also recommend reading an article I posted on Mimecast towards the end of last year entitled "The New OAB Generation, the Good and the Bad".  Whilst the new OAB Generation has removed the single point of failure in the Exchange 2007/2010 design, there are new challenges which are present for companies in multi-tenant configurations.  The article published on Mimecast goes into this in more detail and can be found at the following address:

 

http://blog.mimecast.com/2013/11/exchange-2013-new-oab-generation-the-good-and-the-bad/

 

OAB Virtual Directory

 

The OAB Virtual Directory runs on all Exchange 2013 servers running the Client Access role.  This provides a way for Outlook clients to download the offline address book.  If you have a multi-role Exchange 2013 server, look in the Default Web Site (which is the Front End Client Access) under OAB.  Outlook clients connect to this for downloading the Offline Address Book.

 

 

Unlike Exchange 2007/2010, the Offline Address Book is no longer "distributed" to the Client Access servers however.  This can be shown by opening the web folder.

As you see there is no GUID representing any Offline Address Books or associated address book files.  Just the standard files relating to IIS exist.

 

This is because in Exchange 2013 Client Access servers now "proxy" the connections to the closest mailbox server holding an Arbitration mailbox with the OrganizationCapabilityOABGen.  If you only have one Arbitration mailbox with OrganizationCapabilityOABGen enabled (the default), but you have multiple sites, Client Access servers proxy these requests across WAN links to ensure users can download the OAB.

As I have both a Client Access (front end) and Mailbox (backend) on the same server, the proxy will simply pass through to the Exchange Back End website OAB folder which does contain the OAB as shown below:

If you would like information into what mailbox server the client access is proxying OAB requests to or any additional information regarding the proxying which is going on, view the OAB Proxy log files which can be found under:

%ExchangeInstallPath%\Logging\HttpProxy\OAB\

In the event a client access server finds more then one Arbitration mailbox with OrganizationCapabilityOABGen  enabled, the Client Access server will load balance the proxied requests automatically between the Arbitration mailboxes in a round robin fashion.

Now that you understand how Exchange client access proxies the requests you can see the importance to ensure additional OrganizationCapabilityOABGen capable Arbitration mailboxes exist at remote sites to ensure proxied traffic does not cross WAN links.

Autodiscover

Autodiscover is responsible for letting Outlook 2007-2013 clients know which Client Access server they should connect to for downloading the latest OAB.  I can view this by holding down CTRL and right click on the Outlook icon in my system tray I am able to click Test E-Mail AutoConfiguration.

The OAB URL in the output below shows where Outlook clients are connecting to for the OAB download.

It is possible to change the URL Autodiscover gives out on each Client Access server by modifying the Internal and External URLs.

• The Internal URL is used by clients directly connected to the corporate network.
• The External URL is used by clients connecting in remotely from the Internet.

My environment has split DNS configured so I'm using the same internal/external URLs.  If your using HTTPS the name entered must represent a name on your digital certificate.

To modify the path for the Internal URL in the example above, you would use the following command:

Set-OabVirtualDirectory -Identity "CASSERVERNAME\OAB (Default Web Site)" -InternalURL https://mail.mydomain.local/OAB -RequireSSL $true

To modify the path for the External URL in the example above, you would use the following command:

Set-OabVirtualDirectory -Identity "CASSERVERNAME\OAB (Default Web Site)" -ExternalURL https://mail.mydomain.com/OAB -RequireSSL $true

I hope this post has been helpful and I would like to thank you for reading.  Any questions feel free to send me an email at clint.boessen@avantgardetechnologies.com.au