動作メカニズムRPC エラーのトラブルシューティング

Zubair Alexander

長年、Windows サーバー プラットフォームに携わっていれば、一度ならずリモート プロシージャ コール (RPC) エラーを目にしたことがあるはずです。このエラーは、RPC サーバーが使用できないことや、使用できるエンドポイントがなくなったことを知らせたり、その他何らかの不可解な警告を提示したりします。こうしたメッセージによって混乱が生じたら、この記事をお読みください。ここでは、

いくつか共通するエラー、表示された RPC エラーの特定に使用できるさまざまな技法、および特定の問題を解決するいくつかの解決策について説明します。ただし、特定の RPC エラーや解決方法についてお話しする前に、RPC 用語の基礎知識を身に付けておきましょう。

RPC について

RPC とは、クライアントとサーバーの相互通信に使用されるプロセス間通信 (IPC) 方法の 1 つです。簡単に言えば、プログラム (通常はクライアント コンピュータ上のプログラム) からサーバー コンピュータ上のプログラムを実行する場合に RPC が使用されます。たとえば、Microsoft® Outlook® クライアントは、RPC を使用して Microsoft Exchange Server と通信します。クライアント コンピュータは、特定の引数を指定してサーバーにメッセージを送信します。サーバーは、プログラムの実行結果を含むメッセージをクライアントに返します。

このプロセスに不可欠なのがエンドポイントです。エンドポイントとは、クライアント要求を受信するためにサーバーが監視する、コンピュータ上の名前、ポート、またはポートのグループです。さらに具体的に言うと、エンドポイントは、RPC に使用されるサーバー プロセスのネットワーク固有のアドレスです。

RPC サブシステムの一部であるエンドポイント マッパーは、クライアント要求に応答して動的なエンドポイントの解決を担当します。エンドポイント マッパーは、状況によっては、エンドポイントの動的サーバー割り当ても担当します。

RPC のもう 1 つの重要なコンポーネントは、ロケータ サービスです。このコンポーネントは、ネットワーク上の RPC サービスと RPC サーバーの一覧を管理します。Windows® クライアントは、サーバー メッセージ ブロック (SMB) ポート (TCP 139 と 445) 経由でドメイン コントローラに接続し、ロケータ サービスを使用して RPC サービスまたは 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 サービスで問題が発生していると考えられる場合、その問題の診断に使用できるツールがいくつかあります。

1 つが Repadmin ツールです。このツールは、通常、Active Directory のレプリケーションの問題の監視とトラブルシューティングに使用しますが、RPC エンドポイント マッパーの問題のトラブルシューティングにも使用できます。このツールを実行するには、コマンド プロンプトで「repadmin /bind」と入力します。RPC に問題があれば、"エンドポイント マッパーから使用できるエンドポイントはこれ以上ありません。" などのメッセージが表示されます。これが、問題が RPC に関連していることを示す最初の手掛かりです。

もう 1 つは、ドメイン コントローラ診断ツール (DCDiag) を使用する方法です。このツールは、ドメイン コントローラの問題を診断するためのコマンド ライン プログラムです。エラー "ステータス 1722: RPC サーバーを利用できません。" が表示された場合は RPC の問題が発生していますが、これは、ドメイン コントローラ診断ツールで偶然発見されたにすぎません。

Ntdsutil を使用しているとき、サーバーへの接続時に RPC エラーが発生することがあります。このツールは、Active Directory の管理に使用するコマンド ライン ツールであり、さまざまなメンテナンス作業を実行します。このような場合多くは、"エンドポイント マッパーから使用できるエンドポイントはこれ以上ありません。" など、一般的なエラーのいずれかが表示されます。これも、RPC サーバーで問題が発生していることを示す手掛かりになります。RPC に問題が発生すると、ドメイン コントローラ上のグループ ポリシー オブジェクトの一貫性を確認する 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 に注目します。このエラー コードはメッセージ内に 4 回出現し、RPC サーバーが使用できないことを示しています。図 1 にエラー コードの一部とその説明を示しますが、msdn2.microsoft.com/ms681386 でより多くのエラー コードと説明を確認できます。

