Windows Updateの“更新遅い”問題を改善したい！――Windows Server 2016の場合：山市良のうぃんどうず日記（151）（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の今後の“更新”が怖い（2017年6月27日）（本連載 第98回）

　Windows Server 2016のリリース直後に新規インストールし、その後、更新を続けてきた物理／仮想マシンが何台かあるのですが、時間はかかるものの、最終的には全てを最新状態に更新できています。

　しかし、数カ月前に新規インストールし、特に用途もなく、毎月の更新だけをしているWindows Server 2016の仮想マシン2台のうち1台だけが、なぜか2019年2月のWindows Updateを完了できませんでした。筆者が知る限りの対処方法をいろいろと試してみましたが、10時間以上かけても成功させることができず、仮想マシンを削除して作り直すことにしました。

　Windows Server 2016の新規インストールから最新状態への更新まで、全てを合わせても4時間もかからずに終了しました。Windows 10およびWindows Server 2016以降は、新規インストールに限れば、累積的な品質更新プログラムのメリットを十二分に感じられます。最小限の品質更新プログラムとサービススタック更新プログラムだけで最新状態になるからです（画面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　再起動後にWindows Updateは再開されるが、1時間以上たって結局この画面はキツい。この後、「再試行」をクリックして2時間程度で更新完了

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

　また、シャットダウンや再起動に時間がかかるWindows Server 2016の仮想マシンに対して、Azureポータルの「停止」や「再起動」を操作して、Azureのタイムアウト内に完了しないと、強制的にオフになるようです。その場合には、次回起動時にリモートデスクトップ接続すると「シャットダウンイベントの追跡ツール」が表示されることで分かります（画面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　「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　Azure仮想マシンのサイズの見直しは、コスト削減や性能向上を期待できる

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