Exchange 管理包的三大配置问题

 

上一次修改主题: 2005-08-19

您可以使用 Exchange Server 2003 管理包监视 Microsoft® Exchange Server 2003 的性能、可用性和安全性,出现对服务器可用性有直接影响的事件时向您发出警报,同时筛选出无需采取操作的事件。 导入时,Exchange 管理包开始监视您的环境中运行 Exchange 的服务器。 但是,一些脚本需要配置。 有时,在配置期间,您可能会遇到一些错误不知该如何解决。 本文章就配置方面最常见的三大问题进行讨论,Microsoft 客户就这三个问题致电请求帮助解决。 讨论这些问题前,让我们简单回顾一下如何准备配置运行 Exchange 的服务器才能进行监视。

部署 Exchange 管理包时,Microsoft Operations Manager (MOM) 为您处理大多数配置,它采用隐式运行从而确定在您的环境中运行 Exchange 的服务器,并且对那些服务器强制执行管理包中的规则。 其中的一些规则针对某些属性检查服务器的当前配置,而且可以调用为准备用于监视的服务器而必要更改的其他规则。 开始激活这些规则时,您可以看到 MOM 管理员控制台中事件气泡弹出,表示该过程正在进行。 最后,您应该看到一些其他事件,这些事件引导您采取必要步骤完成 MOM 开始的配置工作。

此时,运行 Exchange 管理包配置向导以帮助您进行 MOM 要求的最终配置更改,以完全监视 Exchange 功能,如邮箱可用性、邮件流或服务。 遗憾的是,您可能也发现因为 MOM 所做的基本准备失败而无法运行向导。

我们在 Exchange 管理包支持中不时看到的一个问题是,无法完成运行 Exchange 服务器的监视配置。 这种情况可能是因为部署管理包时缺失一般幕后发布的数据。 我们试图解释发生这种情况的原因以及一旦发生要查找哪些内容。

从配置向导,您可能看到以下错误:

错误: 无法配置计算机 <servername> 上的邮箱访问帐户。 只有由 MOM 注册 Exchange MOM 事件 9986 后,才可进行该配置。

我们将解释该 9986 事件和何时会出现该事件以及可能找不到它的一些原因。 触发后端 Exchange 服务器的首要规则之一就是邮箱可用性测试。 与该规则相关的脚本检查注册表数据,以确定测试可行性。 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExMPLS 注册表项用于存储加密的域帐户凭据证书,该帐户用于访问运行 Exchange 的每台服务器上的监视邮箱。 该“邮箱访问帐户”(MAA) 必须有登录测试邮箱的权限,因为 MOM 使用这些凭据在登录期间模拟帐户。 如果注册表数据缺失,则该规则生成可触发另一规则的事件,另一规则随即引起发布存储凭据的缺失项。

要发布该注册表项,Exchange 服务器需要安装的“帮助程序”分布式 COM (DCOM) 对象才能与发布规则一起使用。 DCOM 对象负责发布存储 MAA 凭据的注册表项,它是作为 Exchange Server 2003 安装程序的一部分进行安装的。 但是,对于 Exchange 的早期版本,MOM 根据需要安装帮助程序对象,或可手动安装。 发布的规则调用 DCOM 对象以在服务器上发布所需的数据。

如果 DCOM 和帮助程序对象功能正常运行,则创建 ExMPLS 注册表项。 在发布数据时,生成 9986 事件而且您应该可以对那台服务器运行配置向导。 然后,向导以加密方式将 MAA 凭据写入注册表项中。 同时,如果担心缺失该事件,则现在可以完全放心,因为每日要运行检查规则,在数据成功发布后生成 9986 事件。

如果发布失败,则该规则生成事件并在 MOM 管理员控制台中显示,以向管理员发出失败警报。 失败可能是缺失 DCOM 对象或 DCOM 对象异常或 DCOM 权限配置不当而导致的。 缺失或异常的 DCOM 对象作为 Exchange 管理包的一部分进行安装,可能很难进行故障排除且难以解决。 如果生成 9986 事件时遇到故障,请与 Microsoft 客户支持联系获取帮助。 有关调查和解决与默认的 DCOM 权限设置有关的详细信息,请参阅 Microsoft 知识库文章 274696 搜索和拖放之类的操作因为已在 Dcomcnfg.exe 工具中更改默认访问权限而不起作用

生成 9986 事件后,您可以运行“配置向导”配置您的环境,以监视 Exchange。 “配置向导”创建邮箱访问帐户 (MAA) 和测试(代理)帐户以及邮箱。 这些帐户用于 MAPI 登录脚本和 OWA 登录脚本,以便监视 Exchange 服务器。

