相変わらず「Windows Server 2016」の更新が遅々として進まない件：山市良のうぃんどうず日記（174）

Windows Server 2016には「更新プログラムのインストールに異様に長い時間がかかる」という、いまだに解消されない問題が残っています。本連載でも何度か取り上げてきましたが、今回あらためて、しつこく取り上げます。なぜなら、Windows Server 2016を運用している管理者にとっては、毎月繰り返される切実な問題だからです。

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

山市良のうぃんどうず日記

Windows Server 2016ではなく2019をお薦めする理由とは？

　ソフトウェアは「リリース直後はバグが多いため信頼性に欠ける」「安定版と呼べるまで待ってから導入すべき」というのが常識と考えている人がいるようですが、Windowsに限ればそうとはいえません。特に最近はリリースサイクルが短くなり、旧バージョンの不具合はそのまま放置され、新バージョンで不具合が解消されるということもあります。

　サーバOSは長期の連続稼働を前提に導入すると思いますが、2016年10月のリリースから3年以上経過した「Windows Server 2016」が“安定版”と呼べるのかというと、難しいところがあります。これから導入するなら、筆者は2018年11月リリースの「Windows Server 2019」をお薦めします。現在、Windows Server 2016を運用中なら、Windows Server 2019へのアップグレードを検討すべきでしょう。

　なお、オンプレミスのサーバの場合、有効なソフトウェアアシュアランス（SA）を持っていれば無料でアップグレードできますが、そうでない場合はライセンスを新たに購入する必要があります。

　Windows Server 2016は、「2022年1月11日」までメインストリームサポートが提供され、その後の延長サポートは「2027年1月12日」まで提供されます。サポートライフサイクルは、Windows Server 2019より2年先行しているだけです。

　Windows Server 2019は、新機能としてピックアップされている機能（セキュリティの強化やコンテナ機能の改良など）や廃止された機能（RemoteFX 3DビデオやEssentialsエクスペリエンスなど）を除き、主要なサーバの役割や機能の多くはWindows Server 2016のものをほぼそのまま引き継いでいます。Windows Server 2016とWindows Server 2019のどちらを選択しても、できることに大差はありません。

　では、なぜWindows Server 2016ではなく、Windows Server 2019をお薦めするのか――。それは、Windows Server 2016の「品質更新プログラムのインストールにかかる時間」です。Windows Server 2016の品質更新プログラムのインストールに4時間以上かかったとしても、その後の再起動に30分以上かかったとしても、筆者は驚きません。サーバハードウェアのスペックにもよりますが、Windows Server 2016ではそんなものです。「Windows Storage Server 2016」を搭載したNAS（ネットワーク接続型ストレージ）製品も同様の状況だと思います。

　Windows Server 2016でWindows Updateを実行すると、全くダウンロードが進行しないように見える、更新後の再起動が無反応になっているように見えることがあります。肝心なのは、終わるまで気長に待つことです。「コンピューターの電源を切らないでください」と表示されていたら、これは“応答なし”の状態になってしまっていると思い込んでリセットしないでください。きっと処理は進行中です。途中で諦めることは、状況を悪化させるだけです（画面1）。

画面1　Windows Server 2016の更新時に、ダウンロードが途中でストップしているように見える、再起動の途中で応答しなくなっているように見える場合があるが、実際には止まっていない

　Windows Server 2016のWindows Updateの更新処理がなかなか進まない状況については、本連載で繰り返し取り上げました。

• 進まないWindows Update、やっぱり止まっていなかった（本連載 第97回）
• 続・進まないWindows Update、やっぱり止まっていなかった（本連載 第131回）

　Windows Updateの仕組みは、「Windows 10」の登場時に大きく変更されました。そのため、さまざまな問題が発生し、後継バージョンで改良され続けています。後継バージョンでは考えられないような異様に長い時間がかかる理由の一つは、Windows Server 2016に搭載されているWindows Updateが初期の問題を抱えているからでしょう。そのため、今後も状況が改善されることは期待できそうにありません。

　さらに、Windows Server 2016とWindows 10 バージョン1607までのWindows Updateの「更新プログラムのチェック」ボタンのクリックは、その翌週（Cリリース）またはさらに翌週（Dリリース）のオプション扱いの更新プログラムを区別することなく、オプションの更新プログラムをインストール対象として検出します（自動更新ではオプションの更新プログラムはインストールされません）。

　そのため、「Windows Server Update Services（WSUS）」で運用せず、Windows Updateからの自動更新で運用している場合は、毎月、少なくとも2回、非常に長い時間を要する更新プログラムのインストールと、その後の再起動が要求されることになります。

