MENU

PowerShellでのPC名変更時に出る「RPCサーバーが利用できません」エラーの原因と解決策

PowerShell

多くの組織では、Active Directory環境でコンピューター名を管理する必要があります。その際、PowerShellを用いてドメイン環境に接続されたPCの名前を変更しようとしたときに「RPCサーバーが利用できません」といったエラーに直面することがあります。本記事では、その原因や具体的な対処策をじっくり解説していきます。

目次

PowerShellで発生する「RPCサーバーが利用できません」エラーとは

PowerShellでコンピューター名を変更する際、以下のようなコマンドを使用することが多いです。

Rename-Computer -ComputerName "A" -NewName "A1" -DomainCredential (Get-Credential) -Force -Restart

このコマンドは、オンプレミスAD環境下でコンピューター名を変更し、すぐに再起動をかける便利な手法ですが、ネットワークや設定によっては「The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)」といったエラーが表示されることがあります。主に、RPC通信が正常に行われないケースが原因となります。

RPC (Remote Procedure Call) とは

RPCは、リモートホストとの通信を行うための仕組みです。Windows環境では、WMI (Windows Management Instrumentation) やレジストリ操作、リモート管理など、多くの場面でRPCが利用されます。RPC通信が何らかの理由でブロックされていると、コンピューター名変更といった操作が失敗する場合があります。

よくあるエラーの文言

  • 「Cannot establish the WMI connection … The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)」
  • 「WinRMでの接続に失敗しました」
  • 「WMI接続エラーが発生しました」

これらはいずれもリモート通信が確立できないことを示すエラーです。

原因1：ネットワーク接続とファイアウォール設定

RPC通信が失敗する最も一般的な理由として、ネットワーク上のファイアウォールやポート設定が挙げられます。

通信ポートの確認

WindowsでRPC通信を行うためには、以下のポートが正しく通信できる状態である必要があります。

ポート番号役割
TCP 135RPCエンドポイントマッパー (RPC Endpoint Mapper)
TCP 1024～65535RPCダイナミックポート (動的に割り当てられるRPCポート)

オンプレミス環境で独自にファイアウォールやネットワーク機器を運用している場合、TCP 135番や動的ポートレンジがブロックされていると、PowerShellによるコンピューター名変更が失敗する可能性があります。まずはこれらのポートが開放されているかを確認しましょう。

Windowsファイアウォールの一時停止で検証

エラーの切り分けを行うために、一時的にWindowsファイアウォールを停止させてRPC通信をテストすると、有効なヒントを得られることがあります。停止方法は以下の通りです。もちろん、本番環境で試す場合は安全に配慮してください。

# Windows ファイアウォールをすべてのプロファイルで停止
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False

再度、コンピューター名変更コマンドを実行し、問題が解消するかどうかをチェックします。もし解消した場合は、ファイアウォールのポート設定を見直す必要があるでしょう。

原因2：DNS設定の不備

Active Directoryの環境でPC名やドメインの操作を行う場合、DNSの名前解決が大きなカギとなります。DNSが正しく設定されていないと、RPCサーバー側のホスト名やIPアドレスを正しく解決できず、RPC通信が行えません。

DNSエントリとリバース ロックアップの確認

ドメインコントローラーや対象のクライアントPCが正しく登録されているか、以下の点を見直してください。

  1. DNSサーバー上に正しいホスト(A)レコードが存在するか
  2. リバース ロックアップゾーンにPTRレコードが正しく登録されているか
  3. DHCPを使用している場合、DNSへの動的更新が成功しているか

環境によっては、古いキャッシュや誤ったレコードが残っているケースもあります。念のため、DNSキャッシュをクリアし、再度名前解決を試す方法も有効です。

# クライアント側でDNSキャッシュをクリア
ipconfig /flushdns

# 名前解決の動作確認
nslookup <ターゲットホスト名またはIPアドレス>

ドメイン環境におけるDNSの重要性

