2007年1月23日，CNNIC发布了《第19次中国互联网络发展状况统计报告》。报告显示，手机上网人数达到1700万，占网民数的12.4%。在众多手机上网的用户中，无疑电子邮件还是最常用最有价值的应用。作为全球市场份额第一的企业邮件系统，Microsoft Exchange提供了内置的ActiveSync移动邮件解决方案。该方案将使企业员工无论身在何处，只要使用支持ActiveSync的PDA, 智能手机，就能完全接收他们的Exchange Server 2003信息，其中包括电子邮件、工作日程及其它联系信息。所有使用Microsoft操作系统的手持设备都内置了ActiveSync的客户端。此外，索尼－爱立信，DataViz、摩托罗拉、诺基亚、Palm和Symbian 等也从Microsoft获得了协议的授权。几乎可以说，用户能在任何常见的智能手持设备上使用ActiveSync和Exchange服务器同步。所以，现在使用智能手机同步企业邮件再也不是少数人的专利了。它已经融入众多公司的业务流程中，成为企业邮件信息系统中的一个重要组成部分。
如果说IT是一个企业的神经系统，那么邮件系统一定是最复杂(与目录服务，网络，存储，操作系统紧密相关)，涉及面最广（上至CEO下至普通员工），最敏感（一有问题全民皆知）的那一根神经。而Exchange ActiveSync就是这根神经的末梢之一，它内连众多VIP用户，外接Internet，和移动网络隔空相望。纤细而悠长的末梢，需要系统管理员的细心呵护，否则就要触痛用户。本文作者多年工作在相关产品的技术支持第一线，愿意与诸位分享在解决ActiveSync相关问题的经验和心得，帮助快速定位，分析，解决问题。
原理
解决IT系统的问题有时候就像是医生治病。医生能够运用望，闻，问，切治病疗伤，一定需要深刻了解人体生理。否则不是误打误撞，就是庸医害人。对架构原理的理解，可以帮助我们对系统有一个整体的把握，了解数据是如何在设备和Exchange服务器之间的交换，知道需要涉及依赖的组件，预知可能的潜在薄弱环节。有了这些知识，我们才可能作到对症下药，药到病除，妙手回春。在介绍各种典型问题之前，下面就先对Exchange ActiveSync的架构作一个介绍。
理想的拓扑结构
下图就是一个Exchange ActiveSync的理想的拓扑结构。说它是“理想”，是因为在实际部署时候，由于种种原因（经费预算紧张，和老系统的兼容），可能会有所差别。比如，小企业可能没有单独的前端服务器（Front End Server），或者没有专用的ISA服务器。但是这些都不影响我们对总体结构的介绍。
图 1理想的网络拓扑
上图中，手持设备（PDA，SmartPhone）通过各种网络（GPRS/EDGE,CDMA, WiFi）必须能够和ISA 服务器建立TCP连接。ISA服务器必须能够将网络包中继到Exchange前端服务器。前端服务器通过查询目录服务器（Global Catalog Server）定位用户的邮箱服务器（Back End Server）后，和用户的邮箱服务器建立连接。从上图，我们可能得到几个关机点：
• 不管是通过ISA 发布还是其他的办法，Exchange前端服务器必须是从Internet可以访问到的（除非只使用PDA通过Intranet访问）。
• 前端服务器必须能够访问GC （Global Catalog Server）定位到邮箱服务器。所以必须保证有一个健康的目录访问。
• 前端服务器到邮箱服务器的网络必须畅通。
• 前端服务器对GC，或者邮箱服务器的访问，都是必须验证的。验证涉及到KERBEROS，DNS等。所以也必须保证这些协议在前端上正常。
以上介绍还只是停留在网络连接层面，但是已经可以帮助我们对一些简单的问题作出诊断。举一个例子，有用户通过PDA的WiFi可以访问LAN，并通过Exchange ActiveSync同步邮件，但是智能手机用户无法通过GPRS同步邮件。知道了上面的拓扑结构，我们应该知道这根问题很可能就是ISA发布环节出现了问题。这是比较简单的一个问题，我们现在对Exchange ActiveSync的内部机制作一个介绍，以帮助对一些复杂的问题作出正确的判断。
内部机制以及访问协议
到了这一步，具体的网络连接已经不再是关注的焦点，连接已经抽象为就是一双向的TCP连接。我们关心的是TCP之上的应用层协议已经处理这些协议的组件。
图 2 内部原理
我们采用从客户端到服务器顺序依次介绍图2涉及的通讯协议以及不同的组件。假设一智能手机用户开始了一个同步操作，
1. 手机和Exchange前端服务器建立TCP连接（ISA服务器可以认为是透明的）。使用TCP连接，手机终端必须和Exchange前端服务器能够使用HTTPS互相传递数据。这个过程看似简单，其实很多问题往往是由于这一步失败引起的。这一步要成功，需要满足很多条件：
a. Exchange前端服务器上的IIS必须配置了SSL。细节这里不赘述，可以参考IIS的帮助。使用SSL就必须有证书（Certificate）。这个证书可以从一些商业结构申请，也可以从公司内部的CA服务器申请。
b. 证书上有服务器的名字（Common Name），这个名字必须和手机中输入的服务器FQDN完全相同。举个不是完全恰当的例子：每张身份证上都有照片，这个照片如果和持证人的长相不符，我们当然有理由怀疑身份证不是本人的。同理，手机也必须确认前端服务器用于HTTPS的证书就是这个服务器的，它通过比较证书上的名字和用于访问这个服务器的FQDN（这里假设Internet上DNS是可以信赖的）完成这种检查。所以在为前端服务器申请证书的时候，请仔细思考你打算让用户使用哪个名字访问。假设你的Exchange前端服务器的内部名字是MAIL100。Internal.yourcompany.com, 你准备让用户使用mail.yourcompany.com访问前端（当然你必须注册了yourcompany.com这个域名），那在申请证书的时候，服务器的名字必须是mail.yourcompany.com。
c. 每张证书都有一个发证者，这个发证者的上面可能还有一个或者多个发证者。要让手机相信证书是从一个可靠机构发出的，那个最原始的发证者必须是值得信赖的。如果你是从一些商业的发证机构获得的证书，那不要担心，这些机构的证书通常都已经在可信赖的证书列表中。如果是你内部的CA发行的证书，那么内部CA的证书必须导入到手机的可信赖证书中。步骤这里不赘述，需要强调的是很多用户往往会疏漏这一点。
2. 手机终端通过HTTPS协议发送请求到Exchange前端服务器上的虚拟目录/Microsoft-Server-ActiveSync。在处理这些请求之前，IIS会帮助完成身份验证。
3. 身份验证完成后，处理请求的组件 MASSYNC.DLL (这是一个ISAPI Extension, 如果对这个名字不熟悉，你可以把它当作和ASP类似但是更高效的一个Web编程接口)需要查询活动目录获取这个用户的属性，比如他或者她是否启用了ActiveSync, 用户的邮箱服务器位置等。
4. MASSYNC.DLL从AD中获取了用户的属性后，使用WebDAV协议访问用户的邮箱服务器。这一步非常复杂，需要进一步说明：
a. WebDAV是一种HTTP基础上应用协议。传统的HTTP协议可以使用“GET”命令从Web服务器上下载一个网页，或者“POST”命令提交一个表单或者上传一个文件。WebDAV增加了一些新的命令，比如“SEARCH”可以查找符合条件的对象，命令“PROPFIND”获取一个对象的属性等。Exchange提供WebDAV接口的目的在于可以使用HTTP查找邮件，访问邮件的属性（主题，收发时间，收发件人，正文等），删除邮件和发送邮件。
b. 默认情况下，MASSYNC.DLL总是通过访问邮箱服务器上的虚拟目录“/Exchange“访问用户邮箱。这个访问是HTTP而不是HTTPS。如果用户不清楚这一点，可能会导致问题。比如在后端上只是配置了HTTPS，或者/Exchange目录不存在等等，这些都会导致ActiveSync不能工作。
c. 后端服务器上的/Exchange也是需要验证的。这就带来一个配置上的要求。前端服务器上的/Microsoft-Server-ActiveSync必须使用“BASIC”验证方式，而后端上的/Exchange必须是Windows集成验证，否则前端到后端的验证是无法完成的。一个常见的配置错误是，前端服务器的/Microsoft-Server-ActiveSync同时允许“BASIC”和Windows集成两种方式的验证。在这种情况下，客户端通常优先使用Windows集成验证。这样，和后端的验证就无法完成，导致邮件同步失败。
5. MASSYNC.DLL将从Exchange服务器获取的数据打包后返回给手机。
以上5个步骤每一步都有很多复杂的细节没有交代。比如第一步中，手机发送请求使用的其实是AirSync协议。这是一个基于HTTP和XML的Microsoft专有的协议，所有支持ActiveSync的第三方软件必须从Microsoft申请使用许可。在第4步中，WebDAV是如何用于邮件同步我们也没有说明。但是和常见问题相关的技术要点我们都已经涉及到。限于篇幅，有很多细节无法在此一一展开，有兴趣的读者可以参考附录中的链接。
常见问题的分析和解决
我们对Exchange ActiveSync的常见网络拓扑，内部工作原理已经作了一定的介绍，现在我们可以开始分析一些典型案例。在开始之前，对一些常用工具和解决思路先作一个说明。
常用工具和解决思路
第一个最容易使用和最有用的工具是IE浏览器。毕竟无论是终端和前端服务器之间的AirSync还是前后端之间的WebDAV都是HTTP之上的应用协议。用浏览器可以测试网络是否连接，HTTPS是否配置正确。第二个工具是前后端服务器上的WWW的日志。原因和第一个相似。参看日志的优势在于可以准确判断从终端发出的请求是否已经到达了服务器，还是已经被中间的网络设备丢弃。第三个工具是网络抓欧包工具，最典型的是Microsoft Network 2.0或者3.0。通过在不同的服务器上抓包，可以对网络连通情况，客户端请求和服务器端响应作出最精确的判断。
对于所有用户报告的Exchange ActiveSync相关的问题，我们都需要对下面的问题作出判断：
• 首先需要确认的是，用户是否可以使用Microsoft Outlook或者Outlook Web Access（OWA）访问邮箱。如果答案是否定的，请不要继续在ActiveSync上作文章了，需要先解决Outlook或者OWA的问题。他们的问题解决了，ActiveSync可能就不在是问题了。
• 其次需要确认ActiveSync以前是否能够正常工作。如果从来就不曾正常，必须仔细检查部署的文档，需要从后端服务器往设备一级一级检查配置。
• 接下来需要确认这是个别用户的问题还是普遍问题。如果是大量用户存在问题，问题出在服务器端或者靠近服务器端的可能性毕竟大。个别用户的问题也需要确认是和这个用户的邮箱有关还是和使用的设备相关。
如果我们把图1中的各个设备和网络连接抽象成节点和边，就是一个很简单的图，如图3所示。需要作的就是利用介绍的工具二分法定位问题，再利用图2介绍的原理解决问题。
图 3 抽象节点
下面我们将根据经验，对常见问题归类，一一介绍。
单服务器常见问题
我们在前面已经说明，ActiveSync的服务器端的组件是MASSYNC.DLL，它是通过使用WebDAV访问后端的虚拟目录/EXCHANGE的。对于单服务器而言，常犯的一个错误是MASSYNC.DLL无法访问/EXCHANGE目录。通常我们在手机上会看到错误代码HTTP_403。这可能是因为：
• 用户在/Exchange上启用了基于表单的验证（FBA）。MASSYNC.DLL只会通过Windows集成验证访问/Exchange，无法通过基于表单的验证。
• 用户启用了SSL，并强制所有的访问必须是SSL。但是MASSYNC.DLL只能使用HTTP而不是HTTPS访问/Exchange。
• 用户创建了新的虚拟目录，删除了默认的/Exchange虚拟目录。默认条件下，ActiveSync假定Exchange的虚拟目录一定是/Exchange。
我们只要查看一下服务器上IIS的配置就可以确认问题。或者可以使用IE使用HTTP访问/Exchange。如果是只允许使用HTTPS访问，IE会显示一个错误页面提醒必须使用HTTPS访问。如果启用了FBA，IE会显示一个页面提醒输入用户名和密码而不是弹出一个用户名和密码的对话框。如果用户删除了/Exchange，IE应该显示页面找不到错误。
前后端常见问题
如果前后端配置的Exchange ActiveSync出现了问题，首先需要先确认后端的OWA是正常工作的，并且可以使用IE从前端访问http:///exchange。如果这一步就出现了问题，那需要先解决的是后端的OWA的问题。这个在OWA正常工作的情况下，最常见的问题就是验证的问题。我们在前面曾提到，前端的/Microsoft-Server-ActiveSync一定是只有”BASIC”验证，而后端的/Exchange一定要有Windows集成验证。验证方法配置错误是一个很常见的问题，手机等终端在遇到这类问题时候，错误代码是HTTP_500 。下面的截屏再次提醒一下正确的配置。 图 4 前端/Microsoft-Server-ActiveSync验证方法
图 5后端/Exchange的验证方式
除了配置错误外，其他常见的问题还包括KERBEROS验证的问题。前端到后端再次验证的时候，如果前后端直接系统时钟差异过大（比如大于五秒），验证就会出现问题。这类问题反映在OWA中是IE反复提示用户输入用户名和密码。在ActiveSync中就是一个笼统的HTTP_500错误。这类问题的最好办法是测试一下OWA的访问。如果OWA没有在这个前端上启用，需要在前端上收集网络包，判断KERBEROS的通讯是否正常。关于KERBEROS的更多信息，请参考附录提供的连接。
设备端配置问题
这是最常见的一类问题，通常出现在部署阶段，或者部署后个别用户遇到各种问题。
网络传输问题
结论
本文介绍了Exchange ActiveSync的工作原理，列举了几种常见的问题。希望通过这篇文章，帮助Exchange管理员在Exchange ActiveSync规划，实施，维护的不同解决快速地解决各类问题，知其然而且知其所以然。
附录
1. WebDAV协议
RFC 2518
Exchange 2003 WebDAV
2. 客户端错误代码
