進まないWindows Update、やっぱり止まっていなかった：山市良のうぃんどうず日記（97）（1/2 ページ）

Windows 10で大きく変わったWindows Update。Windows Updateがなかなか進まないという状況もしばしば。そのとき、裏側では何が行われているのか、Windows Updateの状況を別の視点から追跡してみました。

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

新規インストール直後の3つの更新プログラムに2時間半の怪

　Windows 10で「Windows Update」は大きく変更され、同じ機能はWindows Server 2016にも搭載されました。新しいWindows Updateに関しては、本連載でも何度か取り上げたように、さまざまな意見があると思います。筆者は「累積的な更新プログラム」への変更は、改善点と評価してきました。新規インストール後、最小限の更新プログラムのインストールで最新状態になるからです。しかし、前回の記事のように、改善といえるのかどうか少し疑問になってきました。

• Windows UpdateとIaaSクラウドは忍耐が試される？（本連載 第97回）
• Windows Updateへの愚痴――Patch Tuesday、恐怖のトラブル集（本連載 第87回）
• Windows Updateが進まない／完了しない／失敗するという悪夢からの脱出――Windows 10／Windows Server 2016の場合（本連載 第78回）

　以前のWindowsでは、Windows Updateに異様に長い時間がかかることがあるという問題を抱えていましたが（特に長期間Windows Updateの実行をサボったときなど）、前回の記事にあるように、リリースされてまだ半年のWindows Server 2016でも時間がかかることがあります。既定で半年ごとに新しいバージョンに更新されるWindows 10でも、実行中のバージョン（ビルド）やPCのスペックによっては、同じ現象に遭遇する可能性があります。

　前回の記事では、Microsoft AzureのIaaS（Infrastructure as a Service）上にある複数のWindows Server 2016の仮想マシン（VM）で2017年5月の更新がなかなか進まず、強制的に再起動したらクラウド上でVMの起動時に「チェックディスク（chkdisk）」が開始されたことと、その状況から抜け出すために、忍耐強く更新の成功を待つ必要があったことを紹介しました。

　その後、新規インストールではどうなのかが気になったので、Hyper-V環境でWindows Server 2016評価版を使って確認してみました。Hyper-V仮想マシンのスペックは第2世代で、2CPU、4GBメモリです。Hyper-Vホストのストレージは高速なものではありません。

　なお、現在、以下のサイトから入手できるのは「14393.693」ベースの更新されたISOイメージ（なんと、6.68GBもあります）が提供されていますが、今回は2016年9月に提供された「14393.0」ベースのISOイメージを使用しました。

• Windows Server 評価版ソフトウェア：Windows Server 2016（マイクロソフト TechNet Evaluation Center）

　結果を先に言うと、2時間半という長い時間を要しましたが、初回のWindows Updateは成功しました。その後のWindows Updateで「Windows Defender」の定義更新と再起動がない更新が2つ検出されましたが、短時間で終了しました。

　以下、「設定」アプリの「更新とセキュリティ」→「Windows Update」で確認できたままのことをお伝えします。新規インストール直後に「更新プログラムのチェック」ボタンをクリックすると、次の3つの更新プログラムが検出され、ダウンロードが始まりました。

• Windows Server 2016 for x64-Based Systems用更新プログラム（KB4013418）
• 2017-05 x64ベースシステム用Windows Server 2016の累積更新プログラム（KB4019472）
• x64エディション用の、Windows悪意のあるソフトウェア削除ツール − 2017年5月（KB890830）

　そして、「更新プログラムをダウンロードしています 21％」まで進んだところで、完全にストップしたように見えました。「21％」のままで1時間が経過したので「タスクマネージャー」の「パフォーマンス」タブを開いて状況を確認したところ、この間、通信はほとんど発生していません。「プロセス」タブでは「Windows Modules Installer Workers」（「詳細」タブの「TiWorker.exe」）が最も大きなCPU使用率を占め、システム全体で80％以上の高めの負荷を示していました（画面1）。

画面1　更新プログラムのダウンロードが「21％」のままで1時間が経過した状況を「タスクマネージャー」の「パフォーマンス」タブで確認

　さらに20分ほど経過すると、ようやく1％進み「22％」になりました（画面2）。それが15分ほど続き、ようやく進行しているのが分かる状態にカウントアップしていきました（画面3）。更新プログラムのダウンロードが完了し、インストールの準備が終わって、再起動が要求されたのは、Windows Update開始から2時間後。その後、再起動が完了するのにさらに30分かかりました。

画面2　1時間20分が経過して「22％」に

画面3　1時間半が経過すると、ようやくパーセンテージが目に見えて進むようになった

　Windows 10やWindows Server 2016、最近ではWindows 7やWindows 8.1も「累積的な更新プログラム」の提供が基本になりました。「Microsoft Updateカタログ」から入手できる更新プログラムと同じものをダウンロードしているのではなく、更新が必要なコンポーネントだけがダウンロードされます。そのため、「更新プログラムをダウンロードしています」のときに、ずっとダウンロードしているわけではありません。ダウンロードサイズについては、以下の記事で検証しました。

• Windows 10の「累積的な更新プログラム」の本当のダウンロードサイズは？（連載：Windowsにまつわる都市伝説 第71回）
• 信じてはいけない？　Windows 7／8.1の更新ファイルのダウンロードサイズ（連載：Windowsにまつわる都市伝説 第83回）