Windowsで「Error 1722: The RPC server is unavailable」を修正する方法

エラーの概要

リモートマシンに対してサービス、イベントビューアー、またはデバイスマネージャーを開こうとしたとき、あるいは sc コマンドを実行したとき、Windowsが突然次のエラーで処理を止めます：

Error 1722: The RPC server is unavailable.

マシンはオンラインです。pingも通ります。しかし、RPCに関わる操作はすべて失敗します。原因を特定して修正する方法を解説します。

根本原因

RPC（Remote Procedure Call）は、Windowsのリモート管理ツールのほぼすべてで使われているトランスポート層です。エラー1722は、クライアント側がネットワークには到達できたものの、ハンドシェイクを完了できなかったことを意味します。主な原因は以下のいずれかです：

対象マシンで Remote Procedure Call (RPC) サービスまたは RPC Endpoint Mapper が停止している
ファイアウォールがTCPポート 135（RPC Endpoint Mapper）または動的RPCポート（49152〜65535）をブロックしている
ネットワークアダプタープロファイルがプライベートからパブリックに切り替わり、リモート管理ルールが無効になっている
DNSが誤ったIPを返しており、RPCがエンドポイントを特定できない（DHCPの変更後にドメイン環境でよく発生する）
VPNの再接続やネットワーク変更により、対象への古いルートが残っている

手順1 — 対象マシンでRPCサービスが動作していることを確認する

まずRDPまたは物理的に対象マシンにログインします。その後、次のコマンドを実行します：

sc query RpcSs
sc query RpcEptMapper

どちらも STATE: 4 RUNNING と表示される必要があります。停止している場合は起動します：

net start RpcSs
net start RpcEptMapper

RpcSs が起動を拒否する場合、システムが異常な状態にあります。eventvwr を開き、「Windowsログ」→「システム」でソースが Service Control Manager のイベントをフィルタリングすると、原因を示すイベントが記録されています。

手順2 — 対象マシンのWindowsファイアウォールルールを確認する

多くの場合、これが問題の原因です。対象マシンで次を実行します：

# リモート管理ルールの有効状態を確認する
Get-NetFirewallRule -DisplayName "*Remote*" | Select DisplayName, Enabled, Profile

以下の3つのルールグループが有効になっている必要があります：

Remote Service Management (RPC)
Remote Service Management (RPC-EPMAP)
Windows Management Instrumentation (WMI-In)

2つのコマンドですべて有効にします：

Enable-NetFirewallRule -DisplayGroup "Remote Service Management"
Enable-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)"

PowerShellリモートアクセスが使えない場合は、netshにフォールバックします：

netsh advfirewall firewall set rule group="Remote Service Management" new enable=Yes
netsh advfirewall firewall set rule group="Windows Management Instrumentation (WMI)" new enable=Yes

手順3 — 自分のマシンからポート135に到達できることを確認する

作業用ワークステーションから実行します：

Test-NetConnection -ComputerName TARGET_HOSTNAME -Port 135

TcpTestSucceeded : False の場合、ファイアウォール（Windowsファイアウォール、ハードウェアファイアウォール、またはネットワークACL）が通信をブロックしています。ポート135が開放されるまでRPCは機能しません。以上です。

ついでに、動的ポートもいくつか確認しておきます：

Test-NetConnection -ComputerName TARGET_HOSTNAME -Port 49152
Test-NetConnection -ComputerName TARGET_HOSTNAME -Port 49153

手順4 — ファイアウォールプロファイルの不一致を修正する

Windowsはドメイン、プライベート、パブリックのネットワークごとに別々のファイアウォールルールセットを持っています。リモート管理ルールはドメインとプライベートにのみ適用されます。ネットワーク変更やDHCPの問題でNICがパブリックに切り替わると、これらのルールが静かに無効になります。

対象マシンの現在のプロファイルを確認します：

Get-NetConnectionProfile

