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

原文发布于 2012 年 3 月 24 日（星期六）

自 2009 年 Exchange 2010 发布后，人们对它如此着迷，简直难以想象。在同客户打交道，为他们提供培训以让其准备迁移到 Exchange 2010 时，我们发现存在一些常见的错误认识。因此，有必要澄清对客户端访问服务器数组对象（简称 CAS 数组对象）的错误认识。技术作家和多产博主 Scott Schnoll（该链接可能指向英文页面）建议我在内部 Microsoft 通讯组上评论这一必要性时用笔写下来… 哦，不对…是用键盘写下来（？），于是便有了这篇文章。

在这篇文章中，我不打算讨论 CAS 数组对象的所有技术方面。Nagesh Magadev 已经在之前的文章：探索 Exchange 2010 RPC 客户端访问服务（该链接可能指向英文页面）中进行了精彩的论述。

提到我将要尝试解密的 CAS 数组对象，下面是我收集的一些事实列表，许多客户或许还未意识到这些事实。第 1 部分将讨论前三条，第 2 部分则讨论后三条。

1. CAS 数组对象不对您的流量进行负载平衡
2. CAS 数组对象不向自动发现、OWA、ECP、EWS、IMAP、POP 或 SMTP 提供服务
3. CAS 数组对象的 FQDN 不需要作为您的 SSL 证书的一部分
4. CAS 数组对象不应通过 DNS 由外部客户端解析
5. 创建 Exchange 2010 邮箱数据库并将邮箱移入数据库后不应配置或更改 CAS 数组对象
6. 即使只有一个 CAS 或一个多角色服务器，也应配置 CAS 数组对象。

是不是很纠结？那好，让我们改进一下方式，一次最好只谈其中一条。您会看到一些服务器名称贯穿本文，那么，我为什么不先来展示一下我正在实验室中从事的工作呢？

名称	ServerRole	AdminDisplayVersion
E2K10-MLT-01	Mailbox、ClientAccess、HubTransport	版本 14.2（内部版 247.5）
E2K10-MLT-02	Mailbox、ClientAccess、HubTransport	版本 14.2（内部版 247.5）
E2K7-MLT-02	Mailbox、ClientAccess、HubTransport	版本 8.3（内部版 83.6）
E2003-BE	无	版本 6.5（内部版 7638.2：Service Pack 2）

好，现在我们来深入探讨一下！

1. CAS 数组对象不对您的流量进行负载平衡

CAS 数组对象不执行负载平衡。它是一个 Active Directory 对象，用来在 Exchange 内自动执行某些功能，仅此而已。Exchange 2010 文档总是建议用负载平衡器 (LB) 负载平衡 CAS 流量。那么我说的 CAS 数组对象不执行负载平衡又是什么意思呢？

使用负载平衡器实际是平衡跨 CAS 池（也可称之为 CAS 数组）的流量，并非 CAS 数组对象本身。其中的差异微妙而又明显；或许是因为我们取的名字不够独特，无助于防止最初产生的混乱。

主要原因，也可能是唯一原因在于，CAS 数组对象的存在是为了自动填充在同一 Active Directory 站点（与 CAS 数组对象相同的站点）中创建的任何新 Exchange 2010 邮箱数据库的 RpcClientAccessServer 属性。

RpcClientAccessServer 属性用来在配置文件创建过程中告知 Outlook 客户端在配置文件中应使用什么服务器名称。它的作用基本如此，再没什么神奇功能了，而且您一旦创建了您的 CAS 数组对象，它只不过是 Active Directory 中的一个对象罢了，在这个时候没有负载平衡发生。

然后，剩下的事就靠您了。您需要：

• 在 DNS 中创建一条“A”记录，这将允许客户端计算机将主机名解析为 IP 地址。此 IP 地址很可能是只有内部客户端才能访问的 LB 的虚拟 IP (VIP)。此 VIP 是 Outlook 或任何其他支持 MAPI/RPC 的应用程序将随后连接以获得对 Exchange 2010 邮箱资源访问权限的目标。
• 通过 VIP 配置您的负载平衡解决方案以将流量传递给 CAS 服务器池。

CAS 自身不知道有任何负载平衡发生。

您可能还对使用 New-ClientAccessArray cmdlet 创建 CAS 数组对象或使用 Get-ClientAccessArray cmdlet 查看预先存在的 CAS 数组对象后可以看到什么存在疑惑。

在这里，我正在我的实验室中创建一个新的 CA 数组对象，名称为 CASArray-A，FQDN 为 outlook.lab.local，并在 Active Directory 站点中很恰当地命名为 Site-A。

