深入剖析 SharePoint消息传递集成故障排除

Pav Cherny

代码下载位置：SharePoint2008_08.exe(416 KB)

内容

常见故障排除方法
SharePoint 消息传递体系结构
获取诊断信息
出站邮件传输
入站邮件传输
目录管理
结束语

在一个设计良好的 SharePoint 环境中，信息工作者无需改变各自的通信习惯或工作日程安排即可进行协作。他们不必不断地手动检查协作站点，SharePoint 可以将文档和其他信息（如警告和提醒）直接发送到他们的邮箱中。

而用户则可以通过回复这些邮件或将新项目以电子邮件的形式发送到文档库和列表来参与工作流。

但是，将 SharePoint® 集成到一个安全的消息传递环境需要面临诸多挑战，而且有可能会使非 SharePoint 组件对基于 SharePoint 的协作产生影响。当集成环境中出现问题时如何有效地隔离问题并消除导致这些问题的根本原因是一个难题。

在本专栏中，我将基于公认可以最快给出结果的故障排除策略来介绍 SharePoint 的消息传递集成。具体思路是首先迅速找到问题点，然后执行详细且有针对性的故障排除步骤。

在大型组织中，这一阶段式调查可能意味着在经过初始分析后需要将问题移交给其他专家，尤其是当该问题与非 SharePoint 组件相关时。但对于中小型组织而言，往往会要求 IT 管理员必须能够马上独立地排除所有相关系统的故障，这时尤其需要用到结构化的方法。

为使本专栏真正做到实用，我特意构建了一个测试环境，其中包括 Active Directory®、Exchange Server 2007 和 WSS 3.0。在随附的材料中，包括了构建此测试环境的分步说明以及本专栏中介绍的故障排除工具（可从《TechNet 杂志》**网站的“代码下载”中获取此材料）。

常见故障排除方法

也许与其他各种互操作性情况相比，对 SharePoint 消息传递集成进行故障排除更需要高度结构化的方法。有多种因素都会使此工作变得复杂异常。

很显然，您必须应对各种复杂的技术，而且当您在为邮件传输问题、邮件格式转换、安全性问题以及目录管理问题绞尽脑汁的时候，一些让人困惑不解的 SharePoint 错误消息可能也会接踵而来。在 Internet 新闻组中，到处都充斥着尚未得到解决的讨论话题和建议，很容易就会将您引入歧途 — 例如告诉您使用 SharePoint 管理中心的应用程序池标识来运行所有 Web 应用程序可以使消息传递集成能正常运行。

当然它也有许多长处。SharePoint 非常灵活。实际上，如果知道具体位置，它可以为您提供详细的故障排除信息。利用一些基本的脚本，您可以显著提高故障排除效率。

要故障排除，首先需要了解您要处理的特定问题。您需要确定问题的位置以及涉及的组件。有时可能还需要使用各种不同的系统配置来重现问题并研究 Windows® 事件日志和基于文本的日志文件。但这一点可能会比较棘手，因为有些问题只是偶发事件。当然，问题再现得越准确，您就可以越迅速地确定问题的根本原因并加以消除。另一个经常被忽略的重要目标就是记录所有配置更改和问题修复，并确保将其应用到环境中的所有相关系统（如 Web 场中的所有前端服务器）。

SharePoint 消息传递体系结构

无论何时遇到与消息传递集成有关的问题，在开始进行故障排除前，最好先喝杯咖啡或泡杯香茶，然后再着手查看 SharePoint 消息传递集成体系结构。否则可能到头来修复的是错误的问题或组件。例如，正如稍后您将看到的，当出现“拒绝访问”错误导致无法在 Active Directory 中创建联系人对象时，并不一定表示需要在 Active Directory 中修复访问权限。

在任何情况下，了解消息传递集成中每个组件的角色以及各组件彼此交互的方式都非常重要。在图 1 中，您会看到 SharePoint-Exchange 连接方案（在后续章节将对此进行详细介绍）中的一些重要组件。

