CAS 数组对象解密 - 第 2 部分

原文发布于 2012 年 3 月 29 日（星期四）

欢迎回来！在 CAS 数组对象解密 - 第 1 部分中，我们从讨论以下三条开始解密 Exchange Server 2010 中的 CAS 数组对象。

1. CAS 数组对象不对您的流量进行负载平衡
2. CAS 数组对象不向 OWA、ECP、EWS、自动发现、IMAP、SMTP 或 POP 提供服务
3. CAS 数组对象不需要作为您的 SSL 证书的一部分

这里，在第 2 部分中，我们将讨论后面三条，从而彻底揭开 CAS 数组对象的秘密，帮助您修正现有的部署和/或为未来的部署做出更具战略性的规划。

4. CAS 数组对象不应通过 DNS 由外部客户端解析
5. 创建 Exchange Server 2010 邮箱数据库并将邮箱移入数据库后不应配置或更改 CAS 数组对象
6. 即使只有一个 CAS 或一台多角色服务器，也应配置 CAS 数组对象。

4. CAS 数组对象不应通过 DNS 由外部客户端解析

如第 1 部分所述（至少有两次吧，我就不数了），您的 CAS 数组对象 FQDN 不应和用于其他服务（如 OWA、ECP、EWS、EAS、自动发现或 Outlook 无处不在外部主机名）的 FQDN 相同。

主要原因在于，Outlook 无处不在客户端会首先尝试通过 DNS 解析 CAS 数组对象 FQDN，所以它知道它是应当（甚至尽力）尝试 RPC (over TCP) 连接还是直接转向 HTTPS。您是否允许直接从 Internet 内到您的 Intranet 的 RPC (over TCP) 连接？我希望您不允许，否则，您会在您的 Exchange 风险和健康评估计划（该链接可能指向英文页面）报告上得到一个大大的危险信号。如果客户端由于能够成功解析 CAS 数组对象 FQDN 而的确先尝试通过 RPC (over TCP) 连接，则可能在延迟相当长时间后，客户端才转而尝试通过 HTTPS 连接到 Outlook 无处不在代理 URL。如果最终用户将这种延迟视为性能下降和/或服务中断，则这种延迟可能导致打到支持人员的求助电话次数增多。

为避免这种状况，只需确保您的内部 CAS 数组对象 FQDN 对内部 DNS 而言是独有的，也许就像 outlook.corp.contoso.com 这样，而您的其他非 RPC (over TCP) 服务 URL 通过拆分 DNS 在内部或外部利用像 mail.contoso.com 这样的形式。

如果您还没有获得机会利用拆分 DNS，那是因为您有一套内部和外部 DNS 服务器正在处理对同一正向查找区域（如 contoso.com）的请求。这两个 DNS 基础结构完全彼此隔离。没有区域传送，它们也不相互利用对方作为 DNS 转发器。此配置允许利用内部 DNS 基础结构的内部用户将主机 mail.contoso.com 解析为内部 IP 地址（例如，192.168.1.10），该地址指向您的负载平衡器 VIP，而外部用户将它解析为公共 IP 地址，该公共 IP 地址可能指向您的外围网络中的面向 Internet 的 Forefront TMG/UAG 基础结构。这在使 CAS 数组对象 IP 地址和非 RPC (over TCP) 服务 URL（OWA、ECP、EWS 等）的内部 IP 地址成为同一负载平衡器 VIP 时非常常见，但它们可能利用不同的活动检查完成适当的服务状态检测。

您的 DNS 为通配符响应提供服务吗？

我碰到过至少一位客户，他拥有一台外部 DNS 服务器，该服务器利用通配符记录来响应它收到的任何有关不存在的主机名的查询。这意味着您可以发送一条 DNS 请求来获取 SomeFunkyNameThatDoesNotExist.contoso.com，而 DNS 服务器始终返回其公司网站的 IP 地址。（通配符记录从 Internet 标准的角度看完全有效。请参阅 RFC 1034（该链接可能指向英文页面）中的第 4.3.3 节了解详情 -编者。）

