需要花很长时间…

原文发布于 2012 年 2 月 20 日（星期一）

在最近的 Exchange 2010 Service Pack 2 更新汇总 1 发布公告中，您会发现，我们发布了许多修补程序，我想通过这篇博客专门介绍其中一个修补程序，同时或许还能够提供一些背景信息以了解这些问题的根源以及如何修复它们。

该特定修补程序称为 2556113（该链接可能指向英文页面），标题为 “用户需要花很长时间在 Exchange Server 2010 组织中下载 OAB” 。

看到这样的标题，您可能认为我们只需确定一种方法来“加快”OAB 的下载速度。您开始可能会认为，我们只通过从 OAB 中随机删除一些您并不认识的用户（比如，在四楼财务部门工作的人员）的数据，来实现此目的。或者，我们或许只需通过删除不需要的信息（比如，家庭成员的姓名、办公室地址或电话号码）来尝试减少 OAB 中包含的详细信息；亦或我们只需要提高 Internet 的速度，因为这的确很容易做到。

不过，我们并没有做这些事情；（但我们会对整个 Internet 的状况进行调查以确定我们对此可以采取哪些措施，因为这听起来不错）相反，我们增加了一些逻辑，以确保 Outlook 能够尝试从离它最近的 CAS 下载 OAB。

您一定会问：“为什么？”问得好。我的答复是“如上面的 KB 文章指出，‘请考虑下面的情形…’”

• Microsoft Exchange Server 2010 组织的慢速网络中有两个 Active Directory 站点。
• 在其中一个 Active Directory 站点上有一台 Exchange Server 2010 客户端访问服务器和一台 Exchange Server 2010 邮箱服务器。
• 在另一个 Active Directory 站点上有一台 Exchange Server 2010 客户端访问服务器，并且您在该站点上添加了一名 Office Outlook 用户。
• 其邮箱位于另一 Active Directory 站点上的用户尝试下载 Exchange 脱机通讯簿 (OAB)。

在这种情形下，可能需要花很长时间来下载 OAB。

的确如此，并没有开玩笑。如果您的 OAB 很大，确实需要花很长时间。不过，让我们对此情形做稍许补充，因为我认为您需要了解一些信息，并且对大多数用户而言，使用只包含 CAS 而无其他任何内容的 AD 站点似乎并不是一个十分明智的选择。

因此，请另行考虑下面这一更详细的情形；

• 您进行了集中部署。所有邮箱都位于一个中央位置。
• 用户分散在许多小地方，并在那里完成工作。
• 这些位置通过状况不好的网络连接到中央站点。这些网络包括人造卫星、ISDN、PSTN、对流层散射（该链接可能指向英文页面）（我的一个客户曾经使用过其中一种网络，性能不错，直到遭遇一场暴风雨）、导电线缆等。
• 您的 OAB 非常大，一点都不小。任意选择您最喜欢的定义。说得更明白些，它已达到您所关注的大小。
• 您的 Outlook 客户端尝试下载 OAB，并且它来自中央数据中心。由坐在您旁边的用户以及坐在角落里的长相有趣的用户使用的 Outlook 客户端也是如此。你们所有人都正在通过同一导电线缆下载 同一 OAB。下载速度非常慢。

幸运的话，您会发现，你们都在争用同一带宽，同时还要努力工作，并且即使用于下载 OAB 的 BITS 客户端技术不错，但它实际上对您也不会有多大帮助。

因此，您在每个远程位置添加了一个 CAS。事实上，正如 https://technet.microsoft.com/zh-cn/library/bb232155.aspx 中详细图表中建议的那样。这种想法是，客户端计算机将从本地 CAS 下载它所需的 OAB。听起来这是一个不错的想法，但它不是 Exchange 已有的工作方式。在 2010 SP2 RU1 发布之前，Exchange 的工作方式是…

Exchange 以前如何工作？我为什么要告诉您 TechNet 并不总是正确？