社内LANアダプターで NetworkCategory: Public と表示されている場合は修正します：

Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory Private

上記の出力に表示されたインターフェイス名に合わせて Ethernet を書き換えてください。

手順5 — DNS解決を確認する

RPCはエンドポイントの検索時に内部でホスト名を使用します。古いDNSレコードが誤ったIPを返すだけで、ファイアウォールやサービスが正常であっても通信がすべて壊れる可能性があります。

# 作業用マシンから実行
nslookup TARGET_HOSTNAME

# PowerShellの代替コマンド
Resolve-DnsName TARGET_HOSTNAME

IPが違う、または解決に失敗する場合は、DNSレコードを修正するか、ホスト名の代わりにIPアドレスで直接接続します。対象マシン上でDNSキャッシュのフラッシュと再登録を行います：

ipconfig /flushdns
ipconfig /registerdns

手順6 — PowerShellリモートを使用している場合はWinRMを有効にする

PowerShellリモートとWMIは、RPCの上に独自のトランスポート層を持っています。Windows Remote Managementサービスが停止していると、基本的なRPCが正常でもエラー1722が発生します。

# 最速の修正方法 — 対象マシン上で実行
winrm quickconfig

# またはPSリモートを強制的に有効化
Enable-PSRemoting -Force

確認

作業用ワークステーションに戻り、すべてが正常に動作していることを確認します：

# ポート135のテスト
Test-NetConnection -ComputerName TARGET_HOSTNAME -Port 135

# リモートサービスのクエリ（Spoolerは常に存在する）
Get-Service -ComputerName TARGET_HOSTNAME -Name Spooler

# 旧来の方法
sc \\TARGET_HOSTNAME query Spooler

Get-Service がエラーなしで結果を返した場合、RPCは正常に動作しています。また、services.msc を開き、ルートノードを右クリック→「別のコンピューターに接続」でホスト名を入力する方法でも確認できます。サービス一覧が読み込まれれば完了です。

本番環境向けクイックチェックリスト

対象に到達できるか？ — pingの後、Test-NetConnection -Port 135 を実行
RPCサービスは動作しているか？ — sc query RpcSs と sc query RpcEptMapper
ファイアウォールルールは有効か？ — Remote Service Managementグループを確認
ネットワークプロファイルは正しいか？ — 社内アダプターはドメインまたはプライベート（パブリックは不可）
DNSは正しく解決できるか？ — nslookup TARGET_HOSTNAME で正しいIPが返ることを確認
VPNや最近のネットワーク変更はあるか？ — VPNを再接続するかアダプターを再起動

対象が別のサブネットにある場合

RPCを疑う前に、基本的なルーティングの問題を除外してください。管理用ワークステーションが対象と異なるVLANにある場合（セグメント化されたサーバー環境ではよくあるケース）、IPルーティングが実際に設定されていることを確認する必要があります。私は ToolCraftのSubnet Calculator を使ってCIDR範囲を素早く確認し、両マシンが同じサブネットにあるか、またはルートが存在するかを確かめています。ブラウザ上で完全に動作し、データは外部に送信されません。

予防策

すべてのサーバーに Remote Service Management と WMI のファイアウォールルールを強制するGPOを適用する — ローカル設定はずれが生じるが、ポリシーは維持される
監視スタックで RpcSs と RpcEptMapper のサービス状態をアラート設定する — 両サービスの停止は、サービス依存関係の変更が失敗したときの既知の副作用である
ファイアウォールが動的ポート範囲を処理できない場合は、RPCを固定範囲に限定する：HKLM\Software\Microsoft\Rpc\Internet に使用するポート範囲（例：50000〜50100）を定義し、そのポートのみ開放する
サーバー上のすべてのネットワークアダプターについて、意図するファイアウォールプロファイルをドキュメント化する — NICが静かにパブリックに切り替わる問題は繰り返し発生する無音の障害要因である