图 1 SharePoint 消息传递集成体系结构（单击此图像可查看大图）

获取诊断信息

其中一个最重要的故障排除工具就是可靠的诊断信息。最为经典的是 Windows 事件日志。除此之外，您还可以使用 SharePoint 管理中心来控制 SharePoint 在向 Web 服务器写入 Windows 事件日志时采用的详细级别，方法是在 Operations（操作）页面的 Logging and Reporting（日志记录和报告）下，单击 Diagnostic Logging（诊断日志记录）。您可以指定向事件日志和跟踪日志报告的最低级别事件。如果需要较低级别的信息，跟踪日志（默认情况下位于 %CommonProgramFiles%\Microsoft Shared\Web Ser­ver Extensions\12\Logs 下）是一个不错的选择，但它的填充速度非常快，因此使用此功能要谨慎。

另一种获取诊断信息的方法是通过配置相应的 web.config 文件来启用受影响的 Web 应用程序的调试工作，如随附材料中的 Web Application Config.pdf 所述。SharePoint 可以直接在用户界面中显示详细的跟踪信息。此方法的好处是不必分析数以兆计的跟踪数据就可以看到相关的错误信息。但缺点是必须要更改 Web 应用程序的系统配置。故障排除完毕后，请不要忘记备份原始的 web.config 文件，备份完之后再恢复原始配置。

也可以对 SMTP 服务进行配置以将详细的处理信息写入到 SMTP 协议日志中，方法是在 IIS 管理器中，选中 General（常规）选项卡上的 Enable logging（启用日志记录）复选框。确保如随附材料中的 SharePoint Messaging Integration.pdf 所述来安装 ODBC 日志记录模块和 SMTP 服务功能（即使并不打算使用 ODBC 日志记录）。否则，SMTP 服务不会写入到协议日志中。默认情况下，SMTP 协议日志位于 %SystemRoot%\System32\LogFiles\SmtpSvc1 下。它是一个文本文件，可用来详细分析 SMTP 通信并确定邮件是否已离开 SharePoint 服务器。

在与 SMTP 服务通信的集线器传输服务器上，您也可以在“发送连接器”和“接收连接器”配置中启用协议日志记录（请参阅 SharePoint Messaging Integration.pdf）。您可以使用多种其他工具（如“邮件跟踪”、“队列查看器”和“管道跟踪”等）来跟踪 Exchange Server 2007 环境中邮件在集线器传输服务器和邮箱服务器之间经过的路径。如需有关 Exchange Server 2007 邮件流问题故障排除的详细信息，请参阅主题“传输和邮件流问题”，网址为 go.microsoft.com/fwlink/?LinkID=120145。

在 Active Directory 域控制器中，您可以通过启用“目录访问”的诊断日志记录来收集详细的故障排除信息，以及通过在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics 下设置相应的注册表项来收集其他种类的信息。如果种类的值为 0x0，则意味着仅记录关键事件；而值 0x5 表示记录所有事件，包括调试信息。如果日志记录级别大于 0x3，则可能会使服务器性能降级，还可能会使 Windows 事件日志填充速度过快。在常规操作过程中，所有值都应设为 0x0。

在进行故障排除时收集有关 SharePoint、Exchange 和 Active Directory 服务器的详细诊断信息，有助于您快速而且可靠地找到问题点。TCP/IP 工具（ping、tracert 以及 telnet）和 Network Monitor 等其他一些故障排除工具也可能会派上用场，因为这些系统之间的大多数通信都是通过计算机网络来完成的。Microsoft® Network Monitor 3.1 的下载地址为 go.microsoft.com/fwlink/?LinkId=120143。

出站邮件传输

资源

• SharePoint 产品和技术网站
• Windows SharePoint Services 技术中心
• Windows SharePoint Services 开发人员中心
• Microsoft SharePoint 产品和技术团队博客

