最近のWindows Updateは、本当にどうかしている（と思う）：山市良のうぃんどうず日記（103）（2/2 ページ）

2017年8月の定例のWindows Update後、Windows 10 バージョン1607とWindows Server 2016の「更新の履歴」が消えるという事象に遭遇しました。その翌週には、これらのOSに対し、累積的な更新プログラムが提供されました。その累積的な更新を数台の仮想マシンにインストールしようとしたら、丸一日かかってしまいました。

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

ねぇ、KB4034661の更新に何時間かかったと思う……3.5時間

　KB4034661は必須の更新ではありませんが、テストのためにWindows 10 バージョン1607 1台とWindows Server 2016 2台、計3台の仮想マシンにインストールしてみました。Windows 10 バージョン1607は、1時間ほどかかりましたが、特に問題なく完了。修正されていないはずの「更新の履歴」にもちゃんと残りました（画面3）。ただし、過去の履歴が復活することはありませんでした。

画面3　Windows 10 バージョン1607へのKB4034661の手動インストールは問題なく完了。「更新の履歴」にも履歴が残った

　Windows Server 2016の仮想マシンの1台は、非常に時間がかかりました。手動インストール開始から2.5時間たっても以下の画面4の状態です（ダウンロード時間は含みません）。結局、更新が完了するまでにかかった時間は3.5時間以上でした。再起動が要求されたのは3時間50分後、再起動が完了するまでさらに20分でしたので、合計4時間以上かかったことになります。

画面4　手動更新開始から2時間30分経過しても、進行状況のバーはこの状態。ちなみに、更新プログラム（.msu）のサイズは1GB以上

　更新プログラムのインストール中に「リソースモニター」でディスクアクティビティーを確認したところ、「C:\Windows\CbsTemp」ディレクトリに激しく書き込んでいる状態でした（画面5）。また、「C:\Windows\SoftwareDistribution\Download」ディレクトリの中を見ると、この更新プログラム（.cab）が展開されたサブディレクトリの、さらに下にある「Install」サブディレクトリに3万個以上のファイルが展開されていました。

画面5　更新プログラムのインストール中に見た「C:\Windows\CbsTemp」ディレクトリ配下に対する大量の書き込みアクティビティー

　以前から想像していたことですが、ディスクI/Oの性能が累積的な更新プログラムの処理に大きく影響していて、累積的な更新プログラムのサイズが巨大化すると、状況がさらに悪化するように見えます。筆者は、決して高性能ではない、同じディスク（1スピンドル）上に複数の仮想マシンの仮想HDD（.vhdx）を配置して、同時実行したり、多段でチェックポイントを作成したりしているので、そうしたことが重なって更新処理に余計に時間がかかっているのかもしれません。

手動インストールが成功しなかったもう1台の仮想マシン

　Windows Server 2016のもう1台の仮想マシンは、2時間かからずに更新プログラムインストール後の再起動までたどり着きました。しかし、この仮想マシンは再起動しても「Windowsの準備をしています コンピューターの電源を切らないでください」と表示したまま、1時間以上固まったままでした（画面6）。進行状況を示すサークルさえ表示さません。

画面6　この状態のまま、さらに1時間以上経過。もう仮想マシンをリセットするしかない

　仮想マシンをリセットすると、ビルドは以前のままで、インストールは失敗していました。「C:\Windows\SoftwareDistribution」ディレクトリのリセットを試してみましたが、その後の手動インストールも全く同じ状況でした。「C:\Windows\SoftwareDistribution」ディレクトリのリセットは、Windows Updateを正常化するのによく効く処方箋です。今回は効果がありませんでしたが、詳しくは、以下の記事をご覧ください。

• Windows UpdateとIaaSクラウドは忍耐が試される？（本連載 第96回）

　問題のWindows Server 2016は、仮想HDD（.vhdx）にインストールされているHyper-Vの仮想マシンです。仮想HDD（.vhdxまたは.vhd）は、ローカルマウントして、オフラインメンテナンスするというテクニックがあります。ダメ元で、この方法を試してみました。

　Windowsエクスプローラーを使用して仮想マシンの仮想HDD（.vhdxまたは.vhd）をダブルクリックしてローカルマウントし、自動マウントされたイメージ（オフラインイメージ）のドライブ文字（Windowsディレクトリが存在するドライブ）を確認して、コマンドプロンプトで次のように実行します。

DISM /Image:<オフラインイメージのドライブ文字:\> /Add-package /PackagePath:<ダウンロードした更新プログラムのフルパス（.msu）>