AD環境では、Kerberos認証やLDAPなど、さまざまな機能がDNSを基盤として動作します。わずかな誤設定や名前解決の不一致が原因で、多くのトラブルが起こりやすいです。特に複数のDNSサーバーを運用している場合や、サブドメインを使用しているケースでは、設定の食い違いに注意しましょう。

原因3：必要なサービスが停止している

PowerShellのRPC通信を円滑に行うためには、Windows上のいくつかのサービスが稼働している必要があります。とくに以下のサービスをチェックしましょう。

チェックすべきサービス一覧

サービス名役割スタートアップの種類
RPC (Remote Procedure Call)RPC通信の中核となるサービス自動
TCP/IP NetBIOS HelperNetBIOS名解決のサポート、NetBIOS関連の通信を補助自動または手動
Remote Registryリモートマシンのレジストリにアクセスするためのサービス必要に応じて手動

これらが停止していると、PowerShellからのリモート操作ができず、「RPCサーバーが利用できません」エラーの原因となります。サードパーティ製のセキュリティソフトや、ポリシー設定によって意図せず停止してしまっている場合もあるため、まずはサービスの稼働状況を確認してみてください。

サービスの状態を確認するPowerShellコマンド例

# サービス状態の確認
Get-Service -Name RpcSs, Tcpip, RemoteRegistry

たとえば「RpcSs」がStoppedになっている場合は、自動起動に設定し、手動で開始する必要があります。

原因4：システム時刻やタイムゾーンの不一致

ドメイン環境では時刻の同期が非常に重要です。Kerberos認証が絡む操作を行う場合、時刻のずれが原因で認証エラーが生じ、結果としてRPC通信が失敗するケースもあります。

時刻同期の確認

ドメインコントローラーとクライアントPCが同じ時刻を保持しているかを確認します。数分程度の誤差であっても、セキュリティ ポリシー次第では問題が起こる場合があります。

# 時刻の確認
w32tm /query /status

# ドメインコントローラーとの同期設定を再度実行 (例)
w32tm /resync /rediscover

時刻同期のルートとなるNTPサーバーが正しく動作しているかも併せてチェックしましょう。VM環境ではホスト側との時刻同期との兼ね合いで微妙なズレが起こるケースもあるため、ゲストOSの時刻設定を慎重に管理しておく必要があります。

その他の考慮ポイント

上記の代表的な原因以外にも、いくつかの要因が「RPCサーバーが利用できません」エラーを誘発する場合があります。

グループポリシー (GPO) の影響

GPOでファイアウォールルールやサービスの起動を制御しているケースでは、意図しないポリシー設定によりRPC接続が遮断されることがあります。特に大規模環境やセキュリティが厳格な組織では、セキュリティ強化のために細かくポート制御が行われている可能性があるので注意しましょう。

サードパーティ製セキュリティソフト

ウイルス対策ソフトやエンドポイント保護製品のなかには、リモートからの操作をブロックする機能を持つものがあります。特定のポート通信を監視または遮断する機能がある場合、RPC通信の確立に影響を与えるかもしれません。そういったソフトを運用している場合は、一時的に機能を無効化してみて状況が変わるかを調べると、原因切り分けの大きな手がかりとなります。

イベントビューアーでの詳細確認

イベントビューアーにはエラーや警告に関する詳細ログが記録されています。特に「Application」や「System」ログを調べると、RPC通信に絡む詳細なイベントが残っている場合があります。コンピューター名変更に失敗したタイミングで、関連するイベントIDやエラーメッセージを見つけることができれば、原因を特定しやすくなるでしょう。

具体的な対処のステップ

ここまで紹介したポイントを、より具体的に対処するステップを示します。

1. ネットワーク経路とポートの開放状況を確認

  • 管理端末から対象PCへpingやtracertを行い、そもそも通信経路が存在するかを確認する。
  • WindowsファイアウォールやNW機器でRPC関連ポート（TCP 135, 1024～65535）がブロックされていないか検証する。

