at Microsoft.Exchange.Clients.Common.Canary15..ctor(String logonUniqueKey) at Microsoft.Exchange.Clients.Common.Canary15Cookie.TryCreateFromHttpCookie(HttpCookie cookie, String logonUniqueKey, Canary15Profile profile) at Microsoft.Exchange.Clients.Common.Canary15Cookie.TryCreateFromHttpContext(HttpContext httpContext, String logOnUniqueKey, Canary15Profile profile) at Microsoft.Exchange.Clients.Owa2.Server.Core.OwaRequestHandler.InternalOnPostAuthorizeRequest(Object sender) at Microsoft.Exchange.Clients.Owa2.Server.Core.OwaRequestHandler.OnPostAuthorizeRequest(Object sender, EventArgs e) at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
这个过程显示的大概是exchange的前端cas和后端mailbox之间创建连接请求的过程。这时大家可能想到的是前端CAS和后端Mailbox的网络通信是否存在问题?
由于目前cas和mailbox是两台all in one角色(有dag),cas和mailbox通信基本是发生在同一台服务器上,且网络没有做过任何调整,网络问题基本也可以排除了。
接下来能想到的无非就是OWA虚拟目录或许出问题了,动手重置OWA虚拟目录后,问题依旧。。。最后终极杀手锏找了一台服务器重新安装一台exchange2013,不做任何更改直接创建用户和数据库,然后在exchange本机尝试访问owa,竟然出现同样的问题,无语了。。。
这时候可以确定问题不是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多项)
这里我们将这几个值的内容再次复制到记事本中进行保存,这样可以起到备份双保险作用,慎重操作,毕竟是生产环境。