在准备好了事件日志、跟踪日志、协议日志、邮件跟踪日志和网络跟踪之后，接下来我将开始对 SharePoint 消息传递集成进行故障排除。我们首先来介绍一下简单的部分：出站邮件传输。SharePoint 支持各种配置的出站邮件传输，并且在 Web 服务器上不需要本地 SMTP 服务。但是，在完整的消息传递集成方案中，使用本地 SMTP 服务是建议的配置。图 2 显示了此方案中的一些关键组件。

图 2 出站邮件传输（单击此图像可查看大图）

此消息传递方案包括四个阶段：SharePoint 必须将邮件传输到 SMTP 服务，SMTP 服务必须处理邮件，集线器传输服务器必须接收邮件，最后 Exchange Server 2007 必须将邮件传输到最终目的地。

如果 SharePoint 无法将邮件传给 SMTP 服务，而您在用户界面中收到一个错误消息，内容可能是说电子邮件通知无法发送。其原因可能是 SMTP 服务未运行。或者 SMTP 协议日志可能会告诉您 SMTP 服务拒绝该提交尝试，错误代码为 550（未执行请求的操作：邮箱不可用），这表示问题出在 SMTP 服务上。

为验证这并非是 SharePoint 的问题，您可以使用一个基本脚本（请参阅随附材料中的 SMTP.vbs）通过 SMTP 提交一封具有相同的发件人以及收件人信息的测试邮件。如果是 SMTP 服务的问题，此脚本将不会成功。实际上，此脚本可能会为您提供有关问题根本原因的一些有价值的线索，但遗憾的是 SharePoint 并未发现，即使启用了调试功能也是如此（如图 3 所示）。

图 3 无法中继邮件（单击此图像可查看大图）

通过在 SMTP 服务配置中授予 Web 服务器中继权限然后重新启动 SMTP 服务，您即可解决 SharePoint 的邮件提交问题。现在邮件可以抵达 SMTP 服务，下一个重要的问题是 SMTP 服务能否将邮件路由到集线器传输服务器。

如果邮件仍在 Queue 文件夹中，SMTP 服务无法联系集线器传输服务器。原因可能是 Microsoft Exchange 传输服务未运行或网络通信或配置存在问题。通过使用 Telnet 客户端，您可以快速且轻松地验证能否连接到为内部通信配置的接收连接器的目标端口。

它并非必须是 TCP 端口 25。实际上，如果 SMTP 服务使用此端口，则您可将邮件传输到集线器传输服务器的默认接收连接器（它被配置为阻止匿名邮件提交）。在这种情况下，您会在 Drop 文件夹中看到一个邮件文件。（必须停止 Windows SharePoint Services 计时器服务；否则，几秒钟后邮件就会消失。）邮件文件是一个传递状态通知，它指出邮件遭拒，并提示 "Diagnostic-code:smtp;530 5.7.1 Client was not authenticated"（诊断码：smtp;530 5.7.1 客户端未通过身份验证）。

要解决此问题，应为 SharePoint 服务器创建一个专用的接收连接器。由于 SharePoint 服务器是内部系统，因此请选择 Externally Secured（外部安全）身份验证选项。这样就不必向“匿名登录”帐户授予更多权限。另外，还可以考虑使用 IPsec 来保护 SharePoint 服务器与集线器传输服务器之间的通信。

如果邮件离开 SMTP Queue 文件夹且 SharePoint 服务器和集线器传输服务器上的 SMTP 协议日志（查看 %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive 文件夹）指示邮件传输成功，则可以认为作业已完成（假定 Exchange Server 2007 可以将邮件路由到目的地）。正如先前提到的，如果邮件没有到达预期的 Exchange 收件人，则使用 Exchange Server 2007 中附带的邮件流故障排除工具来调查问题。请注意，如果收件人信息、垃圾邮件筛选器和邮件大小限制不正确，也有可能导致此阶段最终传递失败。

入站邮件传输

