連載
» 2019年04月16日 05時00分 公開

山市良のうぃんどうず日記(151):Windows Updateの“更新遅い”問題を改善したい!――Windows Server 2016の場合 (1/2)

評価や動作確認のために、さまざまなバージョンのWindows環境を維持している筆者は、毎月第二火曜日の翌日にある定例の「Windows Update」は悩みの種。記事のネタにもなるわけですが、特にWindows Server 2016(少数の物理/仮想マシンと少数のAzure仮想マシン)の更新には、毎回、多くの時間を取られています。なんとか改善できないものかチャレンジしてみました。それも長い時間をかけ、Azure仮想マシンの課金を気にしながら……。

[山市良,テクニカルライター]
「山市良のうぃんどうず日記」のインデックス

山市良のうぃんどうず日記

Windows Server 2016は更新し続けるより、新規インストールから再構築する方が早い

 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 画面1 2019年2月19日に新規インストールして最新状態に更新したWindows Server 2016の「更新の履歴」。新規インストール開始から4時間もかかっていない

 しかし、運用環境のサーバでは、この方法は“最後の手段”になるでしょう。その1つ手前の手段として、Windows Server 2016の「アップグレードインストール」という方法があります。

更新、シャットダウン、再起動に異様に時間のかかるAzure仮想マシンの問題

 2019年2月の定例更新では、Microsoft Azure上のWindows Server 2016仮想マシンの4台中2台で、Windows Updateを開始してから6時間以上経過してもダウンロードが90%や95%で先に進まないものがありました。再起動しても1時間たっても起動しないため、強制的にリセット(Azureポータルからの再起動操作)し、起動後にWindows Updateを実行して、今度は数時間で完了しました(画面2)。この2台は、更新に関係のないときでも再起動やシャットダウンに30分〜1時間かかることがあります。

画面2 画面2 再起動後にWindows Updateは再開されるが、1時間以上たって結局この画面はキツい。この後、「再試行」をクリックして2時間程度で更新完了

 なお、Azure仮想マシンを不用意にリセットすると、次回起動時に「チェックディスク(chkdsk)」の処理が始まることがあるので注意してください(「ブート診断」機能でその様子を確認できます)。

 また、シャットダウンや再起動に時間がかかるWindows Server 2016の仮想マシンに対して、Azureポータルの「停止」や「再起動」を操作して、Azureのタイムアウト内に完了しないと、強制的にオフになるようです。その場合には、次回起動時にリモートデスクトップ接続すると「シャットダウンイベントの追跡ツール」が表示されることで分かります(画面3)。

画面3 画面3 Azureポータルの「停止」や「再起動」を使用すると、Windows Server 2016では強制オフや強制リセットになることも……

 これらのAzure仮想マシンのWindows Updateやシャットダウン、再起動に時間がかかる問題をなんとか改善できないかと思い、2019年3月の定例更新の前日に以下の「DISM」コマンドを実行して、コンポーネントストア(C:\Windows\WinSxS)の破損をチェックし、自動修復させてみました。コマンドが完了するまでに、1台の仮想マシンでは約1時間、もう1台の仮想マシンは2.5時間かかりました(画面4)。

DISM /Online /Cleanup-Image /RestoreHealth
画面4 画面4 「DISM」コマンドでコンポーネントストアを修復しておく。経験上、100%や100%に限りなく近いところまでいけば、エラーが出ても問題ないようだ

 本当は「ディスククリーンアップ」(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)。

画面5 画面5 Azure仮想マシンのサイズの見直しは、コスト削減や性能向上を期待できる

 こちらは2コア、8GBメモリ、月1万749.31円(推定)です。ストレージも「Premium SSD」に変えればディスク性能がアップしますが、めったに使わない評価環境であるため「Standard HDD」のままにしました。コンピューティング料金とは異なり、ストレージは常に課金対象になるからです。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。