リモート プロシージャ コール (RPC) エラーのトラブルシューティング ガイダンス

適用対象: Windows クライアント

Windows Management Instrumentation (WMI) または Microsoft SQL Serverに接続するとき、リモート プロシージャ コール (RPC) セッション中、またはさまざまな Microsoft 管理コンソール (MMC) スナップインを使用しているときに、"RPC サーバーを使用できません" エラーが発生する可能性があります。次の図は、RPC エラーの例を示しています。

これは一般的なネットワーク エラーであり、トラブルシューティングを正常に行うには、プロセスに関する基本的な知識が必要です。 まず、理解すべき重要な用語がいくつかあります。

• エンドポイント マッパー (EPM): ポートと UUID の情報を使用して、サーバーをリッスンし、クライアント アプリをサーバー アプリに誘導するサービス。
• タワー: クライアントとサーバーが接続をネゴシエートできるようにする RPC プロトコルについて説明します。
• フロア: ポート、IP アドレス、識別子など、特定のデータを含むタワー内のコンテンツレイヤー。
• UUID: RPC アプリケーションを識別する既知の GUID。 トラブルシューティング中に UUID を使用して、1 つの種類のアプリケーションの RPC 会話を追跡できます (一度に 1 台のコンピューターで発生する多くの種類のアプリケーションの中で)。
• Opnum: クライアントがサーバーを実行する関数を識別します。 これは単に 16 進数です。 ただし、優れたネットワーク アナライザーによって関数が変換されます。 関数を識別できない場合は、アプリケーション ベンダーに問い合わせてください。
• ポート: クライアントまたはサーバー アプリケーションの通信エンドポイント。 EPM は、クライアントとサーバーが使用する動的ポート (ハイ ポートまたはエフェメラル ポートとも呼ばれます) を割り当てます。

  注:

  通常、ポート番号は、トラブルシューティングに使用する最も重要な情報です。

• スタブ データ: クライアント上の関数とサーバー上の関数の間で交換されるデータ。 このデータは、通信の重要な部分であるペイロードです。

接続のしくみ

次の図は、リモート操作を実行するためにサーバーに接続しているクライアントを示しています。 クライアントは最初にサーバー上の TCP ポート 135 に接続し、動的ポート番号を EPM とネゴシエートします。 EPM がポートを割り当てた後、クライアントは切断し、動的ポートを使用してサーバーに接続します。

RPC による動的ポートの割り当て方法の構成

既定では、EPM は TCP と UDP 用に構成されている範囲から動的ポートをランダムに割り当てます (使用されているオペレーティング システムの実装に基づいて)。 ただし、クライアントとサーバーがファイアウォールを介して通信する必要がある場合は特に、この方法は実用的でない可能性があります。 別の方法として、EPM で使用するポート番号またはポート番号の範囲を指定し、ファイアウォールでそれらのポートを開きます。

RPC に依存する多くの Windows サーバー アプリケーションでは、許可されるポートをカスタマイズするためのオプション (レジストリ キーなど) が用意されています。 Windows サービスでは、このタスクに HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\Internet サブキーが使用されます。

ポートまたはポート範囲を指定する場合は、一般的に使用されるポートの範囲外にあるポートを使用します。 Windows および主要な Microsoft 製品で使用されるサーバー ポートの包括的な一覧については、「 サービスの概要」および「Windows のネットワーク ポート要件」を参照してください。 また、この記事では、RPC サーバー アプリケーションの一覧を示し、RPC ランタイムの機能を超えてカスタム サーバー ポートを使用するように構成できる RPC サーバー アプリケーションについても説明します。

既定では、 インターネット キーは存在しません。 そのため、作成する必要があります。 インターネット キーの場合は、次のエントリを構成できます。

• ポート REG_MULTI_SZ: ポートまたは包括的なポート範囲を指定します。 インターネットの下に表示されるその他のエントリは、使用するポートか、使用から除外するポートかを示します。

  • 値の範囲: 0 - 65535
    たとえば、 5984 は 1 つのポートを表し、 5000 から 5100 はポートのセットを表します。 値が 0 から 65535 の範囲外にある場合、またはいずれかの値を解釈できない場合、RPC ランタイムは構成全体を無効として扱います。