2. DNS関連のチェック

  • nslookupコマンドでターゲットホストの名前解決が正しいか確認する。
  • DNSサーバーに誤ったAレコードやPTRレコードがないか再度チェック。
  • DNSフォワーダーや複数DNSサーバーを導入している場合、全てのDNSにおける設定の整合性を確認。

3. Windowsサービスの起動状態を確認

  • 「RPC (Remote Procedure Call)」「Remote Registry」などのサービスを重点的に監視する。
  • サービスが停止している場合は自動起動へ変更し、直ちに開始する。

4. 時刻同期の確認

  • ドメインコントローラーとクライアントPCの時刻が一致しているかを確認する。
  • w32tmコマンドでNTPサーバーや時刻同期のログを取得し、通信エラーがないかをチェックする。

5. イベントビューアーの解析

  • 失敗が発生した時刻周辺のイベントログを洗い出し、エラーIDや警告メッセージから原因を特定する。
  • GPOやセキュリティソフト関連のイベントがあれば、それらを切り分けて考える。

ドメイン環境で安全にコンピューター名を変更するためのポイント

オンプレミスAD環境では、コンピューター名の変更が意外と頻繁に行われるシーンがあります。たとえば、組織改編やパソコンの再配布、新規端末の導入などが代表例です。ただし、AD上でオブジェクト名（コンピューターアカウント）の変更は各種サービスと密接に関連するため、慎重に進める必要があります。

管理者権限の確認

ドメイン管理者、または少なくともコンピューターアカウントの管理権限を持つアカウントでログインしてください。権限が不十分だと、途中で認証エラーが発生する可能性があります。

事前の再起動スケジュール

コンピューター名変更後には再起動が必要です。稼働中のサービスやユーザーの作業状況を踏まえ、変更前にきちんと再起動のスケジュールを立てることが大切です。

PowerShellの実行例

以下は典型的なPC名変更の例です。

# PC名変更コマンド (ローカルコンピューター用)
Rename-Computer -NewName "NewPCName" -LocalCredential (Get-Credential) -Restart

# ドメイン環境で遠隔操作する場合 (ターゲット指定)
Rename-Computer -ComputerName "OldPCName" -NewName "NewPCName" -DomainCredential (Get-Credential) -Force -Restart

実行後は自動的に再起動が行われ、新しい名前がAD上で反映されます。

トラブルシューティングをさらに深めるためのヒント

原因が複数絡んでいる場合、単純な切り分けだけではトラブルが解決しにくい場合もあります。より踏み込んだアプローチとして、以下のような方法があります。

DCdiag / Netdiag コマンドの活用

ドメインコントローラー自身に不具合がある場合、RPC通信とは別の問題が混在しているかもしれません。dcdiagやnetdiagコマンドを使って、ドメインコントローラーの状態を包括的にチェックすると、DNSやレプリケーション、FSMOロールに関する問題がないかを見つける手掛かりになります。

PowerShell Remoting (WinRM) のテスト

PowerShellによるリモート管理には、WinRM (Windows Remote Management) が使われることも多いです。WinRMが正しく構成されていないと、RPC通信だけでなくリモート管理全般でエラーが発生する可能性があります。Enable-PSRemotingコマンドでWinRMを有効化し、ファイアウォールの例外設定が適切か確認しましょう。

# WinRMを有効化
Enable-PSRemoting -Force

# リモートPCへセッション接続
Enter-PSSession -ComputerName <対象ホスト>

もし接続できない場合は、WinRMポート(既定ではTCP 5985, 5986)がブロックされているか、認証設定に問題がある可能性が考えられます。

ネットワークトレースの取得

最終手段として、ネットワークトレース（パケットキャプチャ）を取得し、RPCハンドシェイクがどの段階で失敗しているかを調べるアプローチがあります。WiresharkやMicrosoftのMessage Analyzerなどのツールを用いれば、TCP 135番ポートでの通信確立が成功しているかどうか、応答が返ってきているかどうかを可視化できます。

まとめ：RPCエラー発生時に確認すべきこと

