【解決事例】リモートデスクトップ接続エラー「DNSキャッシュの古いエントリ」の真の原因はサーバーの時刻ずれだった

発生した問題

Windows Server 2008 R2で構築されたRDS（リモートデスクトップサーバー）ファームに対し、標準のRDクライアント（mstsc.exe）から接続しようとすると、ユーザーから断続的に次のエラーが報告されるようになりました。

「指定されたリモートコンピューターとは別のコンピューターに到達したため、接続を完了できません。この問題は、DNSキャッシュ内の古いエントリが原因である可能性があります。コンピューター名の代わりにIPアドレスを使用して接続してみてください。」

環境構成と初期調査

当該のRDSファームは、Windows Server 2008 R2サーバー3台で構成されており、RD接続ブローカー（Connection Broker）によって各端末への負荷分散と既存セッションへの再接続を制御しています。

エラーが常時ではなく断続的に発生していた点から、ファーム内の特定サーバーに問題があると推測しました。順番に切り分けを行った結果、問題のサーバーを特定し、IPアドレスを直接指定してそのデスクトップへリモート接続しました。

DNS再登録とキャッシュクリアでは解決せず

念のため、まず問題のサーバー側でDNSレコードの再登録を実行しました。

ipconfig /registerdns

続いて数分後、クライアント側でローカルのDNSキャッシュをフラッシュします。

ipconfig /flushdns

しかし、これらの標準的な対処では症状は改善しませんでした。サーバー自体には他に目立った問題もなかったため、Microsoftサポート技術情報の記事（KB2493594：「Windows Server 2008 R2のリモートデスクトップサーバーへのRDP接続が『ローカル セキュリティ機関に接続できません』というメッセージで失敗することがある」）を参照することにしました。

KB記事の対処法：セキュリティレイヤーの変更

KB記事では、RDP接続の暗号化レベルをSSL（認証にTLS 1.0を使用）からRDP Security Layer（RDP独自の、やや安全性の低い暗号化方式）へ下げる方法が提案されています。

この設定は [リモートデスクトップ セッション ホストの構成] → [Microsoft RDP 7.1] → [プロパティ] → [セキュリティ レイヤー] で確認・変更できます。

ただし、弊社環境ではNegotiate（ネゴシエート）方式を採用していました。この方式は、クライアントがTLSに対応していない場合に自動的にRDP Security Layerへフォールバックする仕組みのため、KB記事の対処法は本件には当てはまらない可能性が高い状況でした。

偶然の発見：サーバーの時刻ずれ

調査を進める中で偶然気づいたのが、問題のサーバーの時刻がドメインコントローラーの時刻とずれていたことです。

確認したところ、このサーバー（仮想マシン）が稼働していたVMware ESXiホスト自体の時刻が誤っており、さらにVMware Toolsの設定で「仮想マシンとESX Server間の時刻同期（Time synchronization between the virtual machine and the ESX Server）」オプションが有効になっていました。このため、ホストの誤った時刻がゲストOSへ同期されていたのです。

解決策：ESXi時刻同期の無効化とWindows Timeサービスの再起動

ESXiとの時刻同期を無効化し、Windows Timeサービスを再起動してドメインコントローラーと時刻を同期させました。

net stop w32time
net start w32time

この対応後、ユーザーはRDSファームの全サーバーにエラーなく接続できるようになりました。

補足：ファーム名以外での接続でも同じエラーが表示される

なお、「DNSキャッシュ内の古いエントリが原因である可能性があります」というエラーは、RDSファーム内の特定サーバーに名前を指定して直接接続しようとした場合にも表示されます。この場合、接続ブローカーがクライアントを別のRDホスト（別のDNS名・IPアドレスを持つサーバー）へリダイレクトするため、指定したアドレスと実際に応答したサーバーのアドレスが一致せず、認証試行後にクライアントがエラーを返します。

RDSファームへ接続する際は、必ずファーム名を指定するようにしてください。