这时候可以确定问题不是exchange server本身造成的。。。。
既然不是exchange的问题，那唯独和exchange有联系的就是域控dc服务器了，可是从开始出问题就检查过AD站点的复制状况，并没有出现明显错误。
这时候想起曾经看到过国外一哥们类似问题，最后他向微软开启了一个case支持，微软用了3天15小时进行排查，最后竟然是通过修改ADSI编辑器中cas属性来解决的，整个好也是也OWA无法访问相关的。由于之前不能排除Exchange本身的问题，并且这问题很难让人和域控联系起来，因此一直没敢尝试。现在既然能确定问题和dc有关系了，那这个解决方案还是值得去尝试的。。。
具体操作如下：
1、 由于ADSI内容涉及到整个的活动目录内容，操作之前一定要做好备份，首先通过Windows Server Backup将整个dc做了一次完整备份，以备后患。（这里估计又要被鄙视了，偌大的一个公司竟然没有完善的备份系统，o(╯□╰)o）
2、 打开ADSI编辑器，连接到【配置】，然后找到【CN=Services】-->【CN=Microsoft Exchange】 -->【CN=<你的exchange组织名称>】-->【CN=Client Access】，然后右键点击选择【属性】，打开属性编辑器窗口，在【属性编辑器】选项卡中找到“msExchCanaryData”字样的属性值，然后清空（可能会有0-n多项）
这里我们将这几个值的内容再次复制到记事本中进行保存，这样可以起到备份双保险作用，慎重操作，毕竟是生产环境。
3、 打开CAS服务器的IIS管理器，点击【应用程序池】，找到【MSExchangeOWAAppPool】，然后点击右侧窗口的【回收】
4、 重启exchange服务器
待Exchange服务器重启完成后进行测试，海外用户OWA和ECP恢复正常，其他outlook功能也正常。北京总部用户也一切正常。问题终于解决！
最后问题是解决了，但导致的原因并没有真正找到，希望看到这篇文章并熟知exchange2013的小伙伴来一起讨论。。。。
关于Exchange2013，刚刚一年多的时间已经有 CU5的更新了，无奈让人感慨Exchange2013架构的改变让人耳目一新，同时也带来了N多问题，真心希望Exchange2013的命运不要像Exchange2007那样。。。( ╯□╰ )
解决过程中咨询了多个技术好友，由于Exchange2013是新产品并没有太普及，小伙伴们也都没有遇到过，在此感谢各位！同时感概自己无意中竟然成了先吃螃蟹的人。。。( ╯□╰ )，再者公司没有购买微软技术支持服务，最后想通过MVP通道向微软寻求技术支持，怎奈需要1个工作日的响应时间，最终也没有用上MVP的这点儿福利。。。( ╯□╰ )