在相反的方向上，由于一些更加微妙的潜在问题使得邮件传输变得更加复杂。例如，SharePoint 产品文档建议在 DNS 中为 SharePoint 电子邮件域配置 MX 记录，此方法经常导致在 Exchange 组织中误传邮件。

Exchange Server 2007 使用发送连接器以及相关地址空间来传输邮件。它可能会将 SharePoint 邮件路由到边缘传输服务器，以便即使 SharePoint 服务器是内部系统也可以通过 Internet 进行传输。对于内部邮件传输，使用的则是发送连接器和详细的地址空间，并在连接器配置中将运行 SMTP 服务的 SharePoint 服务器指定为智能主机（请参阅随附下载中的 SharePoint Messaging Integration.pdf）。建立一个定义良好的路由拓扑以及专用的桥头服务器有助于实现从 Exchange 到 SharePoint 的可靠邮件传输。

要验证邮件是否已到达 SharePoint 服务器，应停止 Windows SharePoint Services 计时器服务。邮件将被存放在 Drop 文件夹中，因为是计时器服务来负责处理邮件并将文件附件放置在与收件人电子邮件地址相关联的文档库中（如图 4 所示）。如果邮件没有到达 Drop 文件夹，可使用集线器传输服务器上的队列查看器来查看 Exchange 是否正确路由了邮件。然后再调查可能会阻止集线器传输服务器与 SharePoint 服务器上的 SMTP 服务进行通信的网络通信问题。

图 4 入站邮件传输（单击此图像可查看大图）

当重新启动计时器服务时，应查看邮件项目是否已从 Drop 文件夹中消失。但是，如果邮件附件最终并未以文档的形式进入目标库（即使 SharePoint 在 Windows 事件日志中指出邮件处理成功），则说明 Exchange 是以 Exchange RTF 格式发送的邮件。要调查此问题，请再次关闭计时器服务，通过 Outlook® 客户端再发送一封带有附件的邮件，然后在其到达 Drop 文件夹后用记事本打开该邮件。在其中搜索字符串 "winmail.dat"。如果发现此字符串，则表明 Exchange 服务器是以错误的格式发送的邮件。

SharePoint 要求邮件附件必须以 MIME 或 UUENCODE 格式进行编码。而且，SharePoint 不会在 Windows 事件日志中显示任何与 winmail.dat 相关的问题处理方法（请参阅图 5）。文件附件并不出现在文档库中。使用记事本作为故障排除工具，通过在 SharePoint 电子邮件域的 Exchange 管理控制台中配置远程域定义来消除格式问题。在 Format of original message sent as attachment to journal report（作为附件发送到日志报告的原始邮件的格式）选项卡中，选择 Exchange rich-text format（Exchange RTF 格式）下面的 Never use（永不使用）。

图 5 Winmail.dat 邮件处理（单击此图像可查看大图）

目录管理

其中一个非常有用的计时器服务事件是事件 6873，它表明在处理入站电子邮件文件时由于未知别名而发生错误。如果 Exchange 用户在发送邮件时指定了一个错误的 SharePoint 电子邮件地址（例如指定了一个不存在的文档库），则会发生此类事件。

要缓解此问题，可以在 SharePoint 管理中心的“传入电子邮件设置”中配置“目录管理服务”，以便在 Active Directory 中为启用了邮件功能的文档库创建收件人对象。然后，Exchange 用户可通过地址簿中的正确地址信息来方便地选择这些收件人对象。

但是请注意，您现在正在引入一个新的可能需要进行故障排除的问题。在基于最低权限原则的安全系统配置中，“目录管理服务”将失败，因为此功能已对 Web 服务器提升了权限要求。并且，在建议您应该在 OU 中（此 OU 是您在 Active Directory 中为 SharePoint 收件人对象指定的）授予管理中心应用程序池帐户“创建、删除和管理用户帐户”权限时，产品文档（如 technet.microsoft.com/library/cc262947.aspx）有些过于强调这一点了。

