Messaging and Colloboration

Thursday, 7 July 2016

Evolution of Offline Address Book (OAB) Architecture in Exchange Servers

Offline Address Book is used by outlook clients for address book lookup when it is configured for working in cached mode. Outlook client will always query local OAB first for address lookup. There were no major changes in OAB architecture after Exchange 2007. Team Exchange introduced major changes in OAB architecture in Exchange 2013.
In server side, OAB has 2 main phases,
  • OAB Generation
  • OAB Distribution

Below table differentiates OAB generation and distribution process in Exchange 2010 and 2013
Exchange 2010
Exchange 2013
OAB Generation:
  • OAB generation was bound to specific server (mailbox).
  •  First Exchange mailbox server was designated as OAB Generation server.
  • We can also add additional OAB Generation servers

Get-OfflineAddressbook “Default Offline Address book” | fl name,server
This cmdlet will give you which server is designated as OAB generation server.

Better user accessibility.
Single point of failure, since OAB generation was bound to specific server.

OAB Generation:
  •   OAB Generation was not bound to specific server. OAB is generated by Mailboxes.
  • It uses special type of ‘Arbitration mailboxes’ called “Organization Mailbox”

Get-OfflineAddressbook “Default Offline Address book” | fl name,server
This cmdlet won’t show any designated server.
Tip: if the above cmdlet won’t return any output, then run the below cmdlet,
Set-AdServerSettings -ViewEntireForest $true
Greater resiliency in OAB Generation.

Inefficient user experiences.
Component that generates OAB:

  • Microsoft Exchange System Attendant service

  • OAB Generation was a scheduled process, i.e. OAB generation would start at the scheduled time irrespective of the server load.
  • Default schedule runs at 5 AM every day.

Component that generates OAB:

  • OAB Generator assistant (time-based assistant).
  •  It’s a mailbox assistant running under MS Exchange Mailbox Assistants Service.
  • It’s a throttled process, so it runs or pauses based on the server load.

To view the OAB Generation schedule,
Get-OfflineAddressbook “Default Offline Address book” | fl name,schedule

OAB Storage:

OAB generated by mailbox servers are stored in “C:\Program Files\Microsoft\Exchange Server\V14\OAB”. Then folder was shared so that CAS could retrieve OAB files for distribution.

OAB Storage:

In Exchange 2013, OAB files are generated and stored in Organization mailbox first later  copied to “C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\OAB”
OAB Distribution:

Exchange 2010 supports 2 types of distribution,
  • Web Distribution
  • Public folder distribution

Steps involved in OAB distributions,
  1. Outlook receives OAB URL from Autodiscover and reaches CAS server.
  2. CAS pulled OAB (using MS Exchange File Distribution service) generated on the mailbox server and stored it locally.
  3. CAS authenticate users and serves OAB file from its local storage.

OAB Distribution:

Exchange 2013 supports only Web distribution method

Steps involved in OAB distribution,
  1. Exchange 2013 CAS doesn’t store anything. So It proxies all OAB download request to appropriate mailbox server.
  2.  Outlook receives OAB URL from Autodiscover and reaches CAS server through OAB URL.
  3. CAS performs initial authentication for OAB requests.
  4. CAS Queries AD to find the closest organization mailbox for that user
  5. Also CAS queries Active manager to find out the mailbox server that’s hosting active mailbox database copy.
  6.  Then CAS Proxy the request to the identified Mailbox severs.
  7. Retrieves OAB and passes them to client.

In Exchange 2013, OAB files are stored in “C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\OAB” location. Specifically OAB files are stored to GUID folder of the OAB object. Inside this subfolder lot of .lzx files were created along with .xml files. In fact OAB files are first stored in temp location in OAB folder before they are copied to GUID folder.
Evolution of OAB Architecture since Exchange 2010.
In Exchange 2010, OAB was generated by a particular server within your organization.

In a distributed messaging environment, each site has an OAB generated based on ‘Default Global Address List’, it allow local users to download OAB without any traversing. If travels other site then his outlook application download OAB changes via WAN link, it’s a costly process. This architecture offers greater flexibility but it’s prone to Single point of Failure.
So in Exchange 2013 OAB is generated by a special type of ‘Arbitration Mailbox’ called ‘Organization mailbox’ rather than a server. It also utilizes Exchange 2013 high availability (DAG) by keeping database copies in various servers.

For connectivity,
  1. Autodiscover provides OAB url for the site which has user’s mailbox.
  2. That url resolves to a CAS server.
  3. CAS server will proxy the request to the mailbox server implies OAB mailbox in the local site

a.      If there is no OAB generation mailbox in the local AD site, CAS picks the mailbox in other sites with ‘lowest connection cost’.
                                                              i.      In other site, more than one OAB mailbox with the same connection cost found, then CAS will chose one at random.

Some shortfalls of this architecture,
  • Each OAB generation mailbox generates and stores all the OAB’s in the environment. In the above scenario both Redmond and Portland OAB generation mailbox generate Redmond and Portland OAB’s.
  • Each OAB generation mailbox generates an OAB that is unique when compared to the same OAB generated by other OAB generation mailboxes.

If user travels other site, outlook application will download full OAB each time outlook synchronization request is processed in a different site.

Also Having more than one OAB generating mailbox in a single site leads to a problem because they produces two unique, separate instances of both OAB generating mailboxes. Consider an example, If Redmond site has two OAB’s, then user who is having mailbox in Redmond is directed to Redmond CAS, and the CAS proxies to any one of the OAB mailboxes, so each time outlook client will directed to different OAB, resulting in a full OAB download each time.

To address some inefficiencies in above situation, Exchange Server 2013 Cumulative Update 5 came up with a solution called “Dedicated OAB Generation Mailboxes”. In CU5 an OAB can only be assigned to a single OAB generation mailbox.

So now Redmond users will only download the Redmond OAB from the Redmond AD site and Portland users will only download the Portland OAB from the Portland AD site.
However the above architectural changes did not improve user accessibility in a distributed environment. So Microsoft introduced a new concept “Shadow Distribution” in CU7.

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. This feature is disabled by default.

Consider an example, user who is having mailbox in Redmond travelling to Portland. So the client got OAB url via autodiscover response, so the client will now access the Redmond OAB using a URL resolving to the Portland CAS infrastructure ( oab guid/). This is accomplished by Autodiscover leveraging the X-SourceCafeHeader value specified in the HTTP proxy request.

The first attempt made to access OAB will resulting 404 response (OAB does not exist on the Portland mailbox server that hosts OAB generating mailbox). 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, user’s Outlook client is able to download the necessary OAB files locally.

How to enable Shadow Distribution?
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. Also it is recommended to enable ‘global web distribution’ for all OAB’s hosted on Exchange 2013.
Set-OfflineAddressBook <Name_of_OAB> -VirtualDirectories $null
Set-OfflineAddressBook < Name_of_OAB > -GlobalWebDistributionEnabled $true
Prior to enabling shadow distribution, you should deploy an OAB generation mailbox in each AD site where Exchange 2013 infrastructure is deployed.
New-Mailbox -Arbitration -Name "New_OAB_Mailbox" -Database "MDB004" -UserPrincipalName –DisplayName "New OAB Mailbox"
Set-Mailbox "New OAB Mailbox" –Arbitration –OABGen $true
Once global distribution is enabled and OAB generation mailboxes are deployed, you can then enable shadow distribution on per-OAB basis,
Set-OfflineAddressBook "Redmond OAB" -ShadowMailboxDistributionEnabled $true

No comments:

Post a Comment