正因如此，其 Outlook 无处不在客户端始终能够解析 CAS 数组对象 FQDN，并且会首先尝试 RPC (over TCP) 连接，然后再切换到 HTTPS。如果您发现自己处于类似的情况（即有一台外部 DNS 服务器，该服务器将通配符响应用于特定正向查找区域），那么我建议您尽量不要将该正向查找区域用于您的 Outlook 无处不在代理 URL。

顺便提醒一下，不要忘了为您的负载平衡解决方案配置适当的服务运行状况监视器。要获得最佳服务监视结果，请咨询您的负载平衡解决方案供应商。请查看 Exchange Server 2010 负载平衡器部署（该链接可能指向英文页面），以获得已经过 Exchange 2010 解决方案测试的负载平衡器提供商列表以及指向其相关网页（对于 Exchange 2010）的链接。注意，此列表*并非*受支持的负载平衡供应商的权威列表。它只是一个被挑选出来直接与 Microsoft 一道进行解决方案测试和支持的供应商列表。

一个粗陋的示例可能是：您的基于 HTTPS 服务的 FQDN 针对 TCP/443 响应执行活动测试，而负载平衡解决方案停止将新的客户端流量发送到在 TCP/443 上停止响应的任何客户端访问服务器。CAS 数组对象 RPC (over TCP) 服务 FQDN 可能在 TCP/135 上以及您为 RPC 客户端访问服务和通讯簿服务挑选的两个静态 TCP 端口（该链接可能指向英文页面）上针对 RPC 终结点映射程序执行活动测试。如果这三个端口中有任何一个停止响应特定的客户端访问服务器，则对于 RPC (over TCP)，负载平衡解决方案将不会把新的客户端流量发送到该 CAS，直到所有端口再次开始响应为止。如果您没有配置静态 TCP 端口，则 Exchange 会在启动阶段为每个服务选择一个动态 TCP 端口，这使得活动测试对于某些负载平衡解决方案虽说并非不可能，但也困难重重。

5. 创建 Exchange Server 2010 数据库后不应配置或更改 CAS 数组对象

很多时候，我们都赶着安装邮箱服务器，创建邮箱数据库，并且满心希望通过 Jetstress（该链接可能指向英文页面）开始存储解决方案验证测试。我能否建议您放慢点脚步，让自己今后少些麻烦？尽管邮箱服务器被许多人认为是最重要的服务器角色，但是如果前门被堵死了，它对于您并无益处，因为您无法通过客户端访问服务器进到那里。

如果您在 CAS 数组对象就绪之前就开始创建邮箱数据库，则您会在每个数据库的 RpcClientAccessServer 属性上所标记的同一 Active Directory 站点中看到一个随机客户端访问服务器。

不像它应该具有的样子（使用 CAS 数组对象的 FQDN）

图 1：如果创建了 CAS 数组对象，则用 CAS 数组对象的 FQDN 填充邮箱数据库的 RpcClientAccessServer 属性

它看起来会是下面这样：

图 2：如果未创建 CAS 数组对象，则用客户端访问服务器 FQDN 填充邮箱数据库的 RpcClientAccessServer 属性

客户端配置文件看起来会是下面这样…

图 3：如果未创建 CAS 数组对象，则使用客户端访问服务器的 fqdn 配置 Outlook 客户端

客户端将像下面这样连接...

图 4：客户端连接客户端访问服务器的 fqdn

乍一看，这样做似乎绝无大碍，一切都能正常工作，但您以后会碰到麻烦。如果您就地用此配置开始将邮箱移到 Exchange Server 2010，则 Outlook 会使用用户配置文件的“服务器”字段中的 CAS 名称。除非该客户端访问服务器变得不可用，或在以后某个时间被取消并被不同名的服务器所替换，否则这样做可行。在发生这种事情时，您还宁愿使用客户端访问服务器的负载平衡池吗？？是的，您会！

您可能在心里对自己说“嘿，自以为是的家伙，如果真有那么一天，我会创建一个 CAS 数组对象并修正数据库上的 RpcClientAccessServer，情况会很好。”我在这里告诉您，这只适合您事后移动到 Exchange 2010 的邮箱。任何用户，只要他们的预先存在的配置文件配置为指向 CAS 名称而非 CAS 数组对象，他们都将继续连接 CAS 名称，CAS 名称不会自我更新来利用 CAS 数组对象 FQDN。