“目录管理服务”会创建联系人和组对象，因此管理中心应用程序池帐户需要完全控制此 OU 中的联系人和组对象，但它不需要用户帐户的管理权限。如果您按照本文所述在 Web 场中设置“目录管理服务”并尝试为文档库启用邮件功能，则出现“访问被拒绝”错误的机率非常大。

错误信息可指出 Active Directory 的具体权限问题，并且 SharePoint 管理员会迅速为 SharePoint OU 分配 Everyone 完全控制权限。但是，这不仅会削弱 Active Directory 的安全性，而且也无助于问题的解决。

结构化的故障排除方法要求首先找到问题点，然后再采用有针对性的配置变更。如果您遵循此方法来查看域控制器上的 Windows 事件日志并使用 Network Monitor 来跟踪网络通信，您可能会发现在此问题发生时 SharePoint 并未访问 Active Directory。因此 Active Directory 配置变更不可能会修复此问题。问题发生在 SharePoint 服务器上。

不幸的是，获取更多有关此权限问题的有用信息却比较困难。SharePoint 并未在 Windows 事件日志中记录任何附加信息。但是，如果启用 SharePoint 调试功能，则会看到调用堆栈（如图 6 所示），它指出“目录管理服务”使用了某个 SharePoint Web 服务的 CreateContact 方法。SharePoint SDK 会告诉您此服务是“电子邮件集成 Web 服务”(<WSS_server>:<admin_port>/_vti_bin/SharepointEmailWS.asmx)。

图 6 调试输出

Server was unable to process request. ---> Access is denied.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,      WebResponse response, Stream responseStream, Boolean asyncCall) 
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[]      parameters) 
   at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.CreateContact(String Alias,      String FirstName, String LastName, String ForwardingEmail, ContactFlags Flags) 
   at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String      newAlias) 
   at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration) 
   at Microsoft.SharePoint.SPList.Update() 
   at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender,      EventArgs args) 
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e) 
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument) 
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String      eventArgument) 
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean      includeStagesAfterAsyncPoint)

让我们在 Web 浏览器中看一看 SharepointEmailWS.asmx 以了解支持的操作列表。您可以在其中看到 CreateContact 方法，单击 CreateContact 链接时会显示 SOAP 消息，如果您想要在 Active Directory 中创建联系人，则必须将这些消息发送到此 Web 服务。这真是太棒了，因为现在您可以创建一个在 SharePoint 用户界面之外运行的基于脚本的故障排除工具（请参阅随附材料中的 SharepointEmailWS.vbs），从而能够在测试运行期间更方便地指定不同的用户帐户。图 7 显示了以管理中心应用程序池帐户身份（左）和 SharePoint 管理员帐户身份（右）运行此脚本时返回的信息。

图 7 两个不同的“访问被拒绝”错误（单击此图像可查看大图）

错误消息并不相同！两条消息均说明访问被拒绝，但左侧错误指出了问题处理方法，而右侧错误则没有。那么，应用程序池帐户与 SharePoint 管理员帐户之间究竟有什么不同呢？

SharePoint 管理员是 SharePoint 服务器上的本地管理员，而应用程序池帐户却并非如此。将 Web 应用程序的应用程序池帐户添加到本地管理员组并重新启动 Web 服务器可以解决此问题，但这并不是一种明智的做法。我认为在用于生产的 Web 服务器上以管理权限运行应用程序池帐户是不可接受的。

为什么应用程序池帐户需要这些提升的权限？同样，该脚本可揭示答案。如果出于测试目的授予所有用户对 Web 服务器的本地管理员权限，您会发现应用程序池帐户可以使用“电子邮件集成 Web 服务”，但所有其他帐户（包括 SharePoint 管理员）的访问仍被拒绝。这意味着“电子邮件集成 Web 服务”是使用应用程序池配置作为访问控制决策基础的。