• PortsInternetAvailable REG_SZ: [ポート] の値が含めるポートまたは除外するポートを表すかどうかを指定します。

  • 値: Y または N (大文字と小文字は区別されません)
    • Y: [ポート] エントリに一覧表示されている ポート は、EPM で使用できるそのコンピューター上のすべてのポートを表します。
    • N: [ポート] エントリに一覧表示されている ポート は、EPM で使用できないすべてのポートを表します。

• UseInternetPorts REG_SZ: 既定のシステム ポリシーを指定します。

  • 値: Y または N (大文字と小文字は区別されません)
    • Y: 既定のシステム ポリシーを使用するプロセスには、前に定義したインターネットで使用可能なポートのセットからポートが割り当てられます。
    • N: 既定のシステム ポリシーを使用するプロセスには、イントラネット専用ポートのセットからポートが割り当てられます。

ポート 5000 より大きいポートの範囲を開く必要があります。 5000 未満のポート番号は、既に他のアプリケーションで使用されている可能性があり、DCOM アプリケーションと競合する可能性があります。 さらに、以前のエクスペリエンスでは、少なくとも 100 個のポートを開く必要があることを示しています。 これは、複数のシステム サービスが、これらの RPC ポートを使用して相互に通信するためです。

RPC のしくみの詳細については、「 RPC over IT/Pro」を参照してください。

カスタム ポート構成の例

この例では、新しいレジストリ エントリを構成する方法を示すために、ポート 5000 から 6000 (包括的) を任意に選択しました。 この例は、特定のシステムで必要な最小数のポートの推奨ではありません。 このような構成では、HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpcの下に インターネット キー を 追加し、次のエントリを追加する必要があります。

• ポート MULTI_SZ
  • データ型: MULTI_SZ
  • 値: 5000-6000
• PortsInternetAvailable REG_SZ
  • データ型: REG_SZ
  • 値: Y
• UseInternetPorts REG_SZ
  • データ型: REG_SZ
  • 値: Y

この構成を有効にするには、コンピューターを再起動する必要があります。 その後、RPC を使用するすべてのアプリケーションには、5000 ~ 6000 (包括的) の範囲の動的ポートが割り当てられます。

RPC エラーのトラブルシューティング

Portqry

PortQry では、ネットワーク トレース データを掘り下げる前に、RPC がどのように機能しているかを簡単に把握できます。 クライアント コンピューターで次のコマンドを実行することで、接続を確立できるかどうかを簡単に判断できます。

Portqry.exe -n <ServerIP> -e 135

たとえば、次のコマンドを考えてみましょう。

Portqry.exe -n 169.254.0.2 -e 135

このコマンドは、次の抜粋のような出力を生成します。

Querying target system called:
169.254.0.2
Attempting to resolve IP address to a name...
IP address resolved to RPCServer.contoso.com
querying...
TCP port 135 (epmap service): LISTENING
Using ephemeral source port
Querying Endpoint Mapper Database...
Server's response:
UUID: d95afe70-a6d5-4259-822e-2c84da1ddb0d
ncacn_ip_tcp:169.254.0.2[49664]

この出力を調べることで、次の情報を確認できます。

• DNS が正しく動作しています (IP アドレスが完全修飾ドメイン名 (FQDN) に解決されました)。
• PortQry は、ターゲット コンピューターの RPC ポート (135) に接続しました。
• EPM は PortQry に応答し、後続の通信のために動的ポート 49664 (角かっこで囲まれた) を割り当てた。
• PortQry がポート 49664 に再接続されました。

これらの手順のいずれかが失敗した場合は、通常、次のセクションで説明するように、同時ネットワーク トレースの収集を開始できます。

PortQry の詳細については、「 PortQry コマンド ライン ツールの使用」を参照してください。

Netsh

Windows netsh ツールを使用して、クライアントとサーバーでネットワーク トレース データを同時に収集できます。

同時ネットワーク トレースを収集するには、クライアントとサーバーの両方で管理者特権のコマンド プロンプト ウィンドウを開きます。

クライアントで、次のコマンドを実行します。

Netsh trace start scenario=netconnection capture=yes tracefile=c:\client_nettrace.etl maxsize=512 overwrite=yes report=yes

サーバーで、次のコマンドを実行します。

Netsh trace start scenario=netconnection capture=yes tracefile=c:\server_nettrace.etl maxsize=512 overwrite=yes report=yes