要验证是否安装了“邮箱存储”以及 Microsoft Office Outlook® 用户是否可以成功登录,Exchange 管理包运行 MAPI 登录验证脚本。 在该脚本中,MAA 凭据被用于实际登录和打开“测试”邮箱 (servernameMOM) 的邮箱。 “邮件流验证”脚本也使用 MAPI 登录来发送和接收邮件。 您可以看到登录到运行 Exchange 的服务器,方法是通过在“邮箱存储”文件夹下“登录”部分下的“Exchange 系统管理器”中查看。 您应该看到“测试”邮箱;注意 MAA 是用于登录的 Microsoft Windows® 帐户。

MAPI 登录脚本错误是我们最常见到的一些问题。 您可能会看到几个不同的错误消息,包括 MAPI_E_NOT_FOUND、MAPI_E_LOGON_FAILED 和 MAPI_E_NOT_INITIALIZED。 有关这些错误消息的一些常见原因的详细信息,请参阅 Exchange Server Management Pack Guide for MOM 2005(英文网页)中的“权限和目录访问错误”。

如果您遇到了 MAPI 登录错误,则要遵循该部分中的所有故障排除步骤,因为这些问题的原因复杂多样,只解决其中一个可能掩盖了其他潜在的问题。 有关 MAPI 错误的详细信息,请参阅知识库文章 238119 信息: 扩展 MAPI 数字结果代码的列表

另外,您也应该验证 MAA 是否对 MAPI 登录测试使用的邮箱有足够的邮箱权限。 通过作为“邮箱访问”帐户打开 Outlook 可以验证 MAA 是否有权限。 然后打开“测试”邮箱,方法是依次转到“文件”、“打开”、“其他用户的文件夹”,然后选择测试邮箱。 您应该能够看到测试帐户中的收件箱。 如果您不能打开该邮箱,则打开“Active Directory 用户和计算机”并查看测试邮箱的属性。单击“Exchange 高级”,再单击“邮箱权限”。 应该在此列出 MAA,并且应该为其授予“完全邮箱访问”、“删除”邮箱存储和“读取”权限。

如果仍存在打开测试邮箱方面的问题,请检查以确保没有隐藏 MOM 使用的邮箱(MAA 和测试邮箱)。 如果帐户被隐藏在全局地址列表 (GAL) 中,则 MAPI 登录脚本或邮件流验证脚本将无法使用帐户。 如果帐户没有被隐藏但您仍然无法登录 Outlook,那么确定帐户是被如何创建的,有时是非常有用的。 可能会从创建帐户的方式(例如,使用配置向导、手动创建帐户或使用第三方提供的产品创建帐户)中找到无法登录 Outlook 的线索。

另一种测试方法是,使用“邮箱访问帐户”的登录凭据登录到运行 Exchange 的服务器上的 Windows。 打开“Exchange 系统管理器”,依次展开“管理组”、“服务器”,并继续展开直到您可以选择左方的“邮箱”。 您能够看到右边的邮箱列表吗? 如果看不到,则可能是“邮箱访问帐户”已经拒绝了“查看信息存储状态”。 您可以遵循下面的 ADSI Edit 步骤,并深化服务器的属性。 单击“安全”选项卡(请参阅下面的步骤 10)。 选择“邮箱访问”帐户并在权限列表中滚动。 确保“查看信息存储状态”已继承“允许”。 如果继承了“拒绝”,则检查“CN=服务器”、CN=yourAdministrativeGroup 和“CN=管理组”的属性,以便查找“拒绝”。

下面是 ADSI Edit 中检查明确“拒绝”的步骤:

  1. 打开 ADSI Edit。
  2. 在左窗格中的“控制台根目录”下,用鼠标右键单击 ADSI Edit。
  3. 选择“连接到”。
  4. 在“连接设置”窗口中,在“连接点”部分中查看并选择“选择一个已知命名上下文”,然后在下拉菜单中,选择“配置”。单击“确定”。
  5. 在“控制台根目录”窗口中,展开“配置”旁边的加号。
  6. 展开“CN=配置,DC=”旁边的加号。
  7. 展开“CN=服务”。
  8. 展开“CN=Microsoft Exchange”。
  9. 突出显示 CN=<yourOrgName>,然后单击“属性”。
  10. 单击“安全”选项卡。
  11. 查找“邮箱访问帐户”,并使用“拒绝”验证它没有“代理发送”或“代理接收”的权限。