图 1：创建一个客户端访问数组

首先，我的 FQDN 和名称字段不匹配，因为“名称”是显示名称，纯粹是做做样子。您想怎么命名都可以，只要您知道该 CA 数组对象将来的用途即可。FQDN 是随后您必须在 DNS 中创建的记录，否则其他客户端将永远无法将它解析为一个 IP 地址并与之连接。在这一点上，我会提醒您，每个 Active Directory 站点只能有一个 CAS 数组对象。

那么，为什么在创建后，立即用两个 CAS 填充 Members 属性呢？我不是说过在这时候没有负载平衡发生吗？是不是我在说谎？

老实讲，Members 属性有点误导人。假如您没有读到创建 CAS 数组对象的步骤，您可能认为您已完成此阶段了。您创建了您的 CAS 数组对象，您可以看到两个 CAS 已自动加入到数组中。到此您或许可以停下来开个庆功会，或是跑到魔方镇 (cube-town) 走廊上从这位老兄（该链接可能指向英文页面）那里偷几块饼干 (cookie)。事情还没完呢，我的朋友 ！

鉴于我们将该 CAS 数组对象关联到 Active Directory 站点 Site-A 这一事实，cmdlet 只去查找注册为在 Site-A 中驻留的所有客户端访问服务器，然后在成员列中列出它们。我想告诉客户将此列看作是潜在成员列，或者如我的同事 Kamal Abburi（Microsoft 在这里的另一位 PFE）建议的那样，就作为站点 CAS 成员列。您可以将这些客户端访问服务器添加为您的负载平衡解决方案中的节点，因为它们全都驻留在同一 Active Directory 站点中。但是，在完成负载平衡器配置前，我们没有负载平衡。

Cmdlet 怎么知道 CAS 在哪个站点中？好，很高兴您问这个问题，因为我们就要开始谈到各位最好的朋友 AdsiEdit.msc 并一直深入到 Active Directory 的配置分区来寻找魔法豆。

图 2：Exchange 2010 服务器的 MsExchServerSite 属性中包含服务器所在的 Active Directory 站点

每台 Exchange 服务器都有一个 msExchServerSite 属性，该属性包含它们当前所在的 Active Directory 站点。如果您想知道，那么我告诉您，的确，当您将 Exchange 服务器移到一个新站点时，它会动态更新，而 Microsoft Exchange Active Directory Topology 服务将有机会运行并更新一些东西。但是，AutoDiscoverSiteScope 属性（Get/Set-ClientAccessServer 的一部分）不会动态更新，您可能得到奇怪的自动发现结果，直到此问题被修复，这取决于您的站点、服务器和客户端的布局。

2. CAS 数组对象不向 OWA、ECP、EWS、自动发现、IMAP、SMTP 或 POP 提供服务

让我们回头再看看 CAS 数组对象到底能做什么。它填充 Exchange 2010 邮箱数据库的 RpcClientAccessServer 属性，后者随后用来告诉 Outlook 当使用 RPC (over TCP) 时它需要连接到哪里。对于 Outlook 无处不在 (HTTPS) 客户端，它指示离开 RPC-over-HTTP 代理的流量需要连到哪里才能代表客户端访问它们的邮箱。

那么，当使用 RPC (over TCP) 时，Outlook 客户端会尝试连接到什么服务呢？

首先，Outlook 在 TCP/135 上连接 CAS 数组对象并与 RPC 终结点映射程序通信，以发现下面两个服务正在侦听的 TCP 端口。

1. Microsoft Exchange RPC 客户端访问（亦称 MSExchangeRPC）
2. Microsoft Exchange 通讯簿（亦称 MSExchangeAB）

RPC (over TCP) 模式到此为止！

Outlook 无处不在（亦称 RPC over HTTP）客户端通过解析 Outlook 无处不在外部主机名或 Outlook 配置文件称代理服务器的名称在 CAS 的 TCP/443 上连接 RPC-over-HTTP 代理组件。

这里给所有感兴趣的人员插一条有意思的边注：Outlook 魔术般地、不动声色地将 /rpc/rpcproxy.dll 添加到指定服务器名称中，因为那才是它真正需要连接的目标，但是，假如我们要求用户键入这些名称，就像我们过去在 Outlook 2003 中那样，您能想象有多少人会漏掉它，或者把它搞错吗？

图 3：在 Outlook 2003 中指定 RPC 代理 URL

流量使用硬编码列表而非动态分配的 TCP 端口（它们是 TCP 6001、TCP 6002 和 TCP 6004），在 RPC-over-HTTP 代理之外路由到适当的 MAPI RPC 终结点。Outlook 无处不在外部主机名有意不与 CAS 数组对象的 FQDN 相同，稍后我会解释这是为什么。

