評価や動作確認のために、さまざまなバージョンのWindows環境を維持している筆者は、毎月第二火曜日の翌日にある定例の「Windows Update」は悩みの種。記事のネタにもなるわけですが、特にWindows Server 2016(少数の物理/仮想マシンと少数のAzure仮想マシン)の更新には、毎回、多くの時間を取られています。なんとか改善できないものかチャレンジしてみました。それも長い時間をかけ、Azure仮想マシンの課金を気にしながら……。
Windows 10やWindows Server 2016の「Windows Update」が終わらない、進まない、失敗するといった問題について、トラブルシューティングのヒントとともに本連載で何度も取り上げてきました。Windows Server 2016のWindows Updateは、毎月の品質更新プログラムのファイルサイズが1GBを超えたあたりから(品質更新プログラムは累積的なので増加し続けます)、ダウンロードやインストール、再起動に特に時間がかかるようになりました。
例えば、2年前にはWindows Server 2016のWindows Updateの今後を心配する以下の記事を書きました。
Windows Server 2016のリリース直後に新規インストールし、その後、更新を続けてきた物理/仮想マシンが何台かあるのですが、時間はかかるものの、最終的には全てを最新状態に更新できています。
しかし、数カ月前に新規インストールし、特に用途もなく、毎月の更新だけをしているWindows Server 2016の仮想マシン2台のうち1台だけが、なぜか2019年2月のWindows Updateを完了できませんでした。筆者が知る限りの対処方法をいろいろと試してみましたが、10時間以上かけても成功させることができず、仮想マシンを削除して作り直すことにしました。
Windows Server 2016の新規インストールから最新状態への更新まで、全てを合わせても4時間もかからずに終了しました。Windows 10およびWindows Server 2016以降は、新規インストールに限れば、累積的な品質更新プログラムのメリットを十二分に感じられます。最小限の品質更新プログラムとサービススタック更新プログラムだけで最新状態になるからです(画面1)。
しかし、運用環境のサーバでは、この方法は“最後の手段”になるでしょう。その1つ手前の手段として、Windows Server 2016の「アップグレードインストール」という方法があります。
2019年2月の定例更新では、Microsoft Azure上のWindows Server 2016仮想マシンの4台中2台で、Windows Updateを開始してから6時間以上経過してもダウンロードが90%や95%で先に進まないものがありました。再起動しても1時間たっても起動しないため、強制的にリセット(Azureポータルからの再起動操作)し、起動後にWindows Updateを実行して、今度は数時間で完了しました(画面2)。この2台は、更新に関係のないときでも再起動やシャットダウンに30分〜1時間かかることがあります。
なお、Azure仮想マシンを不用意にリセットすると、次回起動時に「チェックディスク(chkdsk)」の処理が始まることがあるので注意してください(「ブート診断」機能でその様子を確認できます)。
また、シャットダウンや再起動に時間がかかるWindows Server 2016の仮想マシンに対して、Azureポータルの「停止」や「再起動」を操作して、Azureのタイムアウト内に完了しないと、強制的にオフになるようです。その場合には、次回起動時にリモートデスクトップ接続すると「シャットダウンイベントの追跡ツール」が表示されることで分かります(画面3)。
これらのAzure仮想マシンのWindows Updateやシャットダウン、再起動に時間がかかる問題をなんとか改善できないかと思い、2019年3月の定例更新の前日に以下の「DISM」コマンドを実行して、コンポーネントストア(C:\Windows\WinSxS)の破損をチェックし、自動修復させてみました。コマンドが完了するまでに、1台の仮想マシンでは約1時間、もう1台の仮想マシンは2.5時間かかりました(画面4)。
DISM /Online /Cleanup-Image /RestoreHealth
本当は「ディスククリーンアップ」(Cleanmgr.exe)ツールで「Windows Updateのクリーンアップ」項目の削除、あるいは次のコマンドラインを実行して「コンポーネントストアのクリーンアップ」も実行しておきたいところです。
DISM /Online /Cleanup-Image /StartComponentCleanup [/ResetBase]
しかし、筆者の経験からすると、Windows Server 2016では完了までに4時間とか6時間とか、あるいはそれ以上の時間がかかる場合があるため(過去にクリーンアップしたことがない場合、仮想マシンなどディスクのオーバーヘッドが大きい場合など)、Azureの課金が気になり、断念することにしました。完了前に、翌日の2019年3月の定例更新がきてしまうかもしれません(これは冗談です。自動更新はオフにしてあります)。
なお、コンポーネントストアのクリーンアップについては、次回紹介する予定です。
コンポーネントストアのクリーンアップの代わりではないですが、この機会にAzure仮想マシンのシリーズ/サイズも見直しました。Windows 10およびWindows Server 2016のWindows Updateでは、大量のファイルI/O(Input/Output)が行われるため、ディスク性能がWindows Updateのエクスペリエンスに大きく影響していると感じていたからです。
問題の仮想マシンは2年以上前に「Azureクラシックポータル」(2018年1月に廃止)で作成した「クラシックデプロイモデル」の仮想マシンであり、A2やA8といった初期シリーズのサイズでした。クラシックデプロイモデルにしたのは、当時、Azureクラシックポータルを使い慣れていたから。初期シリーズのサイズにしたのは、当時、単価が安かったからです。現在は、同等以上のCPU/メモリ構成で、より性能が良く、より単価の低いシリーズがあるので、初期シリーズのままで利用し続けるのはもったいないこと。
問題の仮想マシンは、開発やテストに適したAシリーズ「Standard A2」でした(現在は後継の「Standard A2_V2」があります)。このサイズは2コア、3.5GBメモリ、月1万2165.80円(推定)ですが、汎用(はんよう)コンピューティング向けの「Standard D2_V3」に変更しました(画面5)。
こちらは2コア、8GBメモリ、月1万749.31円(推定)です。ストレージも「Premium SSD」に変えればディスク性能がアップしますが、めったに使わない評価環境であるため「Standard HDD」のままにしました。コンピューティング料金とは異なり、ストレージは常に課金対象になるからです。
Copyright © ITmedia, Inc. All Rights Reserved.