IT 运作方式排除 RPC 错误
Zubair Alexander
如果您多年来使用的都是 Windows 服务器平台,那么可能曾经看到过远程过程调用 (RPC) 错误。它们提示您 RPC 服务器无法使用,或者没有更多的可用终结点,或提供某个其他难懂的警告。如果您对这些消息感到困惑,请继续阅读。我会
谈到一些比较常见的错误,以及可用来识别所遇到的 RPC 错误的各种技术,并会讨论一些可以解决某些特定问题的解决方案。但是在我讨论 RPC 错误和解决方案之前,先让我们大致了解一下 RPC 技术。
什么是 RPC?
RPC 是一种进程间通信 (IPC) 方法,客户端和服务器可使用这种方法来进行相互之间的通信。简单地说,RPC 可被程序(通常是客户端计算机上的程序)用来执行服务器计算机上的程序。例如,Microsoft® Outlook® 客户端可通过使用 RPC 与 Microsoft Exchange Server 通信。客户端计算机会使用某些参数将消息发送到服务器计算机。而服务器则会以一条包含执行程序的结果的消息响应客户端。
此过程的组成部分是终结点,即计算机上的名称、端口或端口组,由服务器监视经过其传入的客户端请求。更具体地讲,它是用于 RPC 的服务器进程特定于网络的地址。
终结点映射程序 (Endpoint Mapper) 是 RPC 子系统的一个组成部分,负责响应客户端要解析动态终结点的请求。在某些情况下,终结点映射程序还负责动态地将终结点分配给服务器。
另一个重要的 RPC 组件就是 Locator 服务。它维护网络上的 RPC 服务和服务器列表。Windows® 客户端会连接到服务器消息块 (SMB) 端口(TCP 139 和 445)上的域控制器,并通过 Locator 服务搜索 RPC 服务或服务器。
大多数内置的 Windows 服务都通过 RPC 相互通信。例如,证书服务、DCOM、FRS、MSMQ、MAPI 和 Active Directory® 复制服务都使用 RPC 来进行通信。因此,如果 RPC 服务不能网络上正常运行,则您可能就会遇到很多通信问题。
RPC 错误
现在让我们看一些 RPC 服务失败时您可能会遇到的错误。(这并不是完整的列表。)
当文件复制服务 (FRS) 失败时,运行时可能会出现可怕的“RPC 无法使用”错误。当您试图映射一个驱动器时,可能会遇到“拒绝访问”错误。当使用 Active Directory 用户和计算机时,可能会看到错误消息“指定的域不存在或无法联系。”登录域时,可能会看到一条错误消息,指明“缺少该系统主域的计算机帐户或该帐户的密码不正确,无法让您登录此域。”
当 Microsoft Outlook 客户端试图与 Exchange Server 通信时,RPC 失败可能会导致客户端遇到“您的登录信息不正确”或“Outlook 无法登录”等令人误解的错误。
除了这些错误外,当 RPC 服务不可用时,您可能还会遇到其他问题。例如,可能会无法浏览“网上邻居”中的域,或者可能无法打开“组策略”管理单元。
这些只是一部分示例而已,在这些示例中您可能没想到 RPC 会引起问题。在更多示例中,以及在涉及远程过程的任何时候,RPC 问题都有可能是造成您困境的根本原因。那么您要如何确定,以及更重要的是,如何跟踪到精确的错误呢?让我们来了解一下。
故障排除
如果您怀疑您的 RPC 服务遇到了问题,您可以使用好几个工具来诊断这些问题。
一个是 Repadmin 工具。这个程序通常是用来监视和排除 Active Directory 复制问题,但是它也可以用来排除 RPC 终结点映射程序的问题。要运行该工具,可在命令提示符下键入 repadmin /bind。如果您遇到了 RPC 问题,会看到类似下面这样的消息:“终结点映射程序没有更多可用的终结点。”这是与 RPC 相关的问题的第一个提示。
另一个选择是使用“域控制器”诊断工具 (DCDiag),这是一个通过域控制器诊断问题的命令行程序。如果您看到错误“状态为 1722:RPC 服务器无法使用”,您就知道遇到了“域控制器”诊断工具恰巧发现的 RPC 问题。
很多时候,您都在使用 Ntdsutil(用来管理 Active Directory 和执行大量维护任务的命令行工具),这个时候如果您试图连接到服务器,就可能会遇到 RPC 错误。最有可能的就是您会看到更常见的错误之一,例如“终结点映射程序没有提供更多的终结点”。同样,这是 RPC 可能存在问题的一个提示。如果真是 PRC 存在问题,检查域控制器上“组策略”对象一致性的 Gpotool 工具也会报出同样的错误。
使用 Dcpromo 工具将 Windows 2000 Server 或 Windows Server® 2003 服务器提升为域控制器时产生的 Dcpromo.log 也可以显示 RPC 的问题。例如,如果提升失败,可以查看一下该日志。它位于 %windir%\debug 文件夹。列出的错误大意是目录服务无法复制分区,或无法创建对象。在此消息结束的地方会有一个错误代码。下面是您可以在 Dcpromo.log 中看到的错误消息类型的一个示例:
08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
the directory service (1722)
注意错误代码 1722,在这条消息中出现了四次,这指明 RPC 服务器无法使用。图 1 列出了部分错误代码及其说明,更多的错误代码及其说明可以在 msdn2.microsoft.com/ms681386 中找到。
Figure 1 错误代码及其说明
错误代码 | 说明 |
58 | 指定的服务器不能执行请求的操作。 |
1721 | 没有足够的资源可用于完成此操作。 |
1722 | RPC 服务器不可用。 |
1723 | RPC 服务器太忙,无法完成此操作。 |
1727 | 远程过程调用失败,尚未执行。 |
1753 | 终结点映射程序没有提供更多的终结点。 |
解决 RPC 错误
既然您已掌握了检测某些 RPC 错误的方法,接下来就让我们看一下部分解决方案。
Microsoft 客户端会连接到端口 135 上的 RPC 终结点映射程序。然后终结点映射程序会告诉该客户端请求的服务在侦听哪一个端口。系统会动态分配这些端口号,可以是 1024 和 65,535 之间的任何端口号。当您遇到错误时,例如 1753,就表示终结点映射程序没有提供更多的终结点,这意味着 RPC 终结点映射程序无法对服务使用大于 1024 的端口。我们稍后再进一步讨论这个主题。
您需要做的第一件事是检查服务器上 RPC 服务的状态。根据服务器角色的类型,RPC 和 RPC Locator 服务应具有图 2 中所列的状态。如果两个服务都没有像图中显示的那样配置,请尝试调整状态,重新启动服务器,然后进行测试,看它是否解决了您的问题。
Figure 2 RPC 服务的状态
服务器角色 | RPC 服务 | RPC Locator 服务 |
Windows Server 2003—域控制器 | 已启动,自动 | 已停止,手动 |
Windows Server 2003—成员服务器 | 已启动,自动 | 已停止,手动 |
Windows Server 2003—独立服务器 | 已启动,自动 | 已停止,手动 |
Windows 2000 Server—域控制器 | 已启动,自动 | 已停止,自动 |
Windows 2000 Server—成员服务器 | 已启动,自动 | 已启动,手动 |
Windows 2000 Server—独立服务器 | 已启动,自动 | 已停止,手动 |
请验证您的客户端是否可以成功地 Ping 存在连接问题的服务器。例如,如果您在与 IP 地址为 192.168.1.200,名为 DC1 的服务器通信时遇到了问题,则在命令提示符下使用下面的命令来验证 DNS 是否在正确地解析主机 DC1:
Ping –a 192.168.1.200
请确保是将 –a 开关与 IP 地址(而不是主机名)搭配使用。
如果一切顺利,您应该会得到 DC1 的响应,如图 3 中所示的 Ping 响应。注意 Ping 不只是解析 IP 地址 192.168.1.200,还解析主机名 dc1.contoso.com。这确定了 DNS 名称解析在正常运行,并且如期望的那样正确地解析到主机 dc1.contoso.com。
Figure 3 Ping 响应
C:\WINDOWS>ping -a 192.168.1.200
Pinging dc1.contoso.com [192.168.1.200] with 32 bytes of data:
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.1.200:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
您还应确保 Windows XP 或 Windows 2000 客户端上的注册表至少包含图 4 右窗格中列出的四个 ClientProtocols。
图 4** 列入注册表的 RPC ClientProtocols **
如果缺少任一项,则添加一个图 4 中所示名称和数据类型的新字符串值。在默认情况下,还有一个名为 ncacn_nb_tcp 的第五项,它可用来识别基于 TCP 的 NetBIOS,将其作为终结点的协议家族。根据您的配置,您的 ClientProtocols 下可能没有列出这一项,这时您可以手动添加此项以查看它是否解决了 RPC 错误。
注意列在图中左窗格中的 Rpc 文件夹下的项,即 ClientProtocols、NameService、NetBios 和 SecurityService。如果您恰巧看到名为 Internet 但没有值的项,请尝试删除该项,然后重新启动您的计算机。这可能会帮助您解决问题。但是在您修改 Windows 注册表时始终要非常小心。
如前面所述,RPC 可以使用 1024 到 65,535 之间的端口,因此您需要确保这些端口没有被防火墙封锁。要确保端口开放的最简单的方法就是使用“端口查询”工具。这个工具有两种类型:命令行版本 (PortQry) 和 GUI 版本 (PortQueryUI)。
PortQry 可在 Microsoft 下载中心下载。有关其他信息,请查看文章“有关 Portqry.exe 命令行实用工具的说明”。在那里您可以找到 PortQry 状态报告的简要说明以及用来解决问题的命令示例。请不要忘记您还可以使用 GUI 版本,它更加简单,可以在 go.microsoft.com/fwlink/?LinkId=73740 下载。
使用“端口查询”时,您应该确保在没发生过 RPC 错误的计算机上运行它,并且是针对发生了 RPC 问题的计算机来运行它。例如,如果您想验证端口 135(它被 RPC 终结点映射程序占用)是否开放,可以在命令提示符下使用 PortQry,如下所示:
portqry -n [servername] -e 135
无论您使用的是 PortQuery 还是 PortQueryUI,您都会获得结果,如下所示:
Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...
TCP port 135 (epmap service): LISTENING
最后一行显示端口 135 是开放的。否则,最后一行会指明“未侦听”。
要查看端口的范围,请输入以英文逗号隔开的端口号范围,例如“135,1024-5000”。
其他解决方案
如果尝试了目前列出的所有办法还是没有解决您的问题,这里还有一些其他方法供您选择。根据您环境中的具体问题,您可能想要尝试对注册表进行下列其中一项修改。(等等!在修改注册表前,请确定您已备份您的系统,尤其是注册表,这很重要;这样如果真的发生错误,您可以将您的计算机恢复到之前的状态。)
一个方法是调整 MaxUserPort,以指定当应用程序请求系统的可用用户端口时 TCP 可分配的最大端口号。在默认情况下,Windows Server 2003 会将 MaxUserPort 的值设置为 5000,这表示它以 5000 作为最大端口号,即使此项不存在。根据您的配置,您的注册表中可能没有此项,这时您可以将此项添加到图 5 所示的位置。
图 5** 注册表中的 MaxUserPort 设置 **
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000
在修改注册表时,您需要注意任何其他潜在的负面影响,它并不总是那么容易。如果将这个值设置为 50,000,则修改此项可能会对 Microsoft Exchange Server 有影响。如果 Exchange Server 最佳实践分析工具 (BPA) 发现 MaxUserPort 注册表项的值小于 50,000,它会显示一个警告。Microsoft 建议您将值设置为 60,000;否则您可能会引发命名服务提供程序接口 (NSPI) 代理警告,例如事件 9040。有关详细信息,请参阅 Microsoft 的文档“MaxUserPort 值太小”。
您还可以调整 TcpMaxDataRetransmissions。TCP 数据包期望能收到接收端的确认。如果在计时器到时之前还没有确认,则会重传数据包,最多 TcpMaxDataRetransmissions 次。此参数的默认值是 5,但是您可能想尝试 4 或 3 这些值。请不要使用小于 3 的值。
如果 TcpMaxDataRetransmissions 注册表项不存在,您可以将它添加到注册表的下列位置,如下所示:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5
有关 TcpMaxDataRetransmissions 的详细信息,请参阅 Microsoft 知识库文章 170359“如何修改 TCP/IP 最大重传超时时间”。
另一个您可能想实验的注册表项是 TcpTimedWaitDelay。如果用户端使用了过多的端口,很可能它会在 TCP/IP 释放关闭的连接之前用尽端口。这是因为 TCP/IP 直到经过段最大生存时间 (MSL) 的两倍时间后才会释放连接(这称为时间等待状态)。此外,因为每个 MSL 都被定义为 120 秒,而 TCP/IP 直到经过 2 个 MSL 后才会释放连接,因此需要长达 240 秒(4 分钟)的时间才能让 TCP/IP 释放一个关闭的连接。注意,这是一个使用 Service Pack 进行改正后的 Windows NT® 中已知的问题;因此目前您不太可能会遇到这个问题。但是,Microsoft 建议调整这个设置,使之成为一个可以解决 RPC 终结点映射程序错误的可能解决方案,正如知识库文章“如何排除 RPC 终结点映射器错误”中所说明的一样。
可将 TcpTimedWaitDelay 添加到注册表的下列位置:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)
有关 TcpTimedWaitDelay 的详细信息,请参阅知识库文章“Windows NT 客户端用尽端口”。尽管该文章没有建议任何特定的数字,但是您可能会想将 TcpTimedWaitDelay 降到以十进制表示的 60(秒),而以十六进制表示则为 3c。
结束语
RPC 错误可能是您的网络出现各种通信错误的根本原因。幸运的是,您现在有好几种创新方法,可以帮助排除这些难以捕捉的问题。我在这里推荐的工具有些是内置的,有些是 Windows Server Resource Kit 中提供的。很多都已在图 6 中列出。您可以使用这些工具来检测 RPC 错误的原因和位置,然后使用本文列出的其中一项技术来解决这些错误。
Figure 6 RPC 故障排除工具
工具 | 说明 |
DCDiag | 分析域控制器的状态。 |
事件查看器 | 显示记录的事件。 |
Gpotool | 确定策略是否有效、一致。 |
NetDiag | 用于测试网络连接。 |
Network Monitor | 监视和捕获网络通信。 |
Ntdsutil | 为 Active Directory 提供管理工具。 |
PortQry,PortQueryUI | 用于 TCP/IP 连接测试。 |
Repadmin | 诊断 Windows DC 之间的复制问题。 |
RPCDump | 通常与 Network Monitor 一起使用。 |
RPCPing | 用于确认 RPC 连接。 |
Zubair Alexander 是 MCSE、MCT 和 Microsoft MVP,也是一家 IT 培训和咨询企业 SeattlePro Enterprises 的所有者。他的经验涉及 IT 培训领域的诸多方面:作家、大学教授、顾问、网络工程师、公开演讲人、安全架构师、系统管理员、技术编辑和培训师。您可以通过 alexander@techgalaxy.net 与 Zubair 联系。
© 2008 Microsoft Corporation 与 CMP Media, LLC.保留所有权利;不得对全文或部分内容进行复制.