　本連載の第97回と第131回では、止まっているように見えるWindows Updateの処理が、実際には進行中であることをWindows Sysinternalsの「Process Monitor」（Procmon.exe）やWindows標準の「リソースモニター」（Perfmon.exe /res）を使って示しました。

　例えば、Procmon.exeで次のようなフィルターを定義すると、Windows Updateの処理が進行中であることを視覚的に追跡することができます。なお、Procmon.exeの既定のフィルターとして、Systemプロセスを除外する設定が存在するため、その定義をオフにすることを忘れないでください（画面2）。

画面2　Windows Updateの処理を監視するためのProcmon.exeのフィルターの定義例

　また、出力されるイベントは膨大になるため、［Show File System Activity］のトグルボタン（キャビネットのアイコン）だけをオンにした状態で、ファイルシステムのアクティビティーだけを監視するとよいでしょう（画面3）。

• Process Name is TiWorker.exe Include
• Process Name is System Include
• Path beginss with C:\Windows\Cbstemp Include
• Path beginss with C:\Windows\Servicing Include
• Path beginss with C:\Windows\SoftwareDistribution\Download Include
• Path is C:\Windows\SoftwareDistribution\DataStore\DataStore.edb Include
• Path beginss with C:\Windows\System32\catroot Include
• Path beginss with C:\Windows\WinSxS Include

画面3　ダウンロードのパーセンテージが全く進まない状態でも、Procmon.exeは激しくファイルI/Oを行っていることを示している

　Procmon.exeやリソースモニターを使用した監視に慣れてくれば、Windows Updateのユーザーインタフェース（UI）に表示されている進捗（しんちょく）状況を見なくても、現在の状況を的確に把握できるようになり、ダウンロードやインストールが進んでいることに安心できるかもしれません。

　ただし、この方法で再起動中の処理を監視することはできないので、ただひたすら戻ってくるのを待つしかありません。また、Windows Server 2016とWindows Server 2019の両方で試してみれば、Windows Updateの処理に変更が加えられていることにも気が付くでしょう。

Windows Serverは長期の連続稼働が想定された設計

　本連載の第151回、第159回では、Windows Server 2016のWindows Updateに時間がかかる問題を改善する幾つかのヒントや、オフラインで更新プログラムをインストールすることで時間短縮を図る方法について紹介しました。

• Windows Updateの“更新遅い”問題を改善したい！――Windows Server 2016の場合（本連載 第151回）
• 続・Windows Updateの“更新遅い”問題を改善したい！──Windows Server 2016の場合［第2弾］（本連載 第159回）

　Windows Serverでは、システムのアイドル時間や特定のスケジュールに従って、バックグラウンドでさまざまなシステムタスクが実行されます。実は、Windows Updateの更新処理は「インストールして、再起動して、終わり」ではなく、バックグラウンドで処理されるメンテナンスタスクの後処理が確実に実行されることが重要です。連続稼働のシステムの場合、後処理はシステムのアイドル時間に処理されることになります。

　しかし、十分に長いアイドル時間が確保できない場合、中断してしまうことがあります。また、OS展開用のイメージや評価／テスト用の仮想マシンなど、後処理が実行されないまま、次の更新プログラムのインストールが実行されてしまう場合もあります。その場合、後処理のタスクと更新プログラムのダウンロードやインストールの処理が集中してしまい、余計に時間がかかることになってしまいます。サーバのスペックによっては、Windows Updateの処理はシステムに無視できない影響を与えます。しかし、Windowsにとって、Windows Updateの処理は非アイドルとは見なされません（アイドル時間に実行されるメンテナンスタスクを停止することはありません）。

　更新プログラムのインストールを開始する前に（例えば、前日などに）、Windows Updateに影響を与える可能性のあるシステムタスクが、前回のWindows Update以後に実行済みであるかどうかを確認することをお勧めします。

　Windows Server 2016のデスクトップエクスペリエンス環境では、「タスクスケジューラ（Taskschd.msc）」の以下のタスクによって、「ディスククリーンアップ（Cleanmgr.exe）」の自動クリーンアップタスクがC:ドライブに対してアイドル時間に実行され、Windows Updateに関連する不要なファイルなどがクリーンアップされます（画面4）。

• \Microsoft\Windows\DiskCleanup\SilentCleanup

画面4　Windows Updateの実行中に同時に実行されたくないメンテナンスタスクの前回の実行結果をタスクスケジューラで確認する

　「前回の実行時刻」が前回のWindows Updateの後であり、「前回実行結果」が「この操作を正しく終了しました。（0x0）」であることを確認してください。アイドル時間が短いと、タスクが完了する前に中断することを繰り返している可能性があります。確実に完了させるには、コマンドプロンプトやWindows PowerShellで次のコマンドラインを実行します。