Figure 1 エラー コードとその説明

RPC エラーの解決

ここまで RPC エラーの検出方法をいくつか見てきましたが、ここからは解決策をいくつか見ていきましょう。

マイクロソフトのクライアントは、ポート 135 で RPC エンドポイント マッパーに接続します。次に RPC エンドポイント マッパーからクライアントに、要求したサービスをリッスンするポートを通知します。ポート番号は 1024 ～ 65,535 のいずれかに動的に割り当てられます。エンドポイント マッパーから使用できるエンドポイントがなくなったことを示す 1753 などのエラーが RPC 表示されるときは、RPC エンドポイント マッパーが 1024 以上のポートをサービスに割り当てられなかったことを意味します。このトピックは、この後、もう少し詳しく見ていくことにしましょう。

まず、サーバー上の RPC サービスの状態を確認します。RPC サービスと RPC ロケータ サービスは、サーバーの役割の種類に応じて図 2 に示す状態になります。2 つのサービスのいずれかがこの図と異なる構成であれば、状態を調整し、サーバーを再起動して問題が解決されるかどうかをテストします。

Figure 2 RPC サービスの状態

接続の問題が発生しているサーバーに、クライアントから正常に ping を実行できることを確認します。たとえば、IP アドレスが 192.168.1.200 の DC1 というサーバーへの接続に関して問題が発生しているとすると、コマンド プロンプトから次のコマンドを使用して、DNS によってホスト DC1 に正常に解決されることを確認します。

Ping –a 192.168.1.200

-a スイッチは、ホスト名ではなく IP アドレスと共に使用してください。

すべてが正常に機能する場合、図 3 のような ping 応答が DC1 から返されます。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 の右側のウィンドウからわかるように、レジストリに少なくとも 4 つの ClientProtocols が含まれます。

図 4 レジストリに表示される RPC ClientProtocols

不足しているエントリがあれば、図 4 に示した名前とデータの種類で新しい文字列値を追加します。既定では、ncacn_nb_tcp という 5 番目のエントリが存在します。このエントリは、NetBIOS over TCP をエンドポイントのプロトコル ファミリとして識別するために使用されます。構成によっては、ClientProtocols にエントリが存在しない場合がありますが、手動で追加して RPC エラーが解決するかどうかを確認できます。

図の左側のウィンドウの Rpc フォルダの下に表示されるキー、つまり、ClientProtocols、NameService、NetBios、および SecurityService を見てください。Internet というキーがあり、そのキーに値が設定されていない場合は、そのキーを削除してコンピュータを再起動します。これが、問題の解決に役立つ場合があります。ただし、Windows レジストリを変更する場合は、常に十分な注意が必要です。

前述のように、RPC では 1024 ～ 65,535 のポートを使用するため、これらのポートがファイアウォールでブロックされないようにする必要があります。ポートが開いていることを確認する最も簡単な方法は、Port Query ツールを使用することです。このツールには、コマンド ライン バージョン (PortQry) と GUI バージョン (PortQueryUI) の 2 つがあります。

PortQry は、Microsoft ダウンロード センターからダウンロードできます。詳細については、「Portqry.exe コマンド ライン ユーティリティの説明」を参照してください。この資料には、PortQry の状態レポートの簡単な説明と、問題の解決に使用するコマンド例が記載されています。GUI バージョンも使用できます。使いやすさは GUI バージョンの方がはるかに優れています。このバージョンは、go.microsoft.com/fwlink/?LinkId=73740 からダウンロードできます。

Port Query を使用する場合、必ず、RPC エラーが発生していないコンピュータと発生しているコンピュータの両方で実行します。たとえば、RPC エンドポイント マッパーによって使用されるポート 135 が開いていることを確認する場合は、コマンド プロンプトで次のように 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" のようにコンマで区切って入力します。

その他の解決策

