IaaSクラウド上でWindows Server 2016のWindows Updateはハイリスク？：山市良のうぃんどうず日記（105）（1/3 ページ）

本連載第96回「Windows UpdateとIaaSクラウドは忍耐が試される？」では、クラウド（Microsoft Azureなど）上の仮想マシンでWindows Updateやシャットダウンを行う場合の注意点（特に、Windows Server 2016）を取り上げましたが、2017年9月の定例更新で過去最大（筆者史上）の忍耐を強いられることになりました。本連載の過去記事と重複する部分もありますが、トラブルシューティングの参考になるかもしれないのでまとめました。

[山市良，テクニカルライター]

連載目次

2017年9月のWindows Update日記

　「第二火曜日の翌日」（日本において）は、Windows Updateで新しい更新プログラムが配布される毎月恒例の更新日です。以前は、リリース後長い時間が経過したWindows 7において、Windows Updateがなかなか進まないという問題がたびたび報告されましたが、2016年末に導入された「累積的な更新プログラム」による提供に切り替わってからは、スムーズに進むようになりました（スムーズになったのは、その他にもエージェントの更新などが関係しているかもしれません）。

　一方、累積的な更新プログラムが基本のWindows 10やWindows Server 2016では、更新プログラムのファイルサイズが大きくなると、更新の確認やダウンロード、インストールの準備、更新のための再起動に異様に長い時間がかかるようになったり（時には完全に止まっているように見えることもあります）、更新の失敗を繰り返したりといったトラブルが目立つようになってきました。SNSなどでユーザーの反応を見る限り、多数のテスト、評価環境を毎月更新している筆者だけの話ではないようです。Windows Updateに関するトラブルの話題は、本連載でも何度も取り上げてきました。

• Windows UpdateとIaaSクラウドは忍耐が試される？（本連載 第96回）
• 進まないWindows Update、やっぱり止まっていなかった（本連載 第97回）
• Windows Server 2016の今後の“更新”が怖い（本連載 第98回）
• 最近のWindows Updateは、本当にどうかしている（と思う）（本連載 第103回）

　2017年9月12日の早朝から、物理マシンと仮想マシンの複数バージョンのWindowsを対象に、数台ずつ順番にWindows Updateを実行していったところ（ネットワーク帯域を圧迫しないためでもありますし、仮想化環境のリソースの制約もあるため）、9月の更新で目立った問題はなさそうでした。Hyper-V上のWindows Server 2016を実行する仮想マシンの数台で異様に長い時間がかかるものもありましたが、処理の終了を待たずに、次の方法で更新を完了しました。

（1）Windows Updateを実行する前に、念のため作成しておいた仮想マシンの「チェックポイント」を適用して、正常な状態に戻す。

（2）本連載第103回で紹介したオフラインメンテナンスの方法で、仮想マシンのVHD／VHDX内のイメージに対してオフラインで累積的な更新プログラムを適用する。

（3）仮想マシンを起動して、正常に起動すること、最新のビルドに更新されたことを確認する。

（4）Windows Updateを手動で実行し、検出された更新プログラムをインストールする（今回はWindows Defenderの定義ファイルの更新と悪意のあるソフトウェアの削除ツールのみでした）。

　トラブルが発生したのは、Microsoft Azure上の仮想マシンでWindows Updateを手動実行したときでした。1回ですんなりと成功するものがほとんどでしたが、Windows Server 2016を実行しているAzure仮想マシンのうち、5台で累積的な更新プログラム「KB4038782（OSビルド14393.1715）」のインストールトラブルが発生しました。

　そのうち2台は、更新プログラムのダウンロード途中（45％）から何時間たっても進まない状態でしたが、本連載第96回で紹介した「Windows 10／Windows Server 2016のWindows Update正常化テク（経験則）」で更新を完了させることができました。

　残る3台のうち2台では、KB4038782のインストールを完了させるための再起動後、長時間、リモートデスクトップ接続ができない状態が続きました。ローカルコンソールのスクリーンショットを見ることができるAzureポータルの「ブート診断」機能で確認してみると、「更新プログラムを構成できませんでした、変更を元に戻しています」と表示されていました（画面1）。

画面1　リモートデスクトップ接続がなかなかできないと思ったら、累積的な更新プログラム「KB4038782」のインストールに失敗して元に戻し中

　その後、ようやく、リモートデスクトップ接続が可能になったので、履歴を確認してみるとKB4038782のインストールは失敗していて、8月更新時点のビルド14393.1593のままでした。

　最後の1台は、Azure上に構築したテスト用のActive Directoryドメインを管理するドメインコントローラーです。実は、こちらも更新プログラムのダウンロード途中（45％）で止まったように見える状態でしたが、ドメインコントローラーなので辛抱強く待ってみることにしました。しかし、6時間が経過しても45％のままで進みません。Azure仮想マシンの課金が気になるところですが、そのまま放置して翌日まで待ってみることにしました。

　そして、翌日、画面に表示されていた進捗（しんちょく）は、やっぱり45％のままでした（画面2）。完全に停止しているのかどうか、ディスクI/Oや対象ディレクトリ（C:\Windows\CbsTemp）を調査してみると、同じ内容をディレクトリ名を変更しながら、何度も繰り返しているような感じでした。

画面2　合計12時間以上放置したのにもかかわらず、ダウンロード45％時点で完全に停止？