Azure Virtual Machines へのリモートデスクトップ接続ができない問題を切り分けるには
Windows プラットフォーム サポートの宇田です。
今回は、Microsoft Azure 上の仮想マシン (IaaS) にリモートデスクトップ接続が行えない症状のよくある例と、対象方法などをご紹介できればと思います。
RDP は Azure VM の生命線といっても過言ではありませんので、皆様一度は何かしら体験されているのではないでしょうか。ただ、一言で「リモートデスクトップ接続が出来ない」といっても、実際には様々な要因があり、エラー メッセージや対処方法もそれぞれの状況によって異なります。
この為、まずは発生した事象を正確に把握する事が解決には重要となります。
1. よくある症状と対処策
[症状 1.]
リモート デスクトップはリモート コンピューターに接続できません。次のいずれかが原因です。
1) サーバーへのリモート アクセスが有効にされていない
2) リモート コンピューターの電源が入っていない
3) リモート コンピューターがネットワークで使用できない
リモート コンピューターの電源が入っていること、ネットワークに接続されていること、リモート アクセスが有効になっていることを確認してください。
このメッセージが出て、認証が求められない場合には、メッセージの通りそもそもOS が起動していない場合や、ネットワーク接続に問題がある場合が考えられます。また、仮想マシンを誤ってセーフモードで起動したり、OS 起動に至らず、前回の予期せぬ再起動などの影響を受けて、スタートアップ修復が起動していたりする場合にも本メッセージが表示されます。
対処法は、状況により様々ですので、後述の切り分けを実施してください。
[症状 2.]
ライセンスを提供するためのターミナル サーバー ライセンス サーバーがないため、リモート セッションは切断されました。サーバー管理者に問い合わせてください。
ライセンスを提供するためのリモート デスクトップ ライセンス サーバがないため、リモートセッションは切断されました。
リモート デスクトップの RD セッションホストの役割サービスを追加後、ライセンス サーバーの構築・設定を行わずに、猶予期間 (120 日) が経過すると本メッセージが表示されます。また、それ以前からログオン後にポップアップで残りの日数が表示されているのではないかと思います。
Windows Server では同時に 2 名までが管理接続の為にリモート デスクトップ接続を行う事が可能であり、多くのユーザーが同時にログオンするようなターミナル サーバーやリモート デスクトップ サーバーとしての利用でない限り (3 人以上が同時接続しない限り) リモート デスクトップ サービスの役割を追加する必要はありません。誤って役割を追加してしまった場合などにおいては、本役割を削除する事で本現象が改善します。
なお、このメッセージが表示されている場合であっても、管理接続 (mstsc /admin) での接続は可能です。Azure 管理ポータルから RDP ファイルをダウンロードして接続するのではなく、クライアント コンピューターから、[ファイル名を指定して実行] -> “mstsc /admin” としてリモート デスクトップ接続を起動する事で管理接続を行い、役割の削除を実施してください。
(参考)
リモート デスクトップ サービス接続を削除するリモート デスクトップ ライセンス役割サービスをアンインストールする
https://technet.microsoft.com/ja-jp/library/cc754247.aspx
[症状 3.]
お使いの資格情報は機能しませんでした。(パスワードの再入力要求)
メッセージの通り、パスワードを間違って入力した場合 (ないし忘れた場合) に表示されます。こちらは、ゲスト エージェントが導入済みであれば (既定でチェックされているので、大半の方は導入されています) PowerShell 等からリモートでパスワード リセットが可能です。
具体的な手順などは、以下に記載がありますので、ご参考に頂ければと思います。
(参考)
「Azure仮想マシンにログオンできない！」という悲劇からの生還
https://blogs.technet.com/b/ksasaki/archive/2014/03/21/enable-rdp-or-reset-password.aspx
2. 原因個所の特定
上記の対処で改善しない場合、原因が仮想マシン内の問題なのか、ネットワーク等のインフラ側にあるのかを切り分ける必要があります。簡単にですが、いくつかのパターンをまとめてみましたので、一時切り分けの参考にご利用ください。(拡大してご覧ください。)
それぞれのパターンでの対処手順は以下の通りです。
パターン 1.
すでに上でも書いている通り、ゲストエージェント の VMAccessAgent 拡張を利用してパスワード リセットを行います。詳細は以下をご覧ください。
(参考)
「Azure仮想マシンにログオンできない！」という悲劇からの生還
https://blogs.technet.com/b/ksasaki/archive/2014/03/21/enable-rdp-or-reset-password.aspx
パターン 2.
この場合にありがちな原因として、仮想マシン内で NIC に対して IP や DNS の設定を行っている場合がありますが、これは Azure のお作法的に NG となります。
Azure では手動での再起動や、ホストのメンテナンス等の際に、仮想マシンがホストされている物理サーバーが変わる場合があり、この際に異なる NIC に差し替わったと仮想マシン内では認識されるためです。この場合、仮想マシンとしては Azure の DHCP サーバーから割り振られた設定に戻ってしまいますので、設定済みの DNS サーバーの参照設定が無くなり、DC へ通信できずに認証エラーが発生します。
この為、Azure で DNS の指定を行う場合には、Azure の仮想ネットワーク (VNET) にて、DNS サーバーの指定を行う必要があります。また、IP を固定したい場合には、Reserved IP という Azure で用意された機能を利用してください。
以下のように [仮想ネットワーク] -> [構成] にて、dns サーバーを指定します。
(参考)
VM 用の静的内部 IP アドレスを設定する
https://msdn.microsoft.com/ja-jp/library/azure/dn630228.aspx
パターン 3.
こちらの症状の場合には、3389 のポートが LISTEN していない場合や、Firewall でブロックされているといった、通信の問題の場合が考えられます。単純に リモートデスクトップ 接続を OS の設定で禁止してしまった場合などは、先にも紹介した VMAccessAgent で修復が可能です。
一方、アンチウイルス製品をインストールしたら通信できなくなった (3389 がブロックされた) などの場合、残念ながら有効な対処策がありません。残念ですが、VHD ファイルをダウンロードして頂き (注: Azure データセンターから出ていくデータには課金が発生します。) ローカルの Hyper-V 環境などでポート 3389 を解放してから、再度アップロードして起動しなおしてください。
VHD のダウンロード・アップロードは、AzCopy や Azure PowerShell、各種ストレージ エクスプローラをご利用ください。
(参考)
AzCopy コマンド ライン ユーティリティの概要
https://azure.microsoft.com/ja-jp/documentation/articles/storage-use-azcopy/
Windows Server VHD の作成と Azure へのアップロード
https://azure.microsoft.com/ja-jp/documentation/articles/virtual-machines-create-upload-vhd-windows-server/
Windows Azure Storage Explorers (2014)
https://blogs.msdn.com/b/windowsazurestorage/archive/2014/03/11/windows-azure-storage-explorers-2014.aspx
また、リモート デスクトップの機能のみがハングしていたり、正常に動作していなかったりという場合も考えられますので、管理ポータルから仮想マシンの再起動を行って改善されるかもあわせてご確認下さい。
パターン 4.
Ping にすら応答しない場合には、OS 自体がハングアップしているか、仮想マシン内のネットワーク周りで問題が生じている可能性が高いかと思われます。一旦、管理ポータルから仮想マシンを再起動して改善されるかを確認してください。
Azure 外や、Azure 内の異なる仮想ネットワーク (ないしクラウド サービス) 上からの Ping (ICMP) は応答しませんので、必ず同一仮想ネットワーク内の他の仮想マシンから Ping に応答があるかを確認してください。
パターン 5.
複数の仮想マシンに接続できない等の場合、ネットワーク接続全体に何らかの問題が生じている可能性が疑われます。エンタープライズでご利用の場合には、S2S の VPN や Express Route などの形態で接続されている場合もあるかと思いますので、設定等を改めてご確認頂ければと思います。(ネットワークの場合には要因が様々考えられますので、全てを網羅できないため今回は割愛させて頂きます。)
パターン 6.
仮想マシンがそもそも起動できない場合には、CPU のクォータ制限 (デフォルトでは 20 コア等となっています。) を超過していないかをご確認下さい。なお、CPU に限らず Azure の各種クォータはサポートにご連絡頂ければ上限の引き上げが可能です。
詳しくは Azure サポートチームのブログをご覧ください。
(参考)
Microsoft Azure のクォータ増加について
https://blogs.msdn.com/b/dsazurejp/archive/2013/10/22/windows-azure-quota-increase.aspx
例: クォータが 20 コアの場合
4 コアの仮想マシンを既に 4 台起動している状態で、8 コアの仮想マシンを起動しようとした場合には、合計で 4x4 + 8 = 24 コアとなりますので、起動できません。
以上が、Azure 上の仮想マシンに リモートデスクトップ接続できない場合のよくある原因と対処策になります。
上記のパターンで対処が出来ない場合、以下のページでもトラブルシューティングに役立つ情報がまとまっていますので、こちらもあわせてご確認下さい。
Windows ベースの Azure 仮想マシンへのリモート デスクトップ接続に関するトラブルシューティング
https://azure.microsoft.com/ja-jp/documentation/articles/virtual-machines-troubleshoot-remote-desktop-connections/
リモート デスクトップ接続がある日突然出来るなくなる現象は、Azure をご利用の皆様が、日々多く直面する問題だと思いますので、少しでも解決のお役に立てば幸いです。