场景：2台CAS,HUB,MBX合一的exchange2010服务器，DAG环境，要求实现CAS的冗余。
解决思路：
1、HAproxy或者NLB，或者硬件NLB。
2、前端建立CAS array， cas array与DAG是可以共存的（不建立NLB）
解释：
cas array的ip地址指向DAG群集的虚拟ip地址，就是说dag主节点在谁那儿，cas array就访问谁（可以查看两个服务器的网卡 有一块被配置了双IP）。
通过RpcClientAccessServer来关联CasArray与邮箱数据库。
这样实现了最小成本的高可用。而非负载均衡。
（注：微软不推荐此做法）
参考资料：
Uncovering the new RPC Client Access Service in Exchange 2010 (Part 1)CAS array对象解密 – 第 1 部分
操作：
1、建立CAS array，建立DAG，DAG的ip为10.0.0.250
2、所有邮箱的 RPCClientAccessServer指向cas.soda.com
3、AutoDiscover发现值也得改掉，改掉后记得重启exchange AD 拓扑服务使配置生效
也可以使用ADSI修改，如图：两个CN=servers下面CN=08server1与CN=08server2 都要改
4、重新申请证书，加入cas.soda.com域名（非必要，因为outlook使用RPC连接而非SSL保护的HTTP连接）。
5、我的测试环境需求通过mail.soda.com访问，以下附上IIS和DNS配置
6、测试访问，OWA与自动访问没有问题。
测试下高可用，在DAG上放一个数据库 Testmbx，用户soda和用户xuqi都放在里头，，可以看到目前08server1为test的主节点。
断掉08server1
DAG起作用了
接下来测试客户端访问，一切正常，而且自动发现节点也切换到了08server1上。
说明cas array的高可用也实现了。
以上就是cas array+dag，很多生产环境其实都在用这套方案，最低成本的冗余。
PS：一开始在azure上做这个实验，死活不通。后来检查出来是因为azure虚拟机不能配固定IP导致（参照前文，创建DAG ip地址时会直接配到网卡上）。后来换到本地的虚拟机才测试成功。
本文出自 “卡斯特梅的雨季” 博客，请务必保留此出处
我就想是一只草原中被牧童遗忘的羊，