您在 ADSI Edit 中时,验证“代理发送”和“代理接收”没有被“管理组”级别或 Exchange 服务器拒绝。

Active Directory® 目录服务问题也可能导致 MAPI 登录验证脚本间歇失败。如果无法访问域控制器,或域控制器未及时响应,则 MAPI 登录将失败。启动 Exchange System Attendant 服务(如果未启动)。 验证代理邮箱的配置,并纠正配置中的任何错误。 验证域中的域控制器是可访问的,并且用户可以使用 Outlook 登录。

您也可以启用运行 Exchange 的服务器上的日志记录,以帮助解决问题。 在运行 Exchange 的服务器上,添加下列注册表项(键入 DWORD)并将值设为 1:

\\HKLM\Software\Microsoft\Exchange MOM\DebugLS

note注意:
记住,关闭日志记录时,将值设为 0。

停止并重新启运行 Exchange 的服务器上的 MOM 服务。 确保授予“邮箱访问帐户”对 %systemdrive% 的完全权限;否则,任何方式都无法登录 ExMPLS_LOG.txt。确保在之后删除权限!

请等待,直到 MAPI 登录验证脚本运行(等待一晚),并寻找位于 %systemdrive% 中的名为 ExMPLS_LOG.txt 的文件。 该日志文件通常对解决 MAPI 登录问题非常有用。

如果在执行这些步骤后仍然存在与 MAPI 登录有关的问题,请致电 Microsoft 客户服务和支持部门 (CSS) 获得进一步的解决。

与 Microsoft® Office Outlook® Web Access 2003 和 Microsoft Outlook® Mobile Access 登录验证脚本有关的问题是客户有时会遇到的另一个问题。 Exchange 管理包在包含综合登录测试的“可用性与状态监视规则组”下提供几个规则组。 这些规则组使用移动技术之一(如 Outlook Web Access、Outlook Mobile Access 或 Exchange ActiveSync)模拟邮箱登陆。 由于综合登录过程的复杂性,我们有时看到这样的错误,尽管通过 Internet Explorer 实际上可以可以登录到 Outlook Web Access,但在 MOM 中仍显示登录失败。 我们经常看到的这种错误可分为以下类别:

说明:

OWA 登录失败。

URL:未定义

无法衡量 OWA 可用性。 意外错误。

无法在该服务器上找到可形成有效 URL 的 Exchange 虚拟服务器和虚拟目录(SSL 已启用)。 尝试提供自定义 URL 注册表项中的 URL(请参阅“配置”指南获得详细信息)

乍一看来,好象是登录无法找到 Exchange 虚拟服务器。 因此,登录失败。 但是,您知道自己拥有 Exchange 虚拟服务器。 而且当您每天外出时,都要使用 Outlook Web Access 检查邮件。 那么,发生该错误的真是原因是什么呢? 上面错误中暗含的微妙原因是 URL 被退回,未定义。 为了更好地理解究竟发生了什么,那么先让我们花几分钟时间来解释 Outlook Web Access 综合登录过程的工作原理。

Outlook Web Access 登录验证脚本说明了这个过程。 尽管脚本有多项任务,但是它的核心任务如下:

  • 启用到 OWAAvailability 自动对象的引用,该对象被退回到 objOwa
  • 读取下列注册表项并检索 CustomURL 和 BEAccount 字符串的值: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange MOM\FEMonitoring\<FEServerName>
  • objOwa.OWALogon 传递邮箱名称和找到的任一 customURL 值
  • 记录 MOM 操作员控制台中的结果(成功或失败)

OWALogon 脚本功能采用以下三个参数: 我们要登录的 BEMailbox、超时值和 URL。 该功能被称为多次调用,具体情况取决于在注册表中找到的 customURLs 数量。 第一次调用通常使用 NULL URL 值进行,该值最终将测试 https://localhost,后续调用以循环测试 customURLs 的方式进行。 我们关注的是第一个使用 NULL URL 的调用。

OWALogon 脚本功能负责将其接收的参数传递给自动对象 objOwa.OWALogon,该对象将为我们解决大量繁重的工作。 因为我们没有在三个参数中传递(保留 URL NULL),所以 objOwa.OWALogon 首先要做的是调用构建用于测试的 URL 的方法。 该方法 GetExchangeURL 将返回指定邮箱的 URL。 但是,GetExchangeURL 无法确定邮箱中传递的 URL,它返回 NULL,日志记录为意外错误。

现在我们知道为什么会记录为错误,您可以看到为什么我们建议 URL:未定义行暗含细微的线索。 正如错误所暗指的那样,我们无法确定 URL 的内容;因此才导致失败。 了解 GetExchangeURL 需要大量的时间。

