CAS Array 的概念是第一次在 Exchange 2010 中被引入，其主要目的是在于统一客户端访问名称，便于不管连接哪台服务器均能够使用同样一个名字访问，因此在不建立NLB的情况下使用CAS ARRAY能够统一访问名称。

实际的部署 CAS Array 的过程我就不说了，网上很多教程。这里要提出来的三点建议，也许对你的环境会有帮助。

CAS Array 的内外部 FQDN 不要用一样的，说更清楚点，内部 CAS Array 的 FQDN 不要能被外部 DNS 解析。

Why? 就算我内外FQDN一样，我也还是能正常访问 Exchange 啊。对，你确实还是能够访问，但是却增加了 Outlook 的连接时间，在某些慢速网络下，甚至会导致连接超时。我们下面详细来看看各种场景下的连接情况。

a)  内部 Outlook 用户 (TCP连接)。

  • Outlook会通过DNS去查询内部 FQDN 对应的 IP，比如说outlook.internal.local -> 192.168.1.30 (内网IP)。
  • Outlook 会认为自己在内网，于是尝试使用DCE/RPC 也就是135 端口去连接 192.168.1.30。
  • 连接建立。

b)  外部 Outlook 用户 （CAS Array内部FQDN可以从公网解析）

  • Outlook会通过DNS去查询内部 FQDN 对应的 IP，比如说outlook.internal.local -> 123.234.213.213 (公网IP)。
  • Outlook会认为自己在内网，于是尝试使用DCE/RPC 也就是135 端口去连接123.234.213.213。
  • 而大多数情况下，防火墙是不会允许公网的 135 端口通信的，所以得等待TCP连接超时，这其中还有几次重试的时间。
  • 当 Outlook 发现 TCP/135 的端口无法连接的时候，才发现，哦，原来我不在内网啊，那就只能尝试使用 https协议去连接 443 端口。
    默认情况下， 在快速网络环境下，Outlook 会使用 TCP 先行尝试连接，不成功的情况下才会使用 Http/Https ，这里TCP连接浪费的时间，短则10来秒，最长可达30秒钟以上，所以，Outlook Anywhere用户体验会变得糟糕。

当然，你可以改成无论何时都是先用http/https 连接，对于 Outlook Anywhere 用户，很适合，不过这会对内网用户造成困扰，甚至无法登陆，因为内外网证书很可能不一致，导致设定的 FQDN 名称和证书的 Common Name 不匹配，会总提示输入用户名和密码，即便你输入的是正确的，还是会不停地跳出来。

c)  外部 Outlook 用户 （CAS Array内部FQDN不能从公网解析）

  • Outlook会通过DNS去查询内部 FQDN 对应的 IP，但此时从 DNS 并不能返回查询结果。
  • Outlook 知悉，哦，地址无法解析，我在外网，于是直接使用 Https 去建立连接。

** CAS Array 的场景下，客户端最好能做 Kerberos **认证 （Exchange 2010 SP1）。

在 Exchange 2010 中，所有的域客户端的 MAPI 访问实际上都是通过 CAS 来走，而客户端的认证会使用协商认证，即negotiate authentication，也就是会先使用 Kerberos 认证。失败之后再尝试 NTLM 认证。（注：Outlook Anywhere 不适用）

而在配置了 CAS Array 的环境下，Kerberos 认证会失败的，因为 Kerberos 认证的时候，发起的service ticket中的authenticator 使用的是 CAS Array FQDN的 SPN，而不是 CAS Server 的 SPN，所以会认证失败。具体的实现步骤可以参考这里：http://blogs.technet.com/b/exchange/archive/2011/04/15/recommendation-enabling-kerberos-authentication-for-mapi-clients.aspx

那么，开启 Kerberos 认证有啥好处呢？除了可以满足一些企业的安全需求外，还能减少 CAS 服务器和 AD 的负载，这对大型企业中的性能优化很有帮助。

**即便你只有一个 CAS 服务器，也建议配置 CAS Array **。