应用程序池配置是 IIS 元数据库（或 IIS 7.0 中的 applicationHost.config 文件）的一部分，默认情况下只有本地管理员才能访问元数据库。幸运的是，也可以使用 IIS 6.0 资源工具包中所包含的 Metabase Explorer 来授予非管理员帐户访问元数据库的权限。在 IIS 7.0 中则更加简单，只需运行以下命令就可以授予对 applicationHost.config 文件的完全控制权限：

CACLS "%SystemDrive%\Windows\System32\inetsrv\config\applicationHost.config" 
/G "<application pool account>" :F /E iisreset /noforce

总而言之，要想在 Active Directory 中创建联系人对象，管理中心应用程序池必须对目标 OU 中的联系人和组对象具有完全控制权限。并且 Web 应用程序的池帐户还需要对 Web 场中 SharePoint 服务器上的元数据库具有完全访问权限。现在，已经做好了一切准备，可以开始使用 SharePoint 用户界面来创建联系人对象了。

请等一下，还有其他的问题！在 Active Directory 中创建收件人对象只完成了目录集成工作的一半。另一半工作是生成与 Exchange 相关的收件人属性并更新基于服务器的地址簿。例如，如果使用 Exchange 管理外壳命令 Update-GlobalAddressList "Default Global Address List" 来更新 Exchange 服务器上的全局地址列表，则可以在 Outlook 地址簿中显示为 SharePoint 文档库新创建的收件人对象。但是在向这些收件人发送邮件时，会由于地址信息不正确而生成未送达报告，如图 8 所示。

图 8 无法将邮件递送到文档库（单击此图像可查看大图）

首字母缩写词 IMCEAEX 代表 Internet Mail Connector Encapsulated Address for Exchange（用于 Exchange 的 Internet 邮件连接器封装地址）。它使用旧有 Exchange Internet 邮件连接器能够处理的格式来表示封装的非 Exchange 收件人地址。但是现在我们处理的是 Exchange Server 2007 和基于本机 SMTP 的发送连接器。

问题的关键在于 SharePoint 电子邮件集成 Web 服务并未写入 Exchange Server 2007 传输邮件时所需的地址属性。它只写入了名字、姓氏、显示名称和目标地址（或者 ms-Exch-RequireAuthToSendTo）属性。它并未设置邮件昵称（或传统的 Exchange DN 或代理地址），也未建立收件人对象与 Exchange 收件人策略的关联。

要解决此问题，可使用 Exchange 管理外壳中的 Get-Mailbox cmdlet 来获取所有收件人对象以及指向 SharePoint 电子邮件域的目标地址。然后再将输出内容传送到 Set-MailContact cmdlet 以激活 Exchange 收件人策略，如下所示：

Get-Contact | where { $_.WindowsEmailAddress –like
  '*sharepoint.contoso.com' } | Set-MailContact
  -EmailAddressPolicyEnabled:$True

或者，使用 Exchange 管理控制台并选中联系人对象属性中的 Automatically update e-mail addresses based on e-mail address policy（基于电子邮件地址策略自动更新电子邮件地址）复选框。

WSS 3.0 和 MOSS 2007 默认支持所有消息传递集成以允许基于电子邮件的警报和通知、工作流以及文档提交。邮件集成可以提高工作人员的效率，但正确配置系统并不是一件容易的事情。尤其是您必须确保入站和出站邮件传输都运行正常。还应确保目录集成可以正常工作。

SharePoint 错误消息有时不是很直观，无法通过它了解更多的参考信息。但是，我已向您展示了深入探究集成问题、找出根本原因以及在不危及 SharePoint 服务器安全的情况下可靠消除它们的方法。

Pav Cherny 是一位 IT 专家兼撰稿人，专门研究 Microsoft 协作与统一通信技术。他的作品包括白皮书、产品手册和书籍，其内容主要介绍 IT 运营和系统管理。Pav 是 Biblioso Corporation 的总裁，该公司主要经营托管文档和本地化服务。

© 2008 Microsoft Corporation 和 CMP Media, LLC。保留所有权利；未经允许不得复制本文的部分或全部内容。