配置文件不会自我更新，因为客户端不会收到来自 CAS 的 ecWrongServer 响应。它之所以不会收到此响应，是因为任何 CAS 通过 RPC (over TCP) 对于任何邮箱数据库都是一个有效连接点，所以客户端可以经受住数据中心切换/故障转移事件而不被重新配置，而管理员只需翻转 CAS 数组对象 DNS 记录以指向幸存的 CAS 池。目前，修复邮箱配置文件的唯一办法是在 Outlook 内手动修复配置文件，方法是通过 GPO 发布一个 Office PRF 文件（对非加入域的计算机不适用），或取消在用户配置文件中指定的 CAS 服务器以使终结点不再可用。这最后一个选择应（测试、测试、再测试！！）通过 Outlook 2007 或 Outlook 2010 中的自动发现触发完全的配置文件修复。只能通过配置文件修复或 PRF 文件修复 Outlook 2003。截至撰写本文时，自动发现将不会作为正常自动发现过程的一部分将配置文件更新为新的服务器名称。正常自动发现过程会更新 Outlook 无处不在配置并为其他功能（如 OOF 管理、忙/闲和收件箱规则管理）发现 EWS URL。

这也意味着，假如您将邮箱从 AD Site-A（使用名为 Boston-CASArray 的 CAS 数组对象）的数据库移动到 AD Site-B（使用名为 Redmond-CASArray 的 CAS 数组对象）的数据库，那么配置文件不会更新，服务器名称字段将保持为 Boston-CASArray FQDN。如果您有一个顺应工作变化而迁移到不同站点的用户群，或者您要在解决方案生命周期内的某个时间执行到另一个站点的大规模内部邮箱迁移，您可能需要记住这一点。如果您确实发现自己在创建 CAS 数组对象之前创建 Exchange 2010 数据库，则您有必要回过头来修复数据库的 RpcClientAccessServer 属性，以便在将邮箱移入数据库之前使用 CAS 数组对象。

6. 即使只有一个 CAS 或一台多角色服务器，也应配置 CAS 数组对象。

思考前面讨论的内容。如果您稍后添加了一个 CAS 数组对象，客户端不会更新自己来使用该对象。那么好，假如您只有一个 CAS 呢？您或许认为这无关紧要。我猜此时此刻有人会说没关系，但如果可以，为什么不为未来做好准备呢？这多少能省去未来的一些环节和麻烦。假如从现在起的一年中，您发现自己需要替换该 CAS，怎么办？假如您的客户端配置文件全都指向一个 CAS 名称，那么您无法干净利落地转换它们而不造成某种中断或进行手动操作。在添加一个新的 CAS 后，您将必须用已提到的手段之一修复其配置文件，或者必须取消现有 CAS 并引入新的具有相同主机名的 CAS，这将需要一些停机时间。就我而言，这些选项我都不能接受。

假如后来您的业务要求发生变化，并要求您应具备客户端访问高可用性，怎么办？您只有靠添加第二个 CAS 和负载平衡解决方案才能实现此目标。您会发现自己又陷入同样的困境，即必须通过已讨论的手段之一修复每个人的配置文件。同样，这些选项也是我不能接受的。

我的建议是您从一开始就创建一个 CAS 数组对象。如果您没有负载平衡器而只有一个 CAS 怎么办？很简单！像通常那样配置 CAS 数组对象。赋予它一个名字、一个 AD 站点和一个 FQDN，然后只将 DNS “A”记录指向该 IP 作为唯一现有的 CAS 或您当时具有的多角色服务器。您刚刚是让自己为未来做准备，假如您可能必须替换单个 CAS 或多角色服务器，您只需生成新服务器，然后更改 DNS 记录 IP 地址，这样一切都将平安无事。假如您可能需要在以后添加高可用性，您只需让您的负载平衡解决方案运行，然后更改 CAS 数组对象 DNS 记录 IP 地址以指向负载平衡解决方案的 VIP。太容易了！

希望这篇文章帮助您解决了对 CAS 数组对象的一些错误认识，并对诸位朝着健康的 Exchange Server 2010 迁移迈进亦有帮助。

Brian Day
高级现场工程师，消息处理

这是一篇本地化的博客文章。请访问 Demystifying the CAS Array Object - Part 2 以查看原文