トップ > AWS EC2 > Amazon EC2RescueでEC2 Windows Server instanceを救出する

Amazon EC2RescueでEC2 Windows Server instanceを救出する

AWS EC2
記事タイトルとURLをコピーする

ご挨拶

Amazon EC2Rescue is now available！
とのことで、いきなり使ってみましたEC2Rescue。

ご挨拶が遅れましたが、お久しぶりです。
3月からコンサルティング課に所属となりました佐竹がんもです。

配属に伴い「コンサルって何するんだろう？」そう自問したところ
「お客様に喜んで頂くことだろう」
と思いました。

ですので、私は今からWindows Server instanceを救出して、お客様に喜んで頂くことにしました。
早速、Amazon EC2Rescueの使い方をご説明しましょう。

Amazon EC2Rescueとは

Amazon EC2Rescueは、Amazon EC2 Windows Serverインスタンス上で動作する便利で簡単なGUIベースのトラブルシューティングツールです。これはオペレーティングシステムレベルの問題をトラブルシュートするために利用でき、また、詳細なログ及び構成ファイルを収集して解析するためにも利用可能です。
このツールは2017年3月10日(金)よりAWSから提供が開始されています。

Amazon EC2RescueでWindows Server instanceを救出する

これより、EC2Rescueを使った実際のGUIオペレーションを紹介いたします。流れは以下の通りです。

  1. 【準備1】EC2 Windows Serverを壊す
  2. 【準備2】Amazon EC2Rescueを動かすInstanceを構築する
  3. EC2Rescueを実行し、対象のDiskをロードする
  4. EC2RescueでロードしたDiskにCapture logsを実行する
  5. EC2RescueでロードしたDiskにDiagnose and Rescueを実行する
  6. リモートデスクトップ接続の動作確認

【準備1】EC2 Windows Serverを壊す

壊すといっても、設定を少し変更するだけです。以下の手順でリモートデスクトップ接続をできなくします。ですが、これを行うと今後のメンテナンス作業に支障をきたす場合がほとんどのため、基本的には「絶対にやらないでください」とお伝えしてもいいレベルの操作です。

まずは準備のために、EC2Rescueを適用する対象として、EC2 Windows Serverを1つ用意しました。今回は、Windows_Server-2016-English-Full-Base-2017.01.11 (ami-834e32e4)を利用しています。これをLaunchして、リモートデスクトップ接続を行った後、以下の画面より「Don’t Allow Connections To This computer(このコンピューターへの接続を許可しない)」のラジオボタンを選択して適用します。

この設定を行うと、リモートデスクトップ接続のコネクションが直ちに切断され、このEC2 Instanceに対してのリモートデスクトップ接続ができなくなります。
画像の通り、セッションが失われてしまいます。

リモートデスクトップ接続をできなくしたら、EC2 Instanceは停止しておきます。
これで準備は完了です。

【準備2】Amazon EC2Rescueを動かすInstanceを構築する

EC2Rescueを動かすためのInstanceを構築します。今回も、Windows_Server-2016-English-Full-Base-2017.01.11 (ami-834e32e4)を利用しています。通常通りInstanceをLaunchした後、リモートデスクトップ接続を行い以下のページからEC2Rescueの実行ファイルを取得します。

How can I use EC2Rescue to troubleshoot and fix common issues on my EC2 Windows instance?
https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2rescue-windows-troubleshoot/

このURL先のページに、
Download EC2Rescue at https://s3.amazonaws.com/ec2rescue/windows/EC2Rescue_latest.zip.
と記載がありますので、このzipファイルをs3からダウンロードします。 zipファイルを適当な場所に解凍します。 解凍すると、画像の通りのファイルが展開されます。今回実行するのはこのうちの「EC2Rescue.exe」です。これで準備が整いました。

EC2Rescueを実行し、対象のDiskをロードする

もしもの場合に備え、まずは救出したいInstanceを停止させた状態で、AMIもしくはEBS Snapshotを取得することを推奨いたします。
その後、救出したいInstance、今回は【準備1】で作成したInstance(Name:rescue_Crushed)から、CドライブのEBS Volumeをデタッチします。Cドライブをデタッチするときは、必ずInstanceを停止してから行ってください。デタッチしたVolumeを、【準備2】で作成したInstance(Name:rescue_RescueInstance)にアタッチします。アタッチした後、正常にドライブが認識されているかDisk Managementで確認を行います。 画像の、「Disk 1 Basic 30.00GB Offline」と表示されているDiskが今回の救出対象です。このまま、オフラインで作業を行います。
次に、EC2Rescue.exeを実行します。 ライセンスに対して同意が必要となりますので、「I Agree」を押下して進みます。

「Next」を押下して先に進みます。

OfflineでアタッチされているDiskに対して解析/救出を行いますので、2つ目の「Offline Instance」を押下します。
Disk 1が選択されていることを確認し、「Next」を押下します。
確認画面がでますので「Yes」を押下します。
ロードが成功した画面が表示されますので、「OK」を押下します。

EC2RescueでロードしたDiskにCapture logsを実行する

現在の設定を抜き出すために、Capture logsを実行します。3つのメニューのうちの、一番下のものがそれにあたります。
Capture logsを選択し、作業を進めます。

「Collect...」を押下します。

「レジストリデータなどが取得されますが実行を許可しますか？」という内容のポップアップ画面が表示されるので、「Yes」を押下します。

適切なフォルダとファイル名で保存を行います。今回は、デスクトップに保存を行いました。

プログレスバーが表示され、処理が実行されます。この処理の完了までは、t2.microで1分もかかりませんでした。

ログの収集が完了するとこの画面が表示されます。この後は右下の「Finish」を押下し、一度EC2Rescueを終了させる必要があります。