今回紹介したポイントを簡単にまとめると、以下のとおりです。

  1. ネットワークとファイアウォールの設定
  • RPCに必要なポート(TCP 135, 1024～65535)が開放されているか
  • 一時的なファイアウォール無効化で検証
  1. DNS設定の正しさ
  • AレコードやPTRレコードが正しく登録されているか
  • nslookupやipconfig /flushdnsでの動作確認
  1. サービスの起動状態
  • 「RPC (Remote Procedure Call)」「Remote Registry」「TCP/IP NetBIOS Helper」など必須サービスが稼働しているか
  1. 時刻同期とタイムゾーン
  • ドメインコントローラーとクライアント間で時刻のずれがないか
  1. イベントビューアーでのログ確認
  • グループポリシーやセキュリティソフトによるブロック、その他のエラーログの有無を確認

これらを一つずつ丹念にチェックすることで、多くの環境では「RPCサーバーが利用できません」エラーを解消できるはずです。ドメインコントローラーやネットワーク機器との連携を再度見直すことで、スムーズにコンピューター名変更を進められるようになるでしょう。

運用上のコツとアドバイス

最後に、運用現場で役立ついくつかのコツとアドバイスをご紹介します。

PC名変更の前後でイベントを記録する

変更作業の直前と直後でイベントビューアーのログを取得しておくと、何が原因で変更に失敗したかの分析がしやすくなります。特にトラブルシューティングの時間を最小化したい場合は、事前にログを採取しておくと役立つでしょう。

小規模テスト環境を用意する

大規模なAD環境では、ポリシーやセキュリティ設定が複雑です。本格的に導入する前に、小規模のテスト用ドメイン環境でシミュレーションしてみると、実運用に近い手順が試せます。こうしたテスト環境で上手くいかなければ、本番環境でも同じトラブルが起きる可能性が高いので、予防的な対策に役立ちます。

自動化スクリプトの整備

複数台のPC名をまとめて変更するようなシナリオでは、コマンドを一括実行するスクリプトを用意すると効率的です。エラーが出た場合にどのようにリトライするか、ログをどこに出力するかをあらかじめ設計しておくと、トラブルシューティングの効率が向上します。

# サンプル：リストからコンピューター名を変更するスクリプト
# pc_list.csv に旧PC名,新PC名が行単位で並んでいると想定
Import-Csv "C:\Scripts\pc_list.csv" | ForEach-Object {
    $oldName = $_.OldName
    $newName = $_.NewName
    Write-Host "Renaming $($oldName) to $($newName)..."

    Try {
        Rename-Computer -ComputerName $oldName -NewName $newName -DomainCredential (Get-Credential) -Force -Restart
        Write-Host "Success: $($oldName) renamed to $($newName)."
    } Catch {
        Write-Host "Failed: $($oldName) -> $($newName). Error: $($_.Exception.Message)"
    }
}

このようなスクリプトを活用することで、名前変更作業を標準化しやすくなります。ただし、本番環境で実行する際は十分なテストを行い、予期せぬ動作を避けるようにしてください。

まとめ

PowerShellでコンピューター名を変更しようとした際に発生する「RPCサーバーが利用できません」(HRESULT: 0x800706BA) エラーは、ネットワークやDNS、サービスの状態、時刻同期など、さまざまな要素が複雑に絡んでいる可能性があります。本記事で取り上げた確認ポイントと対処方法を順番に検証することで、多くのケースは解決に導けるはずです。特にドメイン環境ではDNSや時刻同期が基盤となるため、日頃から安定した環境を維持することがトラブル予防の鍵となります。

トラブルが解決したあとは、ぜひ定期的なメンテナンスや事前の監視体制を整え、再発防止に取り組んでみてください。これからもシステム運用をスムーズに進めるために、ネットワークと認証の仕組みをより深く理解していくと、さらに安定したAD管理を実現できます。

PowerShell
Active Directory PowerShell Windows RPC エラー対処

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次