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:
- OAB Virtual Directory
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:
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\.
- 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.
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.
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:
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 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.
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 email@example.com