IT 如何運作RPC 錯誤的疑難排解

Zubair Alexander

若您使用 Windows 伺服器平台已有多年，遠端程式呼叫 (RPC) 錯誤對您而言應該是家常便飯了。碰到的錯誤可能包含 RPC 伺服器不存在，或者已經沒有結束點可用了，甚至提出其他難以理解的警訊。如果您對於這些訊息也感到困惑，請繼續閱讀本文。我將

在文中探討各種常見錯誤、可用來辨識 RPC 錯誤的多項技巧，以及討論解決特定問題的方法。不過在討論特定 RPC 錯誤和解決方法之前，讓我們先針對 RPC 的相關名詞打好基礎。

什麼是 RPC？

RPC 是一種處理程序之間的通訊 (IPC) 方法，由用戶端與伺服器之間用於通訊。簡單地說，RPC 通常會由用戶端電腦上的程式使用，以執行伺服器電腦上的程式。例如，Microsoft® Outlook® 用戶端會透過 RPC 與 Microsoft Exchange Server 進行通訊。用戶端電腦會在訊息中加上某些引數，一併傳送給伺服器電腦。伺服器會向用戶端回覆訊息，其中會包含執行程式的結果。

此處理程序中不可或缺的就是結束點 -- 亦即電腦的名稱、單一連接埠或整組連接埠，讓伺服器監控傳入的用戶端要求。更具體而言，這是 RPC 使用的伺服器處理程序的特定網路位址。

結束點對應程式屬於 RPC 子系統的一部分，負責回應用戶端要求，以解析動態結束點。在某些情況下，結束點對應程式亦負責將結束點動態指派給伺服器。

另一項重要的 RPC 元件是定位服務 (Locator Service)，其中會維護網路上的 RPC 服務與伺服器的清單。Windows® 用戶端會經由伺服器訊息區 (Server Message Block，SMB) 連接埠 (TCP 139 和 445) 連線到網域控制站，並透過定位服務搜尋 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 服務有關的線索。用來檢查網域控制站的 Group Policy 物件一致性的 Gpotool 工具，也會在 RPC 發生問題時出現類似的錯誤。

在您使用 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 錯誤碼及描述

解決 RPC 錯誤

您已經了解如何偵測出部分 RPC 錯誤，現在就讓我們一起看看其解決之道。

Microsoft 用戶端會透過連接埠 135 連接到 RPC 結束點對應程式。接著結束點對應程式就會告知用戶端要求的服務所接聽的連接埠。連接埠號碼會動態指派，且是介於 1024 和 65,535 之間的任意號碼。在您看到如 1753 這種錯誤，告訴您結束點對應程式沒有可用的結束點時，則代表 RPC 結束點對應程式無法針對某服務使用大於 1024 的連接埠。我稍後會進一步探討這個議題。

您首先必須做的，是檢查伺服器上的 RPC 服務的狀態。根據伺服器角色的類型，RPC 和 RPC 定位服務的狀態應該如 [圖 2] 所示。若這兩種服務皆未如圖中設定，請嘗試調整狀態、重新啟動伺服器，然後進行測試，以判斷問題是否已解決。

Figure 2 RPC 服務狀態

確認您的用戶端可以成功 Ping 到有連接問題的伺服器。舉例來說，若您無法與名為 DC1 的伺服器通訊，且該伺服器的 IP 位址是 192.168.1.200，請於命令提示字元中使用以下命令，以確認 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 over NetBIOS 做為結束點的通訊協定家族。根據您的設定，ClientProtocols 下方不一定會列出該項目，您可以手動新增以嘗試解決 RPC 錯誤。

在圖中左窗格的 Rpc 資料夾下，分別列出幾個機碼，包括 ClientProtocols、NameService、NetBios 及 SecurityService。若您正好看到名為 Internet 的機碼沒有數值，請嘗試移除該機碼，並重新啟動電腦。這樣可能可以幫您解決問題。不過，請永遠記得在修改 Windows 登錄時要特別小心。

如上所述，RPC 可使用介於 1024 和 65,535 之間的連接埠，因此您必須確認這些連接埠並未受到防火牆的阻擋。若要確認連接埠是否通暢，最簡單的方法就是使用 Port Query 工具。此工具共有兩種型態：一是命令列版本 (PortQry)，二是 GUI 版本 (PortQueryUI)。

PortQry 可以從 Microsoft 下載中心下載。如需詳細資訊，請參閱文章 Portqry.exe 命令列公用程式的說明。該文章內包括 PortQry 狀態報告的簡要說明，以及可用來解決問題的命令範例。請記住，您也可以使用更簡便的 GUI 版本，下載位置為：go.microsoft.com/fwlink/?LinkId=73740。

在使用 Port Query 時，請確保是在未發生 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 已開啟。否則，最後一行會表示 NOT LISTENING (並未進行接聽)。

若要檢查某範圍內的連接埠，請輸入連接埠編號範圍，中間以半形逗號隔開，如 "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 Best Practices Analyzer (BPA) 發現 MaxUserPort 登錄機碼的值小於 50,000，就會顯示警告。Microsoft 建議您將此值設定為 60,000，否則可能導致 Name Service Provider Interface (NSPI) Proxy 發出警告，例如事件 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 在兩個 Maximum Segment Lives (MSL) 結束之前 (代表等待時間狀態)，都不會釋出連線。此外，由於每個 MSL 皆定義為 120 秒，而 TCP/IP 在兩個 MSL 結束前都不會釋放連線，因此 TCP/IP 需要 240 秒 (4 分鐘) 的時間才會釋出已關閉的連線。注意：這是 Windows NT® 中的已知問題，並且已經有 Service Pack 修正此問題。因此現在已不太可能遇到這樣的問題。然而，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 疑難排解工具

Zubair Alexander 是 MCSE、MCT 和 Microsoft MVP，也是 SeattlePro Enterprises 這家 IT 訓練與諮商公司的負責人。他的經歷涵蓋 IT 教育的以下範疇：作家、大學講師、諮商顧問、網路工程師、公開演說家、安全性設計師、系統管理員、技術編輯以及訓練員。Zubair 的連絡方式為 alexander@techgalaxy.net。

© 2008 Microsoft Corporation and CMP Media, LLC. 保留所有權利；未經允許，嚴禁部分或全部複製.