Windows Server 2012 / 2012 R2で、昨日まで使えていたリモートデスクトップ（RDP）が突然つながらなくなる…。ポート開放やTermService稼働、SFC/DISMまで試しても直らない場合、RDPリスナー設定（RDP-Tcp）の破損が原因のことがあります。本記事では切り分け手順と、実際に復旧したレジストリ復元手順を具体的に解説します。
起きていることを整理：Windows Server 2012 / 2012 R2でRDPが突然接続できない
現場で多いのが「特定のクライアントごとに1台ずつ立っているWindows Server 2012 / 2012 R2で、ある日突然RDPが接続不可になった」というパターンです。OS自体は起動していて、アプリや共有フォルダは動いているのに、RDPだけが死んだように見える。しかも、Windowsファイアウォールのポート許可やRemote Desktop Services（TermService）サービス稼働を確認しても改善しない──こうなると、単なるポート閉塞ではなく「RDPの待ち受け（リスナー）構成そのもの」が壊れている可能性が上がります。
この記事では、まず“どこで止まっているか”を短時間で切り分け、最後に採用された根本解決として、正常サーバーからのRDP-Tcpレジストリキー復元による復旧手順を、コピペできるコマンド付きでまとめます。
最初の10分でやる切り分け：ネットワーク問題か、サーバー待ち受け問題か
RDPがつながらないときに重要なのは、「クライアント→サーバー間の通信が届いていない」のか、「通信は届いているがサーバー側がRDPとして受け取れていない」のかを分けることです。ここを外すと、ファイアウォール・サービス・更新プログラムを行ったり来たりして時間が溶けます。
PowerShellで疎通確認：Test-NetConnectionでTCP 3389（または変更ポート）を検査
まずはクライアント側（または同一ネットワーク上の別PC）から、RDPポートにTCP接続できるかを確認します。Windows Server 2012 R2/Windows 8.1以降ならPowerShellのTest-NetConnectionが定番です（Windows Server 2012無印の場合、環境によってはWMF導入が必要です。その場合は後述の代替手段を使います）。
既定ポート（3389）を確認する例
Test-NetConnection -ComputerName "<IPアドレス>" -CommonTCPPort RDP -InformationLevel Detailedポートを変更している場合の例
Test-NetConnection -ComputerName "<IPアドレス>" -Port <ポート番号> -InformationLevel DetailedポイントはTcpTestSucceededの真偽と、失敗時の挙動（タイムアウトか、拒否か）です。結果の読み方を、実務で使う観点で表にします。
| Test-NetConnectionの挙動 | 意味（何が起きているか） | 主な原因 | 次にやること |
|---|---|---|---|
| TcpTestSucceeded : True | TCPレベルでポート到達できている（少なくとも“入口”は開いている） | RDPの認証/NLA、暗号化設定、証明書、セッション制限、ユーザー権限などアプリ層の問題 | イベントログやRDP設定の確認、RDP-Tcp構成の整合性チェック |
| タイムアウト（応答が返らない） | 途中でパケットが落ちている／遮断されている可能性が高い | NW機器・上位FW・ACL、Windowsファイアウォール、経路問題、NAT/ポートフォワード設定の不整合 | サーバー側で待ち受け確認→FWのログ/ルール確認→経路/ACL確認 |
| 即座に拒否（Connection refused相当） | サーバーに到達しているが、そのポートで待ち受けがない/拒否している | TermServiceが実は受け付けていない、RDPリスナーが壊れている、ポート番号の不一致 | サーバー側でnetstat・レジストリ・サービス状態を重点確認 |
Test-NetConnectionが使えない場合の代替
Windows Server 2012無印などでTest-NetConnectionがない場合は、次のいずれかで同等の“TCPが開くか”を確認できます。
- 別PCから PowerShell（新しめ） でTest-NetConnectionを実行（検査はクライアント側で行うのが基本）
- PortQry などのポート診断ツールを利用
- 一時的にtelnetクライアントを有効化して接続（※確実な判定には向かないが目安にはなる）
サーバー側で必ず確認するポイント
クライアント側の疎通で「拒否っぽい」「タイムアウトっぽい」が見えたら、次はサーバー側です。RDPが突然つながらないときは、サービスが動いているだけでは不十分で、実際に“待ち受けソケットが開いているか”を見ます。
待ち受け確認：netstatでRDPポートがLISTENINGか
サーバーのコンソール（iLO/DRAC、仮想基盤コンソール、現地作業など）でログオンできる前提で、まずは待ち受けを確認します。
netstat -ano | findstr ":3389"ポート変更している場合は3389を変更後ポートに置き換えます。LISTENINGが出ない、あるいは別プロセスが握っている場合、RDPがつながらない説明がつきます。
サービス確認：TermServiceがRunningでも“待ち受け”が壊れることがある
powershell -NoProfile -Command "Get-Service TermService | Format-List Status,Name,DisplayName"TermServiceがRunningでも、RDPリスナー（RDP-Tcp）が壊れていると、ポートを開けられず結果的に接続できません。「サービスは動いているのにRDPが死んでいる」状況はここで起きます。
RDP許可フラグ：fDenyTSConnectionsが0か
意外と多いのが、運用中の設定変更やポリシー適用で、RDP許可フラグが反転しているケースです。
powershell -NoProfile -Command "(Get-ItemProperty 'HKLM:\System\CurrentControlSet\Control\Terminal Server').fDenyTSConnections"値が0なら許可、1なら拒否です。1になっているなら、原因を押さえた上で0に戻します。
ポート番号の整合性：RDP-TcpのPortNumberを確認
「待ち受けポート変更（レジストリ変更）を試したが改善しない」ケースでも、変更が想定通り反映されていない、10進/16進の解釈を誤った、グループポリシーに上書きされた、などが起こりえます。まずは現在値を“読み出して”確認します。
powershell -NoProfile -Command "(Get-ItemProperty 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp').PortNumber"変更ポートで運用している場合は、サーバー側の待ち受け・Windowsファイアウォール・上位FW/NAT・クライアントの接続指定（ホスト名:ポート）が全て一致している必要があります。
| チェック項目 | 見るべき場所 | 確認例 | よくあるミス |
|---|---|---|---|
| サーバー待ち受けポート | RDP-TcpのPortNumber / netstat | PortNumberが想定値、netstatでLISTENING | 設定したつもりが別キー、再起動未実施 |
| Windowsファイアウォール | 受信規則（Remote Desktop） | 想定ポートを許可 | プロファイル違い（Domain/Private/Public） |
| 上位FW/NAT | 拠点FW/クラウドSG | 外→内のポートフォワード | 複数サーバーで同一公開IP、変換ポートの衝突 |
| クライアント指定 | mstsc / 接続先 | hostname:port | ポート付け忘れ、古いRDPファイルを使い回し |
症状が揃うと“RDPリスナー構成の破損”が疑わしい
ここまでの確認で、次のような状況が揃うなら、RDPリスナー（RDP-Tcp）の構成破損が濃厚です。
- Windowsファイアウォールや上位FWの設定は問題ない（他のサーバーは同条件でつながる）
- TermServiceは起動しているのに、RDPポートがLISTENINGにならない、または挙動が不自然
- ポート変更をしても症状が変わらない
- sfc /scannow、DISM、Windows Updateなど“ファイル破損系の修復”をしても改善しない
RDPの待ち受け設定は、単なる「ポート番号」だけでなく、暗号化やNLA、証明書バインドなど複数の要素が絡みます。これらがレジストリ上で部分的に欠損したり、異常値になったりすると、サービスが動いていてもリスナーが正しく立ち上がらず、結果としてRDPが突然つながらなくなります。
採用された根本解決：RDP-Tcpキーを“正常サーバーの値”で復元する
最終的に復旧した方法はシンプルで、正常な同一OSバージョンのサーバーから対象レジストリキーをエクスポートし、問題サーバー側で同キーを削除 → バックアップをインポート（復元）する手順です。復元後すぐにRDP接続が復活するケースがあります。
対象キー
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcpこのキーに何が入っているのか（復元が効く理由）
RDP-Tcp配下には、RDPリスナーの動作に関わる設定がまとまって入っています。環境差はありますが、代表的な値は次の通りです。
| 値の例 | 役割 | 壊れると起きやすいこと | 備考 |
|---|---|---|---|
| PortNumber | RDP待ち受けポート番号 | 想定外ポートで待ち受け、または待ち受け失敗 | 変更運用なら要再設定 |
| SecurityLayer | RDPのセキュリティ層（TLS/RDP Securityなど） | 接続開始直後に切断、内部エラー | 環境によってはポリシーで上書き |
| UserAuthentication | NLA（ネットワークレベル認証）の挙動 | 認証前に弾かれる、古いクライアントで失敗 | 切り分けで一時的に変更することも |
| SSLCertificateSHA1Hash | RDPに紐づく証明書の指定 | 証明書不整合でハンドシェイク失敗 | 独自証明書運用では要注意 |
つまり、RDP-Tcpの中身が中途半端に壊れていると「サービスは動いているのにRDPが受けられない」が起きます。逆に言うと、正常サーバーの同キーで“土台”を戻すことで、リスナーが復元されやすいのです。
作業前の注意点（ここを守ると安全に進められる）
- 必ずバックアップ：最低でも当該キーのエクスポート。可能ならシステム状態バックアップも検討します。
- 同じOSバージョン（できれば更新レベルも近い）の正常サーバーから取得します。異なる世代のキーを混ぜないのが鉄則です。
- コンソールアクセス手段を確保：作業中にRDPが使えない前提で、iLO/DRAC/VMコンソール等で戻れる状態にします。
- 変更管理：復元でカスタム設定（ポート変更・証明書・NLAなど）が上書きされる可能性があります。現状値を控えます。
手順：正常サーバーでRDP-Tcpキーをエクスポート
正常なWindows Server 2012 / 2012 R2（同一OS）で、管理者権限のコマンドプロンプトまたはPowerShellを開き、キーを.regとして保存します。
reg export "HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" "C:\Temp\RDP-Tcp_healthy.reg" /y作成した.regファイルを、問題サーバーへ安全な手段でコピーします（共有フォルダ、管理用ファイル転送、コンソール経由など）。
手順：問題サーバーで（バックアップ→削除→復元→再起動）
問題サーバー側でも、まず現在の状態をバックアップしておきます。原因追跡や差分比較、ロールバックに役立ちます。
1）問題サーバーの現状キーをバックアップ
reg export "HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" "C:\Temp\RDP-Tcp_before.reg" /y2）TermServiceを停止（可能なら）
net stop TermService停止できない/依存関係で拒否される場合でも、コンソール作業が可能であれば次へ進められます。運用状況に合わせて判断してください。
3）対象キーを削除（または名前変更）
確実なのは削除ですが、心理的に不安なら「RDP-Tcp_old」のようにリネームして退避してからでも構いません。コマンドで削除する場合は次の通りです。
reg delete "HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /f4）正常サーバーのキーをインポート
reg import "C:\Temp\RDP-Tcp_healthy.reg"5）TermServiceを起動（または再起動）
net start TermServiceサービス再起動で不安定な場合や、他の関連コンポーネントの反映が疑わしい場合は、メンテナンス可能なタイミングでサーバー再起動を行うと確実です。
復元後の確認：RDPが戻ったかを“見える化”してチェック
復元後は、次の順でチェックすると原因の取り違えを防げます。
- サーバー側で待ち受け（LISTENING）が立ったか（netstat）
- クライアント側からTCP到達できるか（Test-NetConnection）
- 実際にmstscでログオンできるか
サーバー側：待ち受け確認
netstat -ano | findstr ":3389"クライアント側：疎通確認
Test-NetConnection -ComputerName "<IPアドレス>" -CommonTCPPort RDP -InformationLevel Detailedクライアント側：ポート変更している場合の接続指定
mstsc /v:<ホスト名またはIP>:<ポート番号>復元後にやりがちな落とし穴（特にポート変更運用）
RDP-Tcpを正常サーバーから復元すると、環境によってはポート番号やNLA設定、証明書バインドが“正常サーバー側の設定”に寄ります。復旧した直後に「つながった／つながらない」がブレるのはここが原因のことが多いです。
| 落とし穴 | 症状 | 確認ポイント | 対処 |
|---|---|---|---|
| ポートが3389に戻った | 変更ポートでは到達しない | PortNumberとnetstat | ポートを再設定し、FW/上位FWも合わせる |
| NLA設定が変わった | 認証前に弾かれる/古い端末だけ失敗 | UserAuthentication | 一時的にNLAを緩めて切り分け→最終的に安全側へ戻す |
| 証明書運用の差 | TLS関連で失敗、警告が増える | SSLCertificateSHA1Hash | 正しい証明書を再バインド、または再生成 |
| FWプロファイル違い | 社内からはOK/外部からNGなど | Domain/Private/Public | 適用プロファイルを見て受信規則を整える |
それでも直らない場合の追加チェック（深掘り用）
RDP-Tcp復元で多くは改善しますが、環境要因が重なっていると別のボトルネックが残る場合もあります。深掘りが必要になったときの優先度が高い項目をまとめます。
イベントログ：RDP関連の手がかりを拾う
RDPが拒否される、あるいは握手途中で切断される場合、イベントビューアーにヒントが残ることがあります。次の系統を中心に見ます。
- システムログ（サービス起動失敗、ポート競合、TLS関連）
- アプリケーションとサービスログ配下のターミナルサービス関連ログ
- セキュリティログ（認証失敗、アカウントロックアウト）
「いつから起きたか（更新適用日、再起動日、設定変更日）」と突き合わせると、原因が絞りやすくなります。
RDPが“開いているのに入れない”ときの典型
- ユーザー権限：対象ユーザーがRemote Desktop Usersに入っていない／ローカルポリシーで拒否
- アカウントロック：パスワード変更後に旧資格情報で試行が続きロック
- NLA/CredSSP：古い端末や一部クライアントだけ失敗
- セッション枯渇：既存セッションが残り、新規接続が通らない（コンソールから切断・ログオフで回復）
ポート競合：別プロセスが同ポートを握っていないか
netstatでLISTENINGが出ていても、PIDがTermServiceではない場合があります。PIDからプロセスを特定し、競合を解消します。
tasklist /FI "PID eq <PID>"再発防止：復旧を“属人化”させない運用のコツ
今回のような「RDPが突然つながらない」系の障害は、復旧できても再発すると同じ時間を奪われがちです。運用で効く対策を、効果が高い順に紹介します。
RDP-Tcpキーの“平常時バックアップ”を取っておく
今回の復旧手順は、正常サーバーが存在することが前提でした。単一サーバー運用や、同一構成のサーバーが少ない環境では、平常時にキーをバックアップしておくと復旧が速くなります。
reg export "HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" "D:\Backup\RDP-Tcp_baseline.reg" /yバックアップはサーバー内だけでなく、管理用の安全な保管場所（アクセス制御されたファイルサーバーなど）にも置いておくのがおすすめです。
監視：管理端末からRDPポートを定期チェックして“気付ける”ようにする
RDP断はユーザーからの申告で初めて気付くことが多い障害です。管理ネットワーク上の監視端末から、日次/数時間ごとにポート監視するだけでも検知が早まります。
# 例：監視用（管理端末側）で実行するイメージ
Test-NetConnection -ComputerName "<対象サーバーIP>" -CommonTCPPort RDP -InformationLevel Quiet| 監視の観点 | 見るもの | 閾値/判断 | 備考 |
|---|---|---|---|
| TCP到達性 | ポート3389（または変更ポート） | Falseなら障害疑い | 上位FW変更でも落ちる |
| サービス稼働 | TermService | Stopped/再起動ループを検知 | サーバー内監視が必要 |
| 構成差分 | RDP-Tcpキー | 想定外変更を検知 | 構成管理ツールが有効 |
Windows Server 2012 / 2012 R2は“延命”より移行計画が重要
Windows Server 2012 / 2012 R2はサポート終了世代であり、更新や暗号化要件の変化、クライアント側のRDP実装変更など、運用リスクが上がりやすい土壌があります。今回のようなRDPトラブルを機に、後継OSへの移行や、管理経路の二重化（RDP以外の管理手段確保）を計画しておくと安心です。
まとめ：RDPが突然つながらないなら、RDP-Tcp復元が“最後の一手”になり得る
Windows Server 2012 / 2012 R2でRDPが突然つながらなくなり、ファイアウォールやTermService、SFC/DISMでも直らない場合、RDPリスナー構成（RDP-Tcp）の破損が原因になっていることがあります。まずTest-NetConnectionで到達性を切り分け、サーバー側で待ち受けとレジストリ値の整合性を確認した上で、正常サーバーからRDP-Tcpキーを復元することで、短時間で復旧できるケースがあります。
レジストリ操作は強力ですが、その分だけ慎重さも必要です。バックアップとコンソールアクセスを確保し、復元後はポートやNLAなどの運用設定が意図通りかを必ず確認してください。
コメント