先回答第一个问题，客户端用于从其下载 OAB 的 URL 由自动发现服务提供给客户端。自动发现代码始终从 您的 邮箱所在 的 AD 站点，而不是从 您的客户端计算机所在 的 AD 站点选取您应下载的 OAB 的 URL。

要回答第二个问题，您首先需要了解 TechNet 是从不会出错的（如果您暗示我的 UE 朋友（如 Scott Schnoll）所发表的文章信息不正确，他们一定会感到愤怒）。只不过有时从某种角度来说，它并不正确。在 2007 年作为原 PM 规范的一部分设计 TechNet 时，已详细说明了这一点。我或许不应该告诉您这些，但事实的确如此。它并非十全十美。您知道，当内容随时发生更改时，包含两千多万行代码的软件产品就会出现这种情况。TechNet 提供的信息通常准确无误。不准确的情况不多。

让我们回到工作方式这个问题上。对此问题思考片刻。您有一个 1 GB 的 OAB。您将该 OAB 的副本添加到用户所在的远程 AD 站点上的 CAS 中。但这些用户从不使用该 OAB。（除非他们的邮箱也位于同一 AD 站点上，但事实并非如此，不是吗？）很糟糕，不是这种情况。我确实听到您这样说。您所说的情形有点类似以下图表。

Outlook 使用离客户端计算机最近的 CAS 来响应客户端的自动发现请求（它 应该 这么做，稍后我们再来讨论这一点），但它所返回的 OAB URL 指向 邮箱 所在的 AD 站点中的 CAS。因此即使我们将 OAB 复制到 AD 站点 B，客户端也需要从 AD 站点 A 获取 OAB。

因此，具有许多小站点和庞大 OAB 的大型客户告诉我们，此过程无法实现并且下载会耗尽他们所拥有的广域网带宽。我们可以为此做些什么呢？事实证明，可采用多种方法解决此问题，并且我要补充一点，尽力尝试搞清此类问题是我的工作乐趣之一。这是一件有意义的事情。

1. 他们可以减小其 OAB 的大小，提高其广域网的速度，使远程办公室离总部更近一些等等。尽管我们曾要求客户采取这些措施，但其中没有一项措施能够帮助他们快速解决问题。
2. 我们可以创建许多包含相同内容的 OAB。在每用户或每数据库级别指定用户应下载的 OAB。然后，我们仅允许在远程位置使用该 OAB。这样，自动发现将在远程位置提供它可以为 OAB 提供的唯一 URL。目前这听起来还不错，但用户会在站点之间移动。因此下载过程会使网络速度降低一半。算了，放弃这种想法。
3. 邮箱也是如此 – 将邮箱移动到远程位置… 但来回移动它们事实上会增加管理复杂性和降低高可用性，进而会增加成本。
4. 我们可以将某种反向 IP 地址映射到 AD 站点。现在，我认为这是我们原来计划用于解决此问题的方法，但它实施起来有点困难。因为您需要确保包含客户端的所有子网均位于 AD 站点和服务中，然后尝试对用户所在的 AD 站点执行反向工程，并且要关注站点链接成本…想法不错。但它很复杂，会受到 NAT 的影响，并且管理员有可能没有在 AD 站点和服务中列出所有可能的子网。
5. 我们可以“干扰”DNS 或自动发现 XML，尝试使客户端认为它正在与中央位置通信，而事实上它正在与本地 IIS 实例通信。再次重申，此过程难以实现和获得支持，它只是一个不成熟的想法。
6. 其他方法。我选择其他方法，因为上述方法似乎真的难以实现。

回顾一下前面的几小段，有句话指出“Outlook 使用离客户端计算机最近的 CAS 响应客户端的自动发现请求”，我们再次关注这句话是因为它涉及一项名为 AutoDiscoverServiceSiteScope 的内容。