　「操作は正常に完了しました」と表示されたら、「ディスクの管理」スナップインなどを使用して仮想HDDを切断します。問題の仮想マシンを起動したら、最新ビルドへの更新が完了していました。

　なお、仮想HDDのオフラインメンテナンスはイメージを破壊してしまう可能性もあるので、仮想HDDの差分ディスクを作成し、そちらで作業して、仮想マシンを起動してみて正常に更新されていれば、親ディスクと結合するという手順で行うとよいでしょう。

画面7　仮想HDDのオフラインメンテナンスの方法で、更新プログラムをインストールする

それでは、物理マシンのときはどうすれば……

　「DISM」コマンドを利用したオフラインイメージに対する更新プログラムのインストールは、ローカルマウントできる仮想HDDであれば簡単な方法ですので、試してみる価値はあります。しかし、これが物理マシンとなるとちょっと厄介になります。

　1つの方法は、システム修復環境のコマンドプロンプト（起動オプションのトラブルシューティングのコマンドプロンプト、またはシステム修復ディスクやWindowsインストールメディアから起動したWindows PE環境など）を起動して、OSディスクに対して同様のコマンドを実行することもできるはずです（過去に別バージョンのWindowsで経験済み）。

　しかし、今回の更新プログラムで試してみたところ、「このコマンドを実行するための十分な記憶域がありません」というエラーが発生し、完了しませんでした（画面8）。ディスクの空き領域は十分あるのですが、更新プログラムのサイズが大き過ぎるのか、物理メモリが足りないからなのか、原因は不明です。

　最終手段としては、物理マシンからHDDを取り出し、USBタイプのHDDケースを使って別のマシン（同じOSバージョン、ビルドを推奨）に接続して、オフラインメンテナンスするという方法はあります。その場合、仮想HDDのローカルマウントと実質的に同じなので、成功するはずです。

画面8　Windows PE環境（Windowsインストールメディアから起動）で起動してDISMコマンドを実行したところ、原因不明のエラーで失敗

企業の強い味方のWSUSも頼りない？

　多数のWindows 10クライアントを管理する企業は、Windows Updateの問題に振り回されないためにも「Windows Server Update Services（WSUS）」やSystem Center製品、その他のシステム管理ツールを用いた更新管理が、以前のバージョンのWindowsよりもますます重要になってきます。

　Windows 10の既定の設定に任せておくと、更新に関連するPCやネットワーク負荷が業務の生産性を落としてしまうでしょうし、アクティブ時間外（その企業の業務時間外ではなく、Windows Updateの設定としてのアクティブ時間外）の突然の再起動が作業中のデータを吹き飛ばしてしまうかもしれません。

　しかし、そのWSUSもWindows 10に関しては、いささか心もとない状況にあるようです。未解決あるいは解決済みですが利用者側の対応が必要な問題が、WSUSやSystem Centerチームのブログで幾つか説明されています。最初のブログは、KB4034658にある「既知の問題」の1つに似ていますが、直接関連しているのかどうかは分かりません。

• ソフトウェアの更新ポイントサーバーにおいてw3wp.exeのCPU使用率が高騰化する（Japan System Center Support Team Blog）
• Windows 10 バージョン1607で更新プログラム適用後の自動再起動が実施されない（Japan WSUS Support Team Blog）
• Windows 10のWSUSクライアントがWindows Updateから更新プログラムを取得するようになってしまう事象について（Japan WSUS Support Team Blog）

　クライアントはWindowsである限り、Windows Updateには今後も苦労することになるでしょうが、サーバ側はいろいろと対策はできます（その分、お金は掛かりますが）。インフラサーバは仮想化とクラスタ化、アプリケーションは多重化やクラスタ化で、Windows Serverの更新のために1台が数時間使い物にならなくても、更新が失敗してクラスタからその1台が脱落することになっても、業務に影響しないようなシステム構成にすることで何とかなるでしょう。そして、IaaSやPaaSを利用しているのなら、マルチインスタンスによる可用性確保や使い捨て前提のデプロイ（更新ではなく、再デプロイで最新にする）の考えでシステム構築すれば何とかなるでしょう。

筆者紹介

山市 良（やまいち りょう）

岩手県花巻市在住。Microsoft MVP：Cloud and Datacenter Management（Oct 2008 - Sep 2016）。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。Microsoft製品、テクノロジーを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。近著は『Windows Server 2016テクノロジ入門−完全版』（日経BP社）。