客户端也可与服务（如自动发现、OAB 下载、EWS、POP 或 IMAP）建立 HTTPS 连接，但这些服务由完全不同的方法（如虚拟目录 URL 或 AutoDiscoverServiceInternalUri 值）定义。CAS 数组对象不向所有这些附加服务提供服务，因为它们都没有使用 RPC，尽管它们可能都在连接同一服务器。CAS 数组对象的 FQDN 可以与其他服务的 URL 共享同一 VIP，但是我们强烈建议，如果正在使用拆分 DNS，则不要让 CAS 数组对象的 FQDN 与其他服务的 URL 相同。关于这最后一条建议，我会在稍后部分详细讨论。

3. CAS 数组对象的 FQDN 不需要作为您的 SSL 证书名称列表的一部分

这是一个非常常见的误解，通常是由上面一条直接导致的。当我们需要做些事情，如建立 SSL 保护的 HTTP 会话时，才会利用这篇文章中所说的 SSL 证书。因为 RPC (over TCP) 不是 HTTP 会话，所以不会用 SSL 来保护它，进而，我们不需要将 CAS 数组对象的 FQDN 包括在 SSL 证书的主题名称列表中。我们来看一看。

下面是 Outlook 2010 以 MAPI/RPC 模式连接到 Exchange 2010 CAS 数组对象。

图 4：Outlook 2010 RPC (over TCP) 与 Exchange 2010 CAS 的连接

我们可以看到它已建立一个目录连接和两个邮件连接。在 netstat 输出中（覆盖在屏幕截图上），我们看到计算机与 CAS 数组对象建立了一个终结点映射程序连接 (TCP 135) 以及与 TCP 59531 和 TCP 59532 TCP（在此实验室中分别代表为 MSExchangRPC 和 MSExchangeAB 服务静态分配的 TCP 端口）建立了连接。

从服务器端我们可以看到使用命令 netstat –n –b 侦听的服务。

图 5：使用 RPC (over TCP) 时 Outlook 需要连接的服务

不出所料，它显示没有在 HTTP（到 TCP 443）上访问任何服务。这便是 SSL 证书上为什么不需要 CAS 数组对象 FQDN 的原因。

了解了 Outlook 在 HTTPS 模式下（如下所示）显示连接的方式，再来想 SSL 证书上需要 CAS 数组 FQDN 的事，这会让您有时感到困惑。

图 6：Outlook 无处不在连接

这一次，我们从截图中可以看到，Outlook 2010 建立了两个邮件连接和一个公用文件夹连接，我们还可以看到，我们在使用 HTTPS。从 Outlook 内看，好像我们连接上了 outlook.lab.local 和 E2K10-MLT-01.lab.local，但是再利用一次 netstat，我们会发现，其实我们是在 TCP/443 (HTTPS) 上连接位于 webmail.lab.local 的 RPC-over-HTTP 代理。Outlook 始终会自己显示或通过 RPC-over-HTTP 代理显示为获取数据而最终连接的服务器。如果您想知道为什么我们通过 netstat 看到 6 个连接而非 3 个连接，这是因为 HTTP 是半双工协议，我们因此为在 Outlook 内看到的每个连接建立一个 RPC_DATA_IN 和 RPC_DATA_OUT 通道。

您可能还会说，“等等！Outlook 2007 和 2010 默认会加密 RPC 会话！证书上必须有名称！”错了，我的朋友，您在下面看到的加密设置利用的是 RPC 加密，与 SSL 无关。通信仍发生在 RPC 上而非 HTTPS 上。

图 7：使用 RPC (over TCP) 连接时 Outlook 使用 RPC 加密

很简单，不是吗？假如一个 CAS 数组对象符合证书颁发机构 (CA) 的要求，并且 CA 说：“嗨，伙计，您真的需要我！拜托我以便宜价格卖给您豪华通配型证书！”，那么，CA 数组对象只要答复“亲爱的唠叨鬼，别介意！”并可能使用 CA 打开一个开心果。现在，如果您按照我们的建议将不同于其他服务的 FQDN 的 FQDN 用于 CAS 数组对象，那是理所当然的。好，我就来谈谈为什么...

我希望到目前为止，这篇文章的第 1 部分已帮助您理解对 CAS 数组对象的一些常见误解，并希望您会继续阅读我们的第 2 部分，在这一部分中，我们将讨论有关 CAS 数组对象的其余三个常见误解。

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

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