ここまでに示したすべての方法を試しても問題が解決しない場合は、他にも試せる方法があります。環境固有の問題に応じて、レジストリの以下のいずれかの変更を試みることができます (ただし、特にレジストリの場合、問題が発生した場合にコンピュータを以前の状態に復元できるように、変更を加える前にシステムをバックアップしておくことが重要です)。

1 つは 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 より小さな値が設定されていることを検出すると、警告が表示されます。マイクロソフトでは、この値を 60,000 に設定することをお勧めします。それ以外の値を設定すると、イベント 9040 など、NSPI (Name Service Provider Interface) プロキシの警告が表示されることがあります。詳細については、マイクロソフトのドキュメント「MaxUserPort 値が小さすぎる」を参照してください。

また、TcpMaxDataRetransmissions も調整できます。TCP パケットでは、受信側から受信確認が返されることを期待します。指定時間内に受信確認が返されない場合は、TcpMaxDataRetransmissions に設定されている回数までパケットが再送されます。このパラメータの既定値は 5 ですが、4 または 3 に設定することもできます。2 以下の値は使用しないでください。

TcpMaxDataRetransmissions レジストリ エントリが存在しない場合、次に示すレジストリの場所に TcpMaxDataRetransmissions レジストリ エントリを追加できます。設定値も示します。

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5

TcpMaxDataRetransmissions の詳細については、マイクロソフト サポート技術情報の記事「TCP/IP の再送タイムアウトの最大値を変更する方法」を参照してください。

もう 1 つ試すことができるレジストリ値に、TcpTimedWaitDelay があります。クライアントで使用されるポートが多すぎると、閉じられた接続が TCP/IP から解放される前にポート不足が発生する可能性が高まります。これは、TCP/IP では、2 つの最大セグメント有効期間 (MSL) が経過する (TIME WAIT 状態とも呼ばれます) まで、接続が解放されないことが原因です。さらに、各 MSL が 120 秒と定義されており、TCP/IP では 2 つの MSL が経過するまで接続が解放されないため、閉じられた接続が解放されるまでには、最大で 240 秒 (4 分) かかります。これは、Windows NT® の既知の問題であり、Service Pack で修正されました。その結果、最近ではこの問題が発生する可能性は大幅に低下しました。ただし、マイクロソフトでは、サポート技術情報の記事「RPC エンドポイント マッパーのエラーのトラブルシューティングを行う方法」で説明されているように、RPC エンドポイント マッパー エラーの解決に使用できる解決策の 1 つとしてこの設定を調整することをお勧めします。

TcpTimedWaitDelay は、レジストリの次の場所に追加されています。

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD 
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)

TcpTimedWaitDelay の詳細については、サポート技術情報の記事「Windows NT クライアントでポートが不足する」を参照してください。この資料では特定の数値を推奨していませんが、TcpTimedWaitDelay を 10 進数で 60 (秒) まで減らすことができます。この値は 16 進数では 3c です。

まとめ

RPC エラーは、ネットワーク上の多くの通信エラーの根本原因になる可能性があります。さいわい、このような特定しにくい問題のトラブルシューティングを行える、独創的な方法がいくつかあります。ここで紹介したツールの一部は組み込みのツールですが、Windows Server Resource Kit から入手できるツールもあります。図 6 に多くのツールを記載しました。これらのツールを使用して、RPC エラーの原因と問題が発生した場所を検出し、ここで示した技法のいずれかを使用して RPC エラーを解決することができます。

Figure 6 RPC トラブルシューティング ツール

Zubair Alexanderは MCSE、MCT、Microsoft MVP を取得しており、IT トレーニングおよびコンサルティング企業である SeattlePro Enterprises のオーナーです。IT 教育の分野で、著者、大学講師、コンサルタント、ネットワーク エンジニア、講演者、セキュリティ アーキテクト、システム管理者、テクニカル エディタ、トレーナーなどの経験があります。Zubair の連絡先は alexander@techgalaxy.net (英語のみ) です。

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.