株式会社レッツページの宮原です。
今回の依頼は、おっと！少し驚いた内容だったので記事として掲載させて頂きます。
AWSはご存知でしょうか？アマゾンが提供している(A)アマゾン(W)ウェブ(S)サービスです。
つまり、クラウド上に必要に応じ仮想サーバーを立ち上げたりS3ストレージを設けたりとこれからの時代を先取りする画期的なサービスですが
サーバーの管理には基本的にリモートディスクトップが必須となります。今回Windowsファイアウォールの設定で3389のポートを誤って閉じた事による
トラブルです。
【稼働しているWindows2012(R2)のセキュリティーポリシーを変更していたらRDTが切断された！】←あるある事件！
理論上OSのレジストリでファイアウォールを無効化すれば良いだけなので以下手順で作業しました。
ざっくり言うと、作業用サーバーをEC2で新規に立ち上げログインできないOSの（Cドライブ）ボリュームをDドライブとしてアタッチさせ、
レジストリを書き換え元に戻す。これで作業は完了となります。
1、作業が行える権限を割り当てたIDでログインします。
2、コンピューティングのカテゴリからEC2をクリック
3、画面上部「リソース」から〇個の実行中のインスタンスをクリックし、ログインできなくなったインスタンスを停止させる。
目的のインスタンス左のチェックボックスを選択し上部にある「アクション」からインスタンスの状態→停止を押す。
この際、間違えて「終了」を押さないように。インスタンスが削除されます。つまり仮想サーバーが「まるっと」削除される恐ろしい事態になります。。。
4、インスタンスの停止を確認したら同じ画面の下の「説明」タブからルートデバイス右側 例）/dev/sda1←このリンクをクリックします。
5、ブロックデバイスの子画面が表示されるので、この画面を念のためスマホでパシャリと写真を撮りましょう。
6、上記画面のEBS IDのリンクをクリックします。この画面は、以下からも入れます。
コンソール～EC2ダッシュボード～〇個のボリューム【現在使用中のインスタンスがあればEC2の画面上部に表示されているはずです】
7、先ほど写真を確認し、EBS IDと一致するのが6、の画面に存在しているボリュームを選択し画面上部から「アクション」～「ボリュームのデタッチ」を実行します。
これで、仮想サーバーからボリュームが切り離されました。
8、次にEC2ダッシュボードへ移動し、3、の画面（インスタンスの一覧が表示されている画面）を表示させ左上の「インスタンスの作成」を押す。（レジストリ編集用の作業マシーンを作成）
9、作成する仮想一覧（AMI)が表示されるので、WindowsOSを好みで選びます。私はWindows2008が使い慣れているので、
Microsoft Windows Server 2008 R2 Baseを選択しました。ステップ2でインスタンスタイプの選択画面が表示されますが、最低限のスペックで良いので、
上から二番目「t2.micro」で良いでしょう。「確認と起動」を押して次に表示された画面で「起動」を押せば完了です。
※若干Amazon側で利用時間分費用が発生します。
10、インスタンスの一覧画面で先ほど作成したインスタンスを3、の手順で停止させ、新たに作成した作業用マシーンのインスタンスIDの部分をスマホでパシャリ！
その後ECダッシュボードへ移動します。
11、〇個のボリュームをクリックし7、でデタッチしたボリュームを選択し画面上部の「アクション」～「ボリュームのアタッチ」を実行します。
その際、どのインスタンスにアタッチさせるか指定する必要があるので10、で撮影した写真で確認して下さい。
疲れたでしょう？ここでコーヒー飲んで10分休憩( ^^) _U~~
ここまでで概ね40%作業完了です。集中力を高め以下の作業を行いましょう。
12、EC2ダッシュボードへ移動し、〇個の実行中のインスタンスをクリックし、先ほど作業で作成したインスタンスを起動させます。
「アクション」~「インスタンスの状態」~「開始」その後、「接続」ボタンを押してキーペアでリモートディスクトップの
パスワードを取得し、「リモートディスクトップファイルのダウンロード」をクリックし、ディスクトップに保存します。
※もしペアキーを紛失した場合などは以下を参考に！
http://dev.classmethod.jp/cloud/aws/first-login-to-ec2-windows/
13、次に作業用マシーンにリモート接続します。ログインしたマシーンが英語版になっている場合、以下を参考に日本語に変更するか、気合で乗り切りましょう！
https://creativeweb.jp/hosting/ec2-japanese/
http://dev.classmethod.jp/cloud/aws/aws-windows-server-japanese/
14、リモートログイン出来たらコンピュータでローカルディスクDが表示されている事を確認します。
Dに先ほどアタッチしたデータが見えるはずです。もし、見えない場合は、「コントロールパネル」~「管理ツール」~「コンピュータの管理」~「記憶域」~「ディスク管理」で
オフラインディスクがあると思うので、右クリックでオンラインに切り替える。
15、これからDドライブ（RDT接続できないOS）のレジストリを書き換えます。ここから先は、AWSに限らずレジストリ系の障害で起動しないPCやサーバーなどのHDDを別のWindows機へ
接続しレジストリを書き換える事も可能なので流用できる項目です。
DドライブからWindows\System32\config\System ←拡張なしのファイルを探します。
Regeditを起動させ、HKEY_LOCAL_MACHINEを選択した状態でレジストリエディタの「ファイル」~「パイプの読み込み」で先ほどのWindows\System32\config\Systemを開きます。
マウントするキー名を求められますが任意の名前でOKなので、「fix」等わかりやすい名前を付けましょう。
以下にわかりやすいサイト見つけましたので紹介します。
http://www.vwnet.jp/Windows/w8/hive/EditOfflineOSRegistry.htm
レジストリエディタで先ほど読み込んだ「fix」から「ControlSet001」→「 services」→「 SharedAccess」→「 Parameters 」→「 FirewallPolicy 」を開き
DomainProfile、PublicProfile、StandardProfile内のEnableFirewallの設定値を1→0に書き換え、
パイプのアンロードします。
これでファイアウォールの設定が全て無効になったので、本来のインスタンスアタッチすればリモートディスクトップ接続が出来るようになります。
16、ECダッシュボード~〇個の実行中のインスタンス～作業用マシーンを停止させます。「アクション」～「インスタンスの状態」～「停止」
17、ECダッシュボードへ移動し「〇個のボリューム」へ移動後、障害が発生していたボリュームを選択し「アクション」～「ボリュームのデタッチ」を実行します。
これで作業用マシーンにアタッチされていたDドライブの関連付けが外れアンマウントされます。
18、次は、本番機にこのボリュームをアタッチして作業完了となります。
17、でデタッチしたボリュームを再度選択し、「アクション」～「ボリュームのアタッチ」を実行し、表示された画面（Attach Volume）のInstanceの欄に本番機のインスタンスIDを入力し
Deviceの欄に5、で撮影した写真を確認し（ブロックデバイスに記載されている 例）/dev/sda1等入力し「Attach」をクリックします。
後は、本番機のインスタンスを起動させればリモート接続できるので、再度ファイアウォールの設定を手直し後
作業用として作成したインスタンスは、料金が発生するので早めに削除しましょう。
私の場合、作業に2時間ほど要しましたが皆さまはいかがだったでしょうか？
乱雑な記載でわかり辛いかもしれませんが少しでもお役立てるならと思い掲載いたしました。
※もし本文掲載に誤りがある場合誠にお手数ですがお知らせ頂ければ幸いでございます。
定番のコメント→本作業は皆さまの責任下で行って下さい。意図しないトラブルが発生しても当社は責任を負えません。
株式会社レッツページ
代表取締役 宮原義浩
