検索
連載

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

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

PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ |       

その他の影響(1)− 未完の自動クリーンアップタスク

 先ほど少し触れ、次回説明予定の「コンポーネントストアのクリーンアップ」は、システムに定義済みの「\Microsoft\Windows\Servicing\StartComponentCleanup」タスクでアイドル時間に自動実行されます。そのため、運用サーバであれば、タスクが定期的に自動実行され、コンポーネントストアが健全な状態に保たれ、その結果としてWindows Updateがスムーズに進むのではと筆者は想像しています。

 しかし、このタスクは実行開始から1時間でタイムアウトとなり、終了してしまうため、稼働時間が短いサーバではコンポーネントストアが不健全な状態になり、手動で解消するとしても長時間かかってしまうことになるのではないかと疑っています。手動で解消する方法については、次回説明します。

 もう一つ、Windows Server 2016のデスクトップエクスペリエンス環境では「\Microsoft\Windows\DiskCleanup\SlientCleanup」タスクが、Windows Updateの処理時間に影響を与える可能性があると感じています。

 Windows Updateを実行中に「なんだか時間がかかる」と思い、「タスクマネージャー」(Taskmgr.exe)を開いてみたら、「プロセス」タブで「Windows用ディスククリーンアップマネージャー」という名前、「詳細」タブでは「cleanmgr.exe」のプロセスが動作しているのを何度か目にしたことがあるからです(画面6)。こちらのタスクもアイドル時に自動実行され、1時間のタイムアウトで強制的に終了します。

画面6
画面6 Windows Updateに時間がかかると思ったら、「Windows用ディスククリーンアップマネージャー(cleanmgr.exe)」プロセスが動いていたことがある。1時間で強制終了するタスクなので、見つけたら途中で終了しても問題ないはず

 このタスク(プロセス)が実行されているのを見たら「タスクスケジューラ」(Taskschd.msc)でタスクを強制終了することで、Windows Updateの方を時短できるかもしれません。なお、Server Coreインストールには「\Microsoft\Windows\DiskCleanup\SlientCleanup」タスクが登録されておらず、システムファイルとして「cleanmgr.exe」も存在しないため、このタスクがWindows Updateに影響することはありません。

その他の影響(2) − .NETネイティブイメージの再コンパイル処理

 Windows Updateのタイミングで起動し、更新が完了するとシャットダウンするような物理/仮想マシンの場合、次にWindows Updateのために起動した際、前回の.NET Frameworkの更新を理由としたNET Frameworkのネイティブイメージの再コンパイル処理と、新しいWindows Updateの処理が重なり、Windows Updateの失敗や遅延の原因になることがあります。

 Windows Updateのために再起動した後、「タスクマネージャー」などで「ngen.exe」(Microsoft Common Language Runtime native compiler)とともに、長時間にわたり、次々に生成されては消えていく大量の「mscorsvw.exe」(.NET Runtime Optimization Service)のプロセスを目にしたことはないでしょうか。そのプロセスが再コンパイル処理のためのものです。

 Windows 10、Windows Server 2019、およびWindows Server, version 1809からは、.NET Frameworkの累積更新プログラムが、Windowsの累積更新プログラムから分離されました(Windows 8.1以前やWindows Server 2012 R2以前はもともと別の累積更新プログラム)。それ以外のWindows 10、Windows Server 2016、Windows Server, version 1803以前は、Windowsの累積更新プログラムに.NET Frameworkの更新が含まれています。

 以下の公式ブログで説明されているように、.NET Frameworkが更新されるとネイティブイメージが無効になり、再コンパイルする必要が生じます。再コンパイルはシステムのアイドル時に自動実行されるようにスケジュールされますが、起動時間が少ない物理/仮想マシンの場合、いつまでもたっても処理されない状態になるかもしれません。

 コマンドプロンプトで次のコマンドラインを実行すると、再コンパイル処理を手動で開始し、完了させることができます。既に終了している場合は、これらのコマンドラインは「All compilation targets are up to date.」と表示してすぐに終了します。次のWindows Updateを実施する前に、念のため実行しておくとよいでしょう。

C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen.exe executeQueuedItems
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen.exe update
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe executeQueuedItems
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update

結果発表、2019年3月と4月のWindows Updateはどうなった?

 いよいよ2019年3月13日、定例更新の日がやってきました。問題が発生していた2台のAzure仮想マシンのWindows Update結果は、以下の通りです。

仮想マシン1:合計約190分

  • 更新の確認開始からダウンロード100%まで:約30分
  • インストール開始から再起動の保留中まで:約70分
  • 再起動開始から起動完了まで:約90分

仮想マシン2:合計約135分

  • 更新の確認開始からダウンロード100%まで:約30分
  • インストール開始から再起動の保留中まで:約90分
  • 再起動開始から起動完了まで:約15分

 どちらも1回のWindows Updateと1台の再起動で問題なく完了しました。Windows 10やWindows Server, version 1709以降と比較すると、やはり時間はかかっていますが、2019年2月のときと比べると大きな改善です。

 計測していませんが、翌月の2019年4月10日の定例更新も同じくらいの時間で完了しました。コンポーネントストアを事前に修復させておいたことがよかったのか、Azure仮想マシンのシリーズ変更の効果なのか、更新プログラム自身の改善なのかは謎のままです。

筆者紹介

山市 良(やまいち りょう)

岩手県花巻市在住。Microsoft MVP:Cloud and Datacenter Management(2018/7/1)。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。Microsoft製品、テクノロジーを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。近著は『ITプロフェッショナル向けWindowsトラブル解決 コマンド&テクニック集』(日経BP社)。


前のページへ |       

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る