AutoDiscoverServiceSiteScope 是一个 CAS 设置，可帮助 Outlook 客户端将 AD 站点映射到 CAS，以查找离该客户端最近的 CAS，从而响应自动发现请求。该设置通过寻找服务连接点 (SCP)（它们实际上是指向自动发现服务的指针），来实现这一点。

此处是该设置的工作方式。当 Outlook 客户端启动时，它会将通信拦截到三角区（有时也称为“AD”），并查找 Exchange 安装程序放置在该位置的所有 SCP。它会找到许多连接点（我们希望如此），而每个连接点都是一个属性（Keywords 属性），使用 Set-ClientAccessServer –AutoDiscoverServiceSiteScope: ADSiteNameA, ADSiteNameB 等可设置/更改该属性，有时还会混淆该属性。Keywords 属性用于指定该 CAS 为响应自动发现请求而负责的 AD 站点。

当 Outlook 客户端找到多个 SCP 时，该设置会通过将 Keywords 属性中存储的值与其自己的 AD 站点（会在该设置启动或更改 IP 地址时由本地 Netlogon 服务动态更新）进行比较，来自行构建一组可用的 SCP。

然后，该设置会构建一个列表。并在其中输入与其 AD 站点匹配的所有 SCP（其中 Keywords 属性 = 客户端 AD 站点），如果没有匹配项，它会在该列表中放置所有 SCP。它们是该设置可用于其自动发现请求的服务器。

然后，它会从列表的顶部开始（始终根据该方法和安装日期按照相同的顺序）尝试连接到 ServiceBindingInformation 属性（自动发现服务本身所在的位置）中所包含的 URI。然后，它会发布 XML，获取响应，顺利地执行后续操作。有关此卓越自动发现服务的更多详细信息，请参阅此处。

为什么这很具吸引力？该 AutoDiscoverServiceSiteScope 设置可帮助 Outlook 查找离客户端位置最近的 CAS，而我们假定管理员已正确设置了网站范围（我们会告知管理员如何执行此操作）。 因此，当我们获得请求时，我们确实不需要指出哪个 CAS 离客户端最近，因为在请求到达 CAS 时就已指明了这一点。

当该请求选中 CAS 时，我们知道相应设置会返回到客户端，但我们总是忘记一点，即，用户需要的 OAB 对我们在其上执行请求的 CAS 来说可能是本地的，而我们总是为用户提供一个位置很远的 CAS 的 URL。这就是我们需要解决的问题。

从理论上讲很容易解决此问题，它表明我们不必设计一种新方法来指出离客户端最近的 CAS，因为我们已经获得的 CAS 能够出色地完成工作。

如果我们假定，管理员正确设置了 AutoDiscoverServiceSiteScope，并且客户端为自动发现连接到的 CAS 将是离客户端最近的 CAS。如果该假定始终成立，那么当在自动发现 XML 中指出要返回的内容时，该 CAS 只需检查以确定它自己是否具有用户应使用的 OAB 的副本，如果有，则该 CAS 只需提供 它自己的 OAB URL，而不是用户邮箱所在的 AD 站点中 CAS 的 OAB URL。当然，如果该 CAS 不具有用户所需的 OAB 的副本，则会执行以前的行为，即，该 CAS 将返回邮箱所在 AD 站点中 CAS 的 OAB URL。

因此，该图表会发生以下主要变化；

现在，是不是对广域网更有利了？通过广域网复制一个副本时，该位置的所有客户端现在都将从本地 CAS 获取 OAB。

要使此新的行为发挥作用，您需要做什么呢？只需做两件事：在 CAS 上部署 SP2 RU1，并确保正确设置 AutoDiscoverServiceSiteScope 参数。

希望这些内容会对您有所帮助，并希望您的广域网永远都是长肥管道（该链接可能指向英文页面）。

Greg Taylor
首席项目经理
Exchange 客户体验团队

这是一篇本地化的博客文章。请访问 It Takes a Long Time… 以查看原文