「OK」を押下し、EC2Rescueを終了します。

なお今回は、ここで取得したデータの一部を確認してみました。

デスクトップに配置されたファイルを解凍した後、レジストリエディタを起動し、[RegistryHives]フォルダの[SYSTEM]を読み込みます。

HKEY_LOCAL_MACHINE\SYSTEM_crushed\ControlSet001\Control\Terminal Server
の中にあるfDenyTSConnectionsが[1]であることを確認しました。これはリモートデスクトップ接続が利用できない設定となっていることを示しています。

EC2RescueでロードしたDiskにDiagnose and Rescueを実行する

「EC2Rescueを実行し、対象のDiskをロードする」の項目に記載しました作業を再度行って頂き、以下の画面まで進めます。

最上部にある、「Diagnose and Rescue」を実行します。これが救出の作業になります。

Diagnose and Rescueを実行すると、図の通りにチェック項目がざっとリストアップされ、どこに問題があるか表示されます。今回はリモートデスクトップ接続ができない状態ですので、画像真ん中にある赤い×印となっている「Remote Desktop Connections」が対象の問題となります。Statusは「Disable」でDescriptionには「Remote Desktop Connections should be enabled to allow access.」とあります。
また、Windows Firewallの設定にも3つの黄色い△!マークがついていますが、これは「Don’t Allow Connections To This computer(このコンピューターへの接続を許可しない)」を設定するとFirewallまで閉じられてしまうためで、これもあわせて解除する必要があります。
「Next」を押下して進めます。

「Detected possible issues」として、検出された問題が列挙されます。左端にチェックボックスが出てきますので、今回解決したい問題に対してチェックを入れます。今回の作業では全てのチェックボックスがチェックされている状態にしました。左下の「Select All」を押下すると全てのチェックボックスにチェックが可能です。
「Next」を押下して進めます。

「Rescue」を押下します。

確認画面がポップアップされますので、「OK」を押下して処理を実行します。

処理が正常に完了した結果が表示されます。「Next」を押下します。

ここで、先ほどと同様の「Done」が表示されますが、Audit logが「View⇒Show log」で確認可能とのことなので、確認を行いました。

EC2Rescueのログが確認できますので、これを範囲選択⇒Ctrl+Cでコピーし、監査用のログとして手元に残すことが可能です。
2017-03-11 05:18:36.129Z Changing Remote Desktop fDenyTSConnections setting to False...
2017-03-11 05:18:36.129Z Changing Remote Desktop fDenyTSConnections setting succeeded.
2017-03-11 05:18:36.130Z Obtaining Remote Desktop fDenyTSConnections setting...
2017-03-11 05:18:36.130Z Obtaining Remote Desktop fDenyTSConnections succeeded: 0

なお、上記の引用の通り、このログの中にはレジストリの値 fDenyTSConnections をFalse(0)に書き換えた記述が出力されていました。最後に「Obtaining Remote Desktop fDenyTSConnections succeeded: 0」と、「0」に書き換わったことが確認されています。

リモートデスクトップ接続の動作確認

最後に【準備1】で作成したInstance(Name:rescue_Crushed)にて動作確認を行います。オフラインとなっている、元CドライブのDiskを「Name:rescue_RescueInstance」からデタッチします。デタッチしたVolumeを、「Name:rescue_Crushed」にアタッチします。

アタッチするときのDeviceは「/dev/sda1」としてください。Windows ServerはCドライブはこの記述である必要があります。
アタッチが完了したら、InstanceをStartします。

無事にリモートデスクトップ接続が回復し、ログオンすることが確認できました。

EC2RescueではEC2Configを使ったパスワードリセットも可能

WIndowsのログインパスワードを忘れてしまった！ そんなときにもEC2Rescueが活躍します。
以下の画面は、別のEC2 Windows Server 2012 Instanceに対してEC2Rescueを実行した画面です。Windows Server 2003 - 2012まではEC2ConfigサービスがインストールされてAMIが出荷されていました。このEC2Configサービスの機能のうちの1つである「Administratorのパスワードをリセットする」機能を、EC2Rescueで実行できます。そうすれば、今一度マネジメントコンソールから「Get Windows Password」でAdministratorのパスワードが取り出せます。

上図の赤枠がその機能です。パスワードをリセットしたくない場合は、この処理が行われないよう、チェックボックスのチェックをつけないようにしてください。

まとめ

Amazon EC2RescueでWindows Server instanceのリモートデスクトップ接続を復活させ、救出することができました！
今までであれば、救出用のInstanceにドライブをアタッチした後は、Diskをオンラインとし手作業でレジストリエディタにて編集作業が必要であり、またドライブをCドライブに戻す作業も

bcdedit /store <Drive Letter>:\boot\bcd /set {default} bootstatuspolicy ignoreallfailures

が必要など、煩雑な作業が必要でしたが、これでかなり簡単に楽に救出ができるようになりました！
問題となっている個所のリストアップのGUIは見やすく、また復旧できなくとも、取得したログをAWSサポートの問い合わせに使うことで解決までの時間を短縮可能と思われます。
また、EC2RescueではDHCPを有効化することも可能ですので、「VMImportしたときにDHCPを有効にするのを失念していた」というときにも、その対処に利用が可能そうです。
あまり頻度は多くはないシチュエーションかもしれませんが、Instanceにつなげなくなった場合はEC2Rescueで救出作業&調査ログの取得を！

ここまでお読みいただきありがとうございました。

佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ

営業部カスタマーサクセス課所属。AWS資格12冠。2010年1月からAWSを利用してきました。2021 Japan APN Ambassador /2020-2021 APN ALL AWS Certifications Engineer。AWSのコスト削減、最適化を得意としています。