Cleanmgr.exe /autoclean /d C:

　前回のWindows Updateに.NET Frameworkの更新プログラム（.NET Framework 4.6.2〜4.7.2の更新はWindows Server 2016の累積更新プログラムに含まれる形で提供、.NET Framework 4.8はWindowsとは別の累積更新プログラムとして提供）が含まれる場合、更新プログラムのインストール後に.NETネイティブイメージの再作成が行われます。

　以下のタスクの「状態」が「無効」になっていれば、この処理が実施済み（または不要）であることを示しています。「準備完了」になっていると、未実施の状態だと分かります。

• \Microsoft\Windows\.NET Framework\.NET Framework NGEN v4.0.30319 64 Critical
• \Microsoft\Windows\.NET Framework\.NET Framework NGEN v4.0.30319 Critical

　未実施の場合は、タスクスケジューラからこれらのタスクを実行できますが、長い時間がかかることがある上、終了して「無効」になるまで進捗状況が分からないということもあります。以下の公式ブログで説明されている4つのコマンドライン（次に説明する「forcengentasks.cmd」に含まれます）を手動で実行することで、これらの再コンパイル処理を確実に行えます。

• .NET Frameworkのネイティブ イメージが無効になる状況と考えられる影響について（Microsoft Docs：Visual Studio サポートチーム blog）

Windows Update後の処理を効率化する筆者の裏技紹介

　筆者は評価／テスト用にWindows Server 2016を含め、複数バージョンの仮想マシンを維持しています。実際に評価／テストに使うことは頻繁にはないため、毎月、Windows Updateの時期にだけ起動して、更新プログラムをインストールしているものも多くあります。そのため、.NETネイティブイメージの再作成や自動クリーンアップの処理は、バッチやスクリプトを使用して更新完了直後に実施し、その後、シャットダウンするようにしています。

　次の「forcengentasks.cmd」は、x64版Windows用の.NETネイティブイメージの再作成処理を直ちに実行します（x86版Windowsの場合、最初の2つの「ngen.exe」だけでよい）。大量の標準出力があるので、進捗状況が少しでも分かるとよいと思い、各「ngen.exe」コマンドの実行時の背景色をそれぞれ「黒」「青」「ピンク」「緑」の順番で変化させています（画面5）。

 1 @ECHO OFF
 2 REM https://docs.microsoft.com/ja-jp/archive/blogs/jpvsblog/ngen
 3 C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen.exe executeQueuedItems
 4 COLOR 1E
 5 C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen.exe update
 6 COLOR DF
 7 C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe executeQueuedItems
 8 COLOR 2E
 9 C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update
10 PAUSE

▲「forcengentasks.cmd」（先頭の数字は行数、実際のスクリプトには含まれない、以下同）

画面5　「forcengentasks.cmd」を実行すると、.NET Frameworkの更新プログラムのインストール後に、ネイティブイメージの再作成処理を直ちに開始する。進捗状況は背景色の変化で分かる

　実行完了後に自動的にシャットダウンさせたいなら、「PAUSE」の行（10行目）を以下の3行に差し替えてください。

10 ECHO 15 秒後にシャットダウンを開始します。シャットダウンを中止するには［Ctrl］＋［C］キーを押してください。
11 TIMEOUT 15
12 SHUTDOWN /S /T 0

▲「forcengentasks.cmd」の「PAUSE」行（10行目）の差し替え

　次のPowerShellスクリプト「myprocmon.ps1」は、「SilentCleanup」タスクまたは「Cleanmgr.exe」の手動実行後に開始することで、「cleanmgr」プロセスの存在を10秒ごとに監視し、プロセスが終了した場合にシャットダウンを開始します（画面6）。

 1 while(1) {
 2     $procid = (Get-Process -ProcessName "cleanmgr" -ErrorAction SilentlyContinue).Id
 3     if ($procid.Length -eq 0) {
 4         Stop-Computer -Force
 5     } else {
 6         Write-Host "PID" $procid "is alive"
 7     }
 8     Start-Sleep -seconds 10
 9 }

▲「myprocmon.ps1」

画面6　「SilentCleanup」タスクのコマンドラインを手動で開始し、「myprocmon.ps1」を実行して「cleanmgr」プロセスの存在を監視する。プロセスが終了したら自動でシャットダウンが始まる

　スクリプトの「"cleanmgr"」の部分を他のプロセス名に変更することで、何かの処理が終わったらシャットダウンを開始するという、さまざまなケースに応用できるでしょう。

筆者紹介

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

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