次の方法で共有

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

  • [アーティクル]

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

RPC サーバーが使用できないことを示すエラー メッセージのスクリーンショット。

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

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

    Note

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

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

接続のしくみ

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

クライアントがリモート サーバーに RPC 接続する方法を示す図。

重要

ファイアウォールがクライアントとサーバーを分離する場合、ファイアウォールはポート 135 と EPM が割り当てる動的ポートでの通信を許可する必要があります。 このシナリオを管理する方法の 1 つは、EPM で使用するポートまたはポートの範囲を指定することです。 詳細については、「 RPC による動的ポートの割り当て方法の構成を参照してください。

一部のファイアウォールでは、UUID フィルター処理も許可されます。 このシナリオでは、RPC 要求でポート 135 を使用してファイアウォールを通過し、EPM に接続すると、ファイアウォールは要求に関連付けられている UUID をメモします。 EPM が応答し、その UUID の動的ポート番号を送信すると、ファイアウォールもポート番号をメモします。 その後、ファイアウォールによって、その UUID とポートに対する RPC バインド操作が許可されます。

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

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

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

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

重要

このセクション、方法、またはタスクには、レジストリの編集方法が記載されています。 レジストリを誤って変更すると、深刻な問題が発生することがあります。 したがって、次の手順を注意深く実行してください。 保護のために、レジストリを変更する前にレジストリをバックアップして、問題が発生した場合にレジストリを復元できるようにします。 レジストリのバックアップと復元方法の詳細は、「Windows のレジストリのバックアップおよび復元の方法」を参照してください。

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

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

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

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

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

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

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

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

Note

必要なポートの最小数は、コンピューターによって異なる場合があります。 RPC 動的ポートが制限されている場合、より多くのトラフィックをサポートするコンピューターでポート不足が発生する可能性があります。 ポート範囲を制限する場合は、これを考慮してください。

警告

ポート構成にエラーがある場合、またはプールに十分なポートがない場合、EPM は動的エンドポイントを使用する RPC サーバー アプリケーション (Netlogon などの Windows サービスを含む) を登録できません。 構成エラーが発生した場合、エラー コードは 87 (0x57) ERROR_INVALID_PARAMETER。 たとえば、十分なポートがない場合、Netlogon はイベント 5820 をログに記録します。

ログ名: システム
ソース: NETLOGON
イベント ID: 5820
レベル: エラー
キーワード: クラシック
説明:
Netlogon サービスで AuthZ RPC インターフェイスを追加できませんでした。 サービスが終了しました。 次のエラーが発生しました: 'パラメーターが正しくありません。'

RPC のしくみの詳細については、IT/Pro RPC に関するを参照してください。

カスタム ポート構成の例

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

  • ポート 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

Note

このコマンドでは、 <ServerIP> は、接続しているサーバーの IP アドレスを表します。

たとえば、次のようなコマンドを考えてみます。

Portqry.exe -n 10.10.10.10 -e 135

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

Querying target system called:
10.10.10.10
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:10.10.10.10[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 でトレース ファイルを開き、サーバーまたはクライアント コンピューターの IP アドレスと TCP ポート 135 のトレース データをフィルター処理します。 たとえば、次のようなフィルター文字列を使用します。

  • Ipv4.address==<client-ip> および ipv4.address==<server-ip> および tcp.port==135

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

  • tcp.port==135

フィルター処理されたデータで、Protocol 列の EPM エントリを探します。

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

動的ポートが強調表示されているネットワーク モニターのスクリーンショット。

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

フィルターが適用されているネットワーク モニターのスクリーンショット。

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

ポートに到達できない

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

TCP SYN 再送信を示すネットワーク モニターのスクリーンショット。

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

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

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

前提条件

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

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

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

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

    Note

    環境でコンピューター レベルで 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. 自動化されたスクリプトが必要なデータの収集を完了したら、サポート要求にデータを添付します。