次に、クライアント コンピューターで問題を再現してみてください。 次に、両方のウィンドウのコマンド プロンプトで次のコマンドを実行して、トレースを停止します。

Netsh trace stop

Microsoft Network Monitor 3.4 または Message Analyzer でトレース ファイルを開き、サーバーまたはクライアント コンピューターと TCP ポート 135 の IP アドレスのトレース データをフィルター処理します。 たとえば、次のようなフィルター文字列を使用します。

• Ipv4.address==<client-ip> と ipv4.address==<server-ip> と tcp.port==135

  このフィルター文字列では、<client-ip> はクライアントの IP アドレスを表し<、server-ip> はサーバーの IP アドレスを表します。

• tcp.port==135

フィルター処理されたデータで、[プロトコル] 列で EPM エントリを探します。

動的ポート番号を含む EPM (サーバー上) からの応答を探します。 動的ポート番号が存在する場合は、今後参照するために注意してください。

動的ポート番号とサーバー IP アドレスのトレース データを再フィルター処理します。 たとえば、 tcp.port==<dynamic-port-allocated> や ipv4.address==<server-ip> などのフィルター文字列を使用します。 このフィルター文字列では、 <動的ポート割り当ては> 動的ポート番号を表し、 <server-ip> はサーバーの IP アドレスを表します。

フィルター処理されたデータで、クライアントが動的ポートに正常に接続されたことを示す証拠を探すか、発生した可能性のあるネットワークの問題を探します。

ポートに到達できない

"RPC サーバーが使用不可" エラーの最も一般的な原因は、クライアントが割り当てられた動的ポートに接続できないことです。 クライアント側トレースでは、動的ポートの TCP SYN 再送信が表示されます。

この動作は、次のいずれかの条件が通信をブロックしていることを示します。

• ダイナミック ポート範囲は、環境内のファイアウォールでブロックされます。
• 中央のデバイスがパケットをドロップしています。
• 宛先サーバーがパケットを削除しています。 この状態は、 Windows フィルタリング プラットフォーム (WFP) パケット ドロップ、ネットワーク インターフェイス カード (NIC) パケット ドロップ、 フィルター ドライバー の変更などの構成によって発生する可能性があります。

より詳細なトラブルシューティングのためのデータの収集

Microsoft サポートに問い合わせる前に、問題に関する情報を収集することをお勧めします。

前提条件

これらの手順では、 TroubleShootingScript (TSS) ツールセットを使用します。 このツールセットを使用するには、次の前提条件に注意する必要があります。

• ローカル コンピューターに対する管理者レベルのアクセス許可が必要です。

• ツールセットを初めて実行するときは、EULA に同意する必要があります。

• コンピューターのWindows PowerShell スクリプト実行ポリシーが にRemoteSigned設定されていることを確認します。 PowerShell 実行ポリシーの詳細については、「 about_Execution_Policies」を参照してください。

  注:

  環境でコンピューター レベルで使用 RemoteSigned できない場合は、プロセス レベルで一時的に設定できます。 これを行うには、ツールを起動する前に、管理者特権の Powershell コマンド プロンプト ウィンドウで次のコマンドレットを実行します。

  PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned
  

  変更が有効であることを確認するには、コマンドレットを実行します PS C:\> Get-ExecutionPolicy -List 。

  プロセス レベルのアクセス許可は、現在の PowerShell セッションにのみ適用されます。 PowerShell ウィンドウを閉じると、実行ポリシーは元の設定に戻ります。

Microsoft サポートに連絡する前に重要な情報を収集する

1. すべてのノードで TSS をダウンロードし、 C:\tss フォルダーに展開します。

2. 管理者特権の PowerShell コマンド プロンプト ウィンドウで C:\tss フォルダーを開きます。

3. 次のコマンドレットを実行して、問題のあるコンピューターでトレースを開始します。

   TSS.ps1 -Scenario NET_RPC
   

4. EULA プロンプトに応答します。

5. 問題を再現します。 イベント ビューアーや wbemtest などのツールを使用して、問題を監視またはテストできます。

6. 問題を再現したら、すぐにデータの収集を停止します。

7. 自動スクリプトで必要なデータの収集が完了したら、サポート リクエストにデータをアタッチします。