首先要复查此代码,我们会吃惊地发现开发者在此方法中投入了大量工作。 那么我们要做的肯定是返回 https://localhost,对吗? 嗯,这要看具体情况。 如果我们有多个 Exchange 虚拟目录或服务器,每一个都发布到了各自的 URL(作为承载),怎么办? 我们需要知道邮箱所属的虚拟服务器,因此才能知道我们在测试正确的 URL。 好了,这样我们就无法做出任何假设而且也不需要构建用于测试邮箱的正确 URL。 在此没有篇幅详细介绍整个 GetExchangeURL 流程;但是会对它的主要步骤进行简要介绍。

  • 获得测试邮箱的主要 SMTP 地址   这是使用 samAccountName 对测试邮箱的简单轻型目录访问协议 (LDAP) 进行搜索。 proxyaddress 属性是读取和分析并查找以 SMTP 开始的地址: (注意大写;非主要地址是小写)。 然后分析该值以提取域名。 要测试该步骤,请执行下列 LDAP 搜索并验证测试邮箱是否返回:
    (&(objectClass=user)(objectCategory=person)(samAccountName=testmailbox))
  • 搜索虚拟目录   更多 LDAP 搜索。 我们不在此更加详细地探究,因为这一点非常普遍,并且不是关注的重点所在。 最终结果是查询前端服务器上的 HTTP 虚拟服务器。
    (&(objectCategory=msExchProtocolCfgHTTPVirtualDirectory)(folderPathname=MBX))
  • 检查虚拟目录 SMTP 域   检查 msExchDefaultDomain 属性中出现的虚拟服务器,并验证是否进行了设置(默认情况下是未进行设置的)。 如果已进行了设置,则查看它是否匹配邮箱的主 SMTP 域或非主 SMTP 域。 如未设置 msExchDefaultDomain,则查看邮箱的主 SMTP 地址是否匹配默认的接收方策略的主 SMTP 域。 例如,如果测试邮箱标记为使用 @it.contoso.com 的自定义策略,但是默认的接收方策略配置为标记 @contoso.com,那么我们就会失败。
    important重要提示:
    这种情况最常见的原因是 GetExchangeURL 返回我们在 Microsoft CSS 中看到的 NULL。
  • 验证是否已在虚拟目录上启用 SSL   检查是否存在 IIS://localhost/W3SVC/1/root/Exchange/AccessSSLFlags 元数据库属性。 您可以使用被称为 Metabase Explorer 的 Internet 信息服务 (IIS) 资源工具包工具检查此值。 有关 IIS 资源工具包中的该工具和其他工具的详细信息,请参阅知识库文章 840671 IIS 6.0 资源工具包工具。 有关 AccessSSLFlags 属性的详细信息,请参阅“IIS 6.0 操作指南”的“IIS 6.0 参考”部分中的 AccessSSLFlags Metabase Property (IIS 6.0)(英文网页)。
  • 检查 secureBindings 的值   获得 IIS://localhost/W3SVC/1/secureBindings 元数据库属性并进行分析。 如果 secureBindings 属性以 :<portNumber> (:443) 开始,则将虚拟服务器设置为“所有未分配”,然后将 URL 设置为 https://localhost。 如果属性不是以 “:” 开始,则分析分配到该端口的 IP 地址。 然后使用到 Win32_NetworkAdapterConfiguration 的 WMI 调用验证该 IP 地址,并将返回的IPAddress 属性与 secureBindings 属性中找到的 IP 地址相比较。 如果找到匹配,则将 URL 设置为 https://ipaddress。 如果未找到匹配,则返回 NULL。 您可以再次使用 Metabase Explorer 查看设置的属性。 如果以 IP 地址开始,则可以使用 WBEMTest 查询 Win32_NetworkAdapterConfiguration 类并检查 IPAddress 属性。 有关 secureBindings 属性的详细信息,请参阅“IIS 6.0 操作指南”的“IIS 6.0 参考”部分中的 SecureBindings Metabase Property (IIS 6.0)(英文网页)。 有关如何使用 WBEMTest 的详细信息,请参阅 Scripting Eye for the GUI Guy(英文网页)。

如果检查了以上各项,您仍然无法确定 GetExchangeURL 返回 NULL 的原因,则 Microsoft CSS 有一个名为 OWACheck 的工具,对解决该问题有极大的帮助。 请联系 CSS 获得该工具和更多疑难解答的帮助。

 
显示: