Changes in OAB generation
In Exchange 2010 servers there is only one server was configured for OAB generation, and it was a single point of failure. If this server was unavailable for a long period, the OAB generation was affected.
In Exchange 2013, the OAB is generated by each Exchange 2013 Mailbox server(s) that hosts a special type of arbitration mailbox, called organization mailbox. OAB generation is not bound by the Server parameter anymore.
Which component will generate the OAB?
The Microsoft Exchange System Attendant service was the workhorse responsible for OAB generation in previous Exchange versions. The OAB generation was a scheduled process, i.e. OAB generation would start at the scheduled time configured on the OAB property, irrespective of the work load on the server.
In Exchange 2013, the OABGeneratorAssistant, a mailbox assistant running under the Microsoft Exchange Mailbox Assistants service, generates the OAB. Like most other mailbox assitants, the OABGEnerationAssistant is a throttled process – it runs or pauses according to the workload on the server.
Where are the OAB files stored?
In previous Exchange versions, the OAB generated by the Mailbox server was located in the %ExchangeInstallPath%\ExchangeOAB folder. The folder was shared so the CAS could retrieve the OAB files for distribution to Outlook clients.
In Exchange 2013, the OAB files are generated and stored in the Organization Mailbox first and later copied to the %ExchangeInstallPath%\ClientAccess\OAB\ folder.
Changes in OAB distribution
Exchange 2007 and 2010 supported two methods of OAB distribution: web distribution and Public Folder distribution. Exchange 2013 supports only the web distribution method, so let’s explore the changes in web-distribution method.
The Exchange 2007/2010 CAS pulled the OAB files generated on the respective Mailbox server and stored them locally. The Microsoft Exchange File Distribution Service on the CAS role did the task of pulling OAB files.
This was the flow OAB download from client side:
- Outlook receives OAB URL from Autodiscover and reaches a CAS server.
- The CAS authenticates the user and serves OAB files from local disk.
Couple of disadvantage with this method:
- The OAB download fails if the CAS doesn't have the OAB files locally.
- If the File Distribution Service on CAS isn't working, clients will receive stale OAB files or, in other words will not receive the updates.
In Exchange 2013, OAB files are not stored locally on the CAS. CAS 2013 proxies all OAB download requests to the appropriate Exchange 2013 Mailbox server. With this change in the architecture, the Microsoft Exchange File Distribution Service is removed from the CAS role.
In Exchange 2013, this is the flow of OAB download:
- Outlook receives OAB URL from Autodiscover and reaches designated CAS 2013 through OAB URL.
The CAS server performs the following actions:
- Performs initial authentication for OAB.
- Queries Active Directory and determines the closest Organization Mailbox for the requesting user.
- Queries Active Directory again to determine the mailbox database hosting the Organization Mailbox.
- Queries the Active Manager to determine the mailbox server where the mailbox database is active (mounted).
- Proxies the request to the Mailbox server identified in step 4.
- Retrieves OAB files and passes them to the client.
This new workflow overcomes the disadvantages of legacy OAB download workflow.
The Organization Mailbox
The Organization Mailbox is a new type of arbitration mailbox introduced with Exchange 2013. The arbitration mailbox with persisted capability OrganizationCapabilityOABGen is referred to as Organization Mailbox. It plays a crucial role in OAB generation, storage and distribution.
Each Exchange Server 2013 mailbox role hosting an Organization Mailbox will generate all Exchange 2013 OAB’s defined in the environment. The OAB is generated in the Organization Mailbox first and later copied to the disk.
Use the following command to identify the Organization mailbox:
Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"}
Storing the OAB files in the Organization Mailbox makes the OAB files more resilient.
Putting it together: A real-life scenario:
The following scenario puts together the critical points we learned so far:
- MBX1 and MBX2 are Exchange 2013 Mailbox servers and member of a DAG. CAS1 is an Exchange 2013 CAS.
- The organization mailbox is present on mailbox database DB1. DB1 has copies on MBX1 and MBX2.
- DB1 is currently active on MBX1.
- The Microsoft Exchange Mailbox Assistants service on MBX1 will generate the OAB.
- The OAB will be first generated in the organization mailbox and later copied to disk of MBX1. At this point, MBX2 is not playing any role in OAB generation.
- An Outlook client tries to download OAB, and reaches CAS1 through OAB URL.
- CAS1 queries Active Manager and finds out database hosting organization mailbox (DB1) is active on MBX1.
- CAS1 proxies the OAB download request to MBX1 and serves the files back to the client.
- At this point, MBX1 goes down due to power failure and DB1 is activated on the server MBX2.
- CAS1 receives another request for OAB download, queries the Active Manager again and this time proxies the request to MBX2, as DB1 is now active on MBX2.
- MBX2 extracts OAB files present in the organization mailbox to the disk, to ensure latest files are served to the client.
- MBX1 comes back online, but DB1 remains active on MBX2.
- At next OAB generation work cycle, the Microsoft Exchange Mailbox Assistants service on MBX2 will generate the OAB.
Dedicated OAB Generation Mailboxes in Cumulative Update 5
CU5 moves away from the previous model where an OAB generation mailbox generates all the OABs in the organization. While an OAB generation mailbox can continue to generate multiple OABs (the default behavior when you deploy Exchange 2013), what’s new in CU5 is that an OAB can only be assigned to a single OAB generation mailbox.
This architectural change addresses the aforementioned deficiencies:
- By allowing administrators to define where an OAB is generated.
- By removing the capability to have multiple instances of the same OAB, mitigating the scenario where a client could hit a different OAB instance triggering a full OAB download.
From a connectivity perspective, Autodiscover provides back an OAB URL for the site in which the user’s mailbox is located. That URL resolves to a Client Access server which proxies the request to the linked OAB generation mailbox that is responsible for generating the requested OAB.
What happens to my existing OABs when I upgrade to CU5?
When you upgrade to CU5, all existing OABs are linked to the system arbitration mailbox, SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}, regardless of whether there are additional OAB generation mailboxes within the environment. This ensures that all OABs are still generated after CU5 is installed. This has two implications:
- If you were not aware of our guidance of deploying only a single OAB generation mailbox per organization, and instead, deployed multiple OAB generation mailboxes, those mailboxes will no longer generate OABs after the servers hosting their databases are upgraded to CU5. This means that Outlook clients will perform a full OAB download (as they are now accessing a different OAB instance).
- Once you dedicate an OAB to a specific OAB generation mailbox, this will be a new OAB instance and thus, will trigger a full download for the Outlook clients.
Note: Users will not experience full OAB downloads after CU5 is deployed if your deployment does not contain multiple OAB generation mailboxes.
