sorta kinda...

主にAWS関連ですが、これに限らずいろいろ勉強したことや思ったことを書いていきます。

Windows のグループポリシーでシャットダウンスクリプトが実行されない場合がある?

日々 Windows 運用に悩んでいます、那須です。

EC2 で動いている Windows Server の Windows Update 等の運用で OS 再起動前にサービスを落としたり必要なプロセスを落としたりすると思いますが、皆さんどうされてますか? Windows のシャットダウンで自動で行われるサービス停止をアテにする人は少ないかもしれませんね。 よくあるのは、グループポリシーでシャットダウン時に明示的にスクリプトを実行するように設定することでしょうか。 ↓こんな画面のやつです。
f:id:nasrinjp1:20190416003535p:plain

とある要件で、サービスを確実に停止してから OS をシャットダウンしたり再起動したりする、というのがありましてグループポリシーのシャットダウンスクリプトでいろいろテストしてみました。 思わぬ結果が出たので、共有しておこうと思います。

 

思わぬ結果?

ハードウェアに詳しい方なら当然の結果なのかもしれませんが、私はハードウェアに全く詳しくないので個人的には面白い結果になったと思っています。 グループポリシーのシャットダウンスクリプトですが、シャットダウンの定義というかどういう場面でトリガーされるのかが気になっていくつかパターンを試してみました。

問題なくシャットダウンスクリプトが実行される例

  • OS 内から停止
  • セッションマネージャから再起動
  • RunCommand で WindowsUpdate

シャットダウンスクリプトが実行されない例

  • AMI 作成時に再起動チェック
  • コンソールから再起動/停止

 

どこからシャットダウン指示を出すかで動作が違う?

結果を見る限り、OS 内からシャットダウンを実行した場合はシャットダウンスクリプトが実行されて、OS 外(AWSコンソール等)からシャットダウンを実行した場合はシャットダウンスクリプトが実行されない、という動作をしているように見えますね。 セッションマネージャは ssm-user ユーザが OS 内から、RunCommand は SSM エージェントが OS 内部からコマンド送信しています。 一方、AMI 作成時の再起動オプションや、AWS コンソールからの再起動や停止は OS の外からシャットダウン命令を出しているのでそう思いました。

 

同じ言葉でも動作は厳密には違うっぽい

なんとなく AMI 作成時に再起動オプションをつけていて、サービスやプロセスの停止に長時間かかるような場合だとマズそうだなというのが見えてきました。 DB がないのであればほとんどの場合はそれでも大丈夫だと思いますが、一部のファイルの中身がなくなった!なんて例も 1 度だけですが経験しているので、確実にサービスやプロセスを止めてからバックアップを取りたい場合は、OS 内から当該サービス等を止めてから AMI 作成やスナップショット作成の API をコールするスクリプトを実行すると安心ですね。 もっといい方法があるような気がしますが、今時点では安心を買うにはこうするしかなさそうです。

そんなややこしいことしなくてももっと簡単もしくはシンプルにできるよ!って方がいれば教えていただけると嬉しいです!