●「累積的な更新」の意義は理解できますが……

 Windows Update、特にWindows 10で大きく変更されたWindows Updateは、本連載で何度も取り上げているトピックです。しかし、PCやネットワークが重くなる、すぐ使いたいのに更新のための再起動に阻まれる、ダウンロードや更新が一向に進む気配がないなど、Windows 10のWindows Updateで苦労している方も多いと思います。筆者は、仕事用、家庭用の物理PCに加えて、検証環境用に複数の物理マシンと大量の仮想マシンをメンテナンスしており、ここ最近は何度かWindows Updateのトラブルに遭遇しています。

 Windows 10のWindows Updateの大きな変更点の1つである「累積的な更新プログラム」による更新は、大きなメリットがあるのは事実です。特に、Windows 10を新規インストールする場合がそうです。

 例えば、最新の累積的な更新プログラムとAdobe Flash Playerの更新のインストール、Windows Defenderの定義の更新、悪意のあるソフトウェアの削除ツールの実行、これら数個の更新プログラムをインストールするだけで、短時間で最新状態にまで更新できるからです。

 2017年8月4日に新規インストールしたWindows 10 Creators Update(バージョン1703)ですが、インストール直後の数個の更新プログラムで、その時点で最新ビルド「15063.502(KB4032188)」に更新されました。

 最新ビルドになったWindows 10は、毎月の定例更新、あるいはその間に提供される新しいセキュリティ更新を含まない累積的な更新プログラムにより、既知の脆弱(ぜいじゃく)性が排除され、不具合が修正されていくわけですが、そこからが苦難の始まりになるかもしれません。“かも”といったのは、Windows Updateに関してほとんど問題が出ないPCもあれば、毎回のように何らかの問題に遭遇するPCもあるからです。筆者の評価環境にある、まっさらな(Windows Updateしかしていない)仮想マシンであっても、問題に遭遇することがあります。更新プログラムの問題であることも、もちろんあります。

●定例更新の消えた「更新の履歴」問題

 2017年8月(日本では8月9日)の定例のWindows Updateは、あいかわらず“時間がかかる”という印象でしたが、筆者の環境では失敗などの問題はなく、無事に完了しました。ただし、後で1つの問題に遭遇しました。Windows 10 Anniversary Update(バージョン1607)とWindows Server 2016の「更新の履歴」(「設定」アプリの「更新とセキュリティ」→「Windows Update」にある)が消えてしまい、「更新プログラムがまだインストールされていません」と表示されたのです。どちらも、OSビルド「14393」であり、「更新の履歴」が消えた後の詳細なビルドは「14393.1593」です。

 この問題については、その後、以下のWebページの「この更新プログラムの既知の問題」に追加されました。Microsoftによると、「マイクロソフトはこの問題を調査中です。可能な限り早く更新プログラムを提供いたします」ということだそうです。

 「更新の履歴」が消えてしまうと、更新に成功したのか、失敗したのかも分かりません。詳細なビルド番号から累積的な更新プログラムについては判断できますが、それ以外にもインストールされた更新プログラムが存在するはずです。この問題を受け、筆者の個人ブログに「更新の履歴」以外の場所や方法で、更新プログラムのインストール履歴を確認する方法をまとめておきました。イベントログからコマンドラインで履歴を抽出する方法は、企業で使うと便利だと思います。

●翌週リリースの累積的な更新はダウンロード提供のみ

 筆者は、頻繁に以下のWebページをチェックして、新しい累積的な更新プログラムがリリースされていないか、累積的な更新プログラムに問題が報告されていないかを確認しています。以下のページはWindows 10 バージョン1703のものですが、Windows 10 バージョン1607とWindows Server 2016、Windows 10 バージョン1511以前についても、同じページのリンクからアクセスできます。日本語版のページ(en-usをja-jpに置き換える)もありますが、最新情報を得るにはオリジナルの英語版のページを確認することをお勧めします。
 2017年8月の定例更新はお盆直前の時期でした(お盆明けに延期した企業もあるかもしれません)。Windows 10 バージョン1607とWindows Server 2016に関しては、その翌週(8月16日付)のお盆明けに、新しい累積的な更新プログラムがリリースされました。

 当初は(筆者が確認した限り、最終更新日:2017/08/17 - リビジョン:26までは)、「How to get this update(この更新プログラムの入手方法)」に次のように書かれていました。

――――――
This update will be downloaded and installed automatically from Windows Update. To get the standalone package for this update, go to the Microsoft Update Catalog website.(この更新プログラムは、Windows Updateから自動的にダウンロードおよびインストールされます。この更新プログラムのスタンドアロンパッケージを入手するには、Microsoft Updateカタログ Webサイトにアクセスします)
――――――

 そのため、お盆を挟んでの二週連続リリースとあっては、企業は大騒ぎになるだろうと予想しました。お盆休み明けにPCを起動したら更新が始まり、たまった仕事が進まないなどです。しかし、実際にはこの累積的更新プログラムはWindows Updateでは配布されず、Microsoft Update Catalogからのダウンロード提供のみでした。現在(筆者が確認した限り、リビジョン:28では)、上記の前半の「Windows Updateで自動的にインストールされる」という記述は削除されています。このようなドキュメントのちょっとした(それでいて重要なミス)を見ても、最近のWindows Updateは本当にどうかしていると思ってしまいます。

 この累積的な更新プログラムは、Microsoft Update Catalogからのダウンロード提供だけなので、ほとんどのユーザーは提供されていることに気が付いていないかもしれません。しかし、企業ユーザーにとっては重要な修正が含まれているかもしれません。

 例えば、Citrix XenAppに関する問題の修正や暗号化ドライブの問題の修正、Active Directoryに関連する複数の問題の修正などです。この累積的な更新プログラムで修正される内容を確認して、自分の環境に影響がない(緊急に解決したい問題がない)場合は、インストールする必要はありません。今回の修正内容は、次にWindows Update経由で配布される累積的な更新プログラムに累積されるため、急ぐ必要はありません。ちなみに、「更新の履歴」が消える問題については、引き続き「Known issues in this update(この更新プログラムの既知の問題)」のリストの中です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

●企業の強い味方の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つに似ていますが、直接関連しているのかどうかは分かりません。

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

 

【関連記事】

これまで以上に前途多難? 「Windows 7サポート終了」認知徹底の難しさ

マイクロソフト、「Azure Event Grid」発表--イベントベースのアプリ開発を支援