Exchange Server 2013 中的OAB原理介绍及设置

OAB 历史

脱机通讯簿（可称为 OAB）很长时间以来一直是 Exchange 基础架构中的关键组件。OAB 由 Microsoft Outlook 客户端在脱机时在缓存 Exchange 模式下用于通讯簿查找。OAB 还对减轻 Exchange 服务器上的工作负载起着重要作用，因为缓存模式 Outlook 客户端将始终先查询本地 OAB。

OAB 已随着 Exchange 版本发生了演变。OAB 体系结构的最近一次重大革新是在 Exchange Server 2007 中，我们在其中引入了 OAB 的 Web 分发，以及 CAS 服务器角色（主要负责分发 OAB）。但 OAB 生成过程本身并未发生太大变化。

但现在情况已发生变化。

随着 Exchange Server 2013 中引入的服务器角色体系结构的变化，我们还更改了 OAB 的生成方式和分发给客户端的方式。让我们通过将 Exchange 2013 中的新 OAB 与其先前版本相比较来探索它吧。

OAB 生成中的更改

哪个服务器将生成 OAB？

在以前的所有 Exchange 版本中，OAB 生成由 Server 属性绑定到特定 Exchange 服务器。安装第一台 Exchange 邮箱服务器时，安装程序会将其指定为 OAB 生成服务器。您可根据需要创建新的 OAB。创建新的 OAB 时，必须指定 OAB 生成服务器。

Exchange Server 2010 中的 OAB：

此方法的缺点在于只为 OAB 生成配置了一台服务器，它是单点故障。如果此服务器长期不可用，则会影响 OAB 生成。

在 Exchange 2013 中，OAB 由托管特殊类型的仲裁邮箱（称为组织邮箱）的每个 Exchange 2013 邮箱服务器生成。OAB 生成不再由 Server 参数绑定。

Exchange Server 2013 中的 OAB：

从特定服务器取消绑定 OAB 允许同一 OAB 由多个邮箱服务器生成。这一新的体系结构可在 OAB 生成中提供更好的复原能力。

哪个组件将生成 OAB？

Microsoft Exchange 系统助理服务是负责以前 Exchange 版本中的 OAB 生成的骨干。OAB 生成是计划的过程，即，OAB 生成将于在 OAB 属性上配置的计划时间启动，无论服务器上的工作负载如何。

在 Exchange 2013 中，OABGeneratorAssistant（在 Microsoft Exchange 邮箱助理服务下运行的邮箱助理）会生成OAB。与多数其他邮箱助理一样，OABGEnerationAssistant 是一个限制过程 – 它根据服务器上的工作负载运行或暂停。

OAB 文件存储在什么位置？

在以前的 Exchange 版本中，邮箱服务器生成的 OAB 位于 %ExchangeInstallPath%ExchangeOAB 文件夹中。该文件夹是共享的，因此 CAS 可检索 OAB 文件，以便分发到 Outlook 客户端。

在 Exchange 2013 中，生成的 OAB 文件先存储在组织邮箱中，稍后会复制到%ExchangeInstallPath%ClientAccessOAB 文件夹。

OAB 分发中的变化

Exchange 2007 和 2010 支持两种 OAB 分发方法：Web 分发和公用文件夹分发。Exchange 2013 只支持 Web 分发方法，所以让我们探索 Web 分发方法中的变化吧。

Exchange 2007/2010 CAS 提取在各自邮箱服务器上生成的 OAB 文件，并在本地存储这些文件。CAS 角色上的Microsoft Exchange 文件分发服务执行提取 OAB 文件的任务。

下面是从客户端进行 OAB 下载的流程：

1. Outlook 从自动发现接收 OAB URL 并到达 CAS 服务器。
2. CAS 对用户进行身份验证，并从本地磁盘提供 OAB 文件。

   此方法的一些缺点：

   1. 如果 CAS 本地没有 OAB 文件，则 OAB下载将失败。
   2. 如果 CAS 上的文件分发服务运行不正常，则客户端会收到旧 OAB 文件，或者换句话说，不会收到更新。

      在 Exchange 2013 中，OAB 文件未本地存储在 CAS 上。CAS 2013 将所有 OAB 下载请求代理到相关的 Exchange 2013 邮箱服务器。体系结构中进行此更改后，会从 CAS 角色中移除 Microsoft Exchange 文件分发服务。

      在 Exchange 2013 中，下面是 OAB 下载的流程：

      1. Outlook 从自动发现接收 OAB URL，并通过 OAB URL 到达指定的 CAS 2013。

         CAS 服务器执行以下操作：

         1. 对 OAB 执行初始身份验证。
         2. 查询 Active Directory 并确定离请求用户最近的组织邮箱。

         3. 再次查询 Active Directory，以确定托管组织邮箱的邮箱数据库。

         4. 查询活动管理器，确定其上的邮箱数据库处于活动状态（已装载）的邮箱服务器。
         5. 将请求代理到步骤 4 中标识的邮箱服务器。
         6. 检索 OAB 文件并将它们传递到客户端。

            此新的工作流克服了旧 OAB 下载工作流的缺点。

            组织邮箱

            组织邮箱是随 Exchange 2013 引入的新类型的仲裁邮箱。具有 OrganizationCapabilityOABGen 持续功能的仲裁邮箱称为组织邮箱。它在 OAB 生成、存储和分发中发挥着至关重要的作用。

            托管组织邮箱的每个 Exchange Server 2013 邮箱角色都将生成环境中定义的所有 Exchange 2013 OAB。OAB 先在组织邮箱中生成，稍后复制到磁盘。

            使用以下命令可标识组织邮箱：

            1	Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"}

            示例：

            1	Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "*oab*"}

            2	Name Alias ServerName ProhibitSendQuota

            3	---- ----- ---------- -----------------

            4	SystemMailbox{bb558c35... SystemMailbox{bb5... mbx1 Unlimited

            将 OAB 文件存储在组织邮箱中会使 OAB 文件的复原能力更强。

            将内容结合起来：真实情形

            以下情形将我们目前为止了解到的关键点结合在一起：

            1. MBX1 和 MBX2 是 Exchange 2013 邮箱服务器，并且是 DAG的成员。CAS1 是一个 Exchange 2013 CAS。
            2. 组织邮箱位于邮箱数据库 DB1 上。DB1 在 MBX1 和 MBX2 上具有副本。
            3. DB1 当前在 MBX1 上处于活动状态。
            4. MBX1 上的 Microsoft Exchange 邮箱助理服务将生成 OAB。
            5. OAB 将先在组织邮箱中生成，稍后复制到 MBX1 的磁盘。此时，MBX2 在 OAB 生成中不发挥任何作用。
            6. Outlook 客户端尝试下载 OAB，并通过 OAB URL 到达 CAS1。
            7. CAS1 查询活动管理器，它发现托管组织邮箱的数据库 (DB1) 在 MBX1 上处于活动状态。
            8. CAS1 将 OAB 下载请求代理到 MBX1，并将文件提供回客户端。
            9. 此时，MBX1 由于电源故障不可用，DB1 在服务器 MBX2 上激活。
            10. CAS1 收到 OAB 下载的另一请求，它再次查询活动管理器，这一次将请求代理到 MBX2，因为 DB1 现在于 MBX2 上处于活动状态。
            11. MBX2 将组织邮箱中存在的 OAB 文件提取到磁盘，以确保向客户端提供最新文件。
            12. MBX1 再次联机，但 DB1 在 MBX2 上仍处于活动状态。
            13. 在下一 OAB 生成工作周期，MBX2 上的 Microsoft Exchange 邮箱助理服务将生成 OAB。

                声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。