続・Windows Updateの“更新遅い”問題を改善したい！──Windows Server 2016の場合［第2弾］：山市良のうぃんどうず日記（159）

Windows Server 2016の更新プログラムのインストールは、マシンスペック（特にディスクI/O）にも左右されますが、概して長い時間がかかります。時間がかかったとしても成功すればよいのですが、長い待ち時間の後、エラーで失敗したりすると……。本連載では何度も取り上げてきたテーマですが、今回は状況を改善できるかもしれない「オフライン更新」という方法を、通常のオンライン更新との比較実験でお送りします。

» 2019年08月14日 05時00分公開

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

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

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

筆者がWindows Server 2016の更新時間短縮に固執する理由

　Windows Server 2016ベースでシステムを構築し、運用している企業や組織のIT担当者は、OSやアプリケーションの更新管理に苦労していないでしょうか。Windows Server 2016のOS更新技術は、Windows 10 バージョン1607と共通であり、Windows 8.1やWindows Server 2012 R2以前から大きく変更されています。

　そのため、従来の更新方法では期待通りに運用できないこともあります。「Windows Update」の技術は、その後のWindows 10やWindows Serverで改善が継続して行われていますが、その改善がWindows Server 2016にフィードバック（バックポート）されることはあまり期待できません。

　「長期サービスチャネル（Long Term Servicing Channel：LTSC）」のWindows Serverの最新バージョンは、2018年11月リリース（正確には再リリース）の「Windows Server 2019」であり、2016年10月リリースのWindows Server 2016は一世代前のバージョンです。それでも筆者がWindows Server 2016の更新の問題に固執するのは、このバージョンがLTSCであり、2027年1月まで更新プログラムのサポートが続くからです。

　Windows Server 2016ベースでシステムを構築し、運用している場合は、この先もしばらくはWindows Server 2016の更新管理と向き合うことになります。まだ先のことですが、2022年1月にメインストリームサポートが終了し、延長サポートに入る頃には、現行システムの今後について検討を始めましょう。

　本連載第151回では、Windows Server 2016の更新プログラムのインストールに異様に長い時間がかかったり、エラーで失敗したりする原因の一つとして「コンポーネントストア」の問題と、その修復やクリーンアップの方法を紹介しました。また、時間を長引かせている要因の可能性として、未完のクリーンアップタスク（「\Microsoft\Windows\Servicing\StartComponentCleanup」および「\Microsoft\Windows\DiskCleanup\SlientCleanup」）、.NET Frameworkの更新の影響による再コンパイル処理について指摘しました。

Windows Updateの“更新遅い”問題を改善したい！ ─ Windows Server 2016の場合（本連載第151回）

更新時間を短縮できるかもしれないもう一つのヒント――ウイルス対策の除外設定

　Windows Server 2016では、更新プログラムのインストールとは関係ないタイミングで、通常のシャットダウンや再起動に時間がかかることがあります。毎月、Windows Server 2016を更新していると、「\Microsoft\Windows\Servicing\StartComponentCleanup」タスクによるコンポーネントストアのクリーンアップが最後まで完了していないことが影響しているのではないかと筆者は考えています。

　「タスクスケジューラ」で「\Microsoft\Windows\Servicing\StartComponentCleanup」タスクの実行履歴を確認し（「タスクの履歴」の有効化が必要）、タスクが強制終了を繰り返しているようであれば（タイムアウトに到達またはシャットダウンなどの理由で）、「タスクを停止するまでの時間」を既定の「1時間」から「4時間」などに変更してみると状況が改善するかもしれません。

　もう一つ、状況を改善できる可能性がある設定に、「ウイルス対策ソフトの除外設定」があります。Windows Server 2016で毎月行われる累積更新プログラムのインストールでは、ダウンロードされた更新プログラムのパッケージとインストール済みの更新ファイルから、数万個に及ぶファイルやディレクトリがディスクの一時的な場所に展開され、最終的にコンポーネントストア「C:\Windows\WinSxS」が更新されます。

　コンポーネントストアや一時的な展開場所を除外設定に追加することで、更新されたファイルのダウンロードと展開に対してウイルス検査が行われなくなり、I/O処理の改善が期待できます。筆者が追加設定している除外設定は、以下の4つの場所です。

C:\Windows\CBSTemp

C:\Windows\Servicing

C:\Windows\SoftwareDistribution

C:\Windows\WinSxS

　Windows Server 2016は標準で「Windows Defenderウイルス対策」を備えており、他のウイルス対策ソフトがインストールされておらず、明示的に無効にしていない限り、有効になっています。Windows Defenderの除外設定は、「設定」アプリの「更新とセキュリティ」→「Windows Defender」を開き、「除外」から編集できます。Windows PowerShellで次のコマンドラインを実行して追加することも可能です（画面1）。

Add-MpPreference -ExclusionPath "C:\Windows\CbsTemp"
Add-MpPreference -ExclusionPath "C:\Windows\Servicing"
Add-MpPreference -ExclusionPath "C:\Windows\SoftwareDistribution"
Add-MpPreference -ExclusionPath "C:\Windows\WinSxS"

画面1　更新プログラムのインストールで大量のファイルI/Oが行われる一時ディレクトリとコンポーネントストアをウイルス対策から除外する

Windows回復環境（WinRE）からのオフライン更新という方法

　Windowsの「Windows Update（wuauserv）」サービスを利用した更新プログラムのインストールを「オンライン更新」と呼ぶとしたら、実行中でないWindowsのイメージに対して更新プログラムをインストールする方法を「オフライン更新」と呼ぶことにします（本稿内において）。

　「設定」アプリの「更新とセキュリティ」→「Windows Update」、Server Coreの「Sconfig」ユーティリティー（デスクトップエクスペリエンスでも利用可）→「6）更新プログラムのダウンロードとインストール」、そして「Windows Update Agent（WUA） API」の自作スクリプトによる更新プログラムのインストールはオンライン更新です。

　対してオフライン更新とは、イメージ展開のためのWindowsイメージ（WIMファイル）、仮想マシンの仮想ハードディスク（VHD／VHDXファイル）、あるいはメンテナンス用の独立したOS環境である「Windows回復環境（Windows Recovery Environment：WinRE）」で起動したサーバ／PCのローカルディスク上のOSボリュームに、「DISM」コマンドを利用して更新プログラムをインストールする方法です。

　Windows Server 2016デスクトップエクスペリエンスの場合は、「設定」アプリの「更新とセキュリティ」→「回復」を開き、「PCの起動をカスタマイズする」の「今すぐ再起動する」をクリックします。その後、「オプションの選択」画面が表示されたら「トラブルシューティング」→「詳細オプション」→「コマンドプロンプト」の順番に選択することで、WinREのコマンドラインを起動することができます（画面2）。

画面2　オフライン更新の方法で更新プログラムをインストールするために、WinREの「コマンドプロンプト」でサーバを起動する

　Server Coreインストールの場合は、次のコマンドラインを実行することで「オプションの選択」画面に入ることができます。この方法は、デスクトップエクスペリエンスでも使えます。

reagentc /boottore
shutdown /r /t 0

　事前にオンラインのWindows Server 2016環境で、「Microsoft Updateカタログ」サイトから更新プログラム（.msu）をWinREからアクセス可能な場所（例えば、オンラインのWindows Server 2016の「C:\Work」）にダウンロードしておき、WinREのコマンドプロンプトで起動し直したら、次のコマンドラインを実行することで更新プログラムをインストールできます。

DISM /Image:<オフラインイメージのドライブ名:\> /Add-Package /PackagePath:<更新プログラム（.msu）のパス> /ScratchDir:<ローカルディスク上の任意の一時ディレクトリのパス>
WPEUTIL REBOOT

対決！　オンライン更新 vs. オフライン更新――更新時間

　オンライン更新の場合、更新の負荷によるサーバ性能の低下や、更新を完了するための再起動に伴うダウンタイムが発生します。Windows Server 2016では、それが安定運用を阻害する一因になることがあります。WinREによるオフライン更新なら、業務時間外など、許容できる範囲の少ないダウンタイムで更新を完了できるかもしれません。

　2019年7月の定例更新が完了した状態（KB4507460、ビルド14393.3085）と同じ環境（仮想マシンのスナップショットを利用）に対し、その翌週にリリースされた累積更新プログラム（KB4507459、14393.3115）を通常のオンライン更新とWinREによるオフライン更新でインストールし、完了するまでを比較してみました。

　以下の画面3～7は、稼働中のWindows Server 2016に対するオンライン更新（画面左）と、既にWinREで起動したオフラインのWindows Server 2016に対するオフライン更新（画面右）を同時に開始したとして、ほぼ同じ経過時間の進行状況を並べたものです。オフライン更新のための更新プログラムは、事前にダウンロード済みの状態です。

画面3　同じ更新状態のWindows Server 2016に対して、通常のオンライン更新（画面左）とWinREからのオフライン更新（画面右）を同時にスタートしたと想定

画面4　8分経過。オンライン更新はダウンロード5％、オフライン更新はインストール1％完了

画面5　60分経過。オンライン更新はまだダウンロード24％、オフライン更新は完了。WinREの再起動を開始

画面6　再起動を開始したオフライン更新の方は、「更新プログラムを構成しています XX％完了」の表示はなく、2分とかからずに起動完了（オフライン更新を開始したのは「10:50」）

画面7　70分経過。オンライン更新のダウンロードがようやく71％まで進む。オフライン更新の方はビルド番号（winver）で更新完了を確認

　このように、オフライン更新では、WinREで起動してから1時間で更新を完了できました。一方、オンライン更新は、ダウンロードが完了し、インストールの準備が始まったのが30分後（更新開始から90分後）、再起動が要求されたのがその25分後（更新開始から115分後）、再起動して「更新プログラムを構成しています 100％完了」まで進み完了するまで、さらに55分（更新開始から170分）かかりました。また、再起動を開始してから30分以上、「Windowsの準備をしていますコンピューターの電源を切らないでください」と表示される、変化のない状態が続きました。

　今回のテストでは、オフライン更新はオンライン更新の3分の1の時間で完了しました。また、サーバを利用できないダウンタイムはほとんど変わりませんでした。緊急に対応する必要があるものの、性能低下は許容されず、停止できる時間が限られている場合、オフライン更新は選択肢の1つになるのではないでしょうか。

　ただし、オフライン更新はWinREを利用するため、クラウドのIaaS環境では利用できません。Microsoft AzureのIaaS環境はWinREの使用をサポートしていません（シリアルコンソールを使用したWindows Server 2016の起動オプションの選択は可能ですが、別OSであるWinREを起動し、対話的にアクセスする方法は存在しません）。

対決！　オンライン更新 vs. オフライン更新――ダウンロードサイズ

　最後に、オンライン更新とオフライン更新、それぞれでの更新プログラムのダウンロードサイズを比較してみましょう。Microsoft Updateカタログからダウンロードした更新プログラムのサイズは約1.38GBでした（画面8の右）。これは、累積更新プログラムのフルパッケージのサイズともいえます。

画面8　オンライン更新（画面左）とオフライン更新（画面右）のダウンロードサイズの比較。オンライン更新の「高速インストール」のダウンロードサイズは10分の1、でもダウンロードにかかる時間は10倍という皮肉

　一方、オンライン更新では「高速インストール（Express Install、Express Update）」という最適化技術によって、累積更新プログラムに累積された更新ファイルのうち、まだインストールされていないものが選択的にダウンロードされます。オンライン更新でダウンロードが完了してからネットワークインタフェースの受信バイト数を確認してみると、ダウンロードサイズは150MB程度でした。これが前回更新からの差分というわけです。

　Microsoft Updateカタログから手動でダウンロードする場合、10分もかからずダウンロードできましたが、オンライン更新ではダウンロードが完了するまでに開始から90分かかりました。繰り返しますが実際にダウンロードされた合計サイズは150MB程度です。「高速インストール」はネットワーク帯域には優しい技術ですが、その名前は実に皮肉なものです。Windows Server 2016ではこのフェーズが遅々として進まず、“本当に動いているの？”と思いたくなります。

ダウンタイムを最小化するためのその他の考慮事項

　Microsoftはサポート対象のWindowsに対して、毎月第2火曜日（日本ではその翌日）に新たなセキュリティ修正を含む累積更新プログラム（Windows 8.1／Server 2012 R2以前はセキュリティマンスリー品質ロールアップ、Monthly Rollupという名前）を重要な更新プログラム（セキュリティ問題の修正プログラム）としてリリースしています。

　そして、その翌週または翌々週に、翌月の第2火曜日に予定されている修正を含み、新たなセキュリティ修正を含まない累積更新プログラムのプレビュー（Windows 8.1／Server 2012 R2以前はマンスリー品質ロールアップのプレビュー、Preview of Monthly Rollupという名前）をオプションの更新プログラムとしてリリースしています。

　通常、安定性とセキュリティ対策のためには、第2火曜日の累積更新プログラムを計画的にインストールすることで、更新管理に伴うダウンタイムを最小化できます。「計画的」とは、更新プログラムを評価した上で、「Windows Server Update Services（WSUS）」やその他の更新管理ツールを使用して業務に影響しないように展開するということです。

　Windows Server 2016の累積更新プログラムも同様のリリースサイクルに従いますが、Windows Server 2016のWindows Updateには重要な更新プログラムとオプションの更新プログラムを区別する機能がなく、どちらもWindows Updateの自動更新、手動更新で配布されます。

　Windows Server 2016の更新に伴うダウンタイムを最小化するには、これらの更新プログラムをきちんと区別し、必要のないオプションの更新プログラムを配布しないように管理することが重要になります。もちろん、緊急のセキュリティ更新プログラムや、特定の不具合の早急な解消を目的とした更新プログラムの場合は除きます。なお、通常、オプションの更新プログラムはWSUSには同期されないため、WSUSに手動でインポートしない限り配布可能にはなりません。

　また、ツールを使って更新管理を行う場合は、Windows Server 2016に対する更新プログラムのインストールやそれに伴う再起動のため、長い時間がかかることも覚悟しておくべきでしょう。

　例えば、Azureの「Update Management」サービスはAzure上の仮想マシンやオンプレミスのサーバに対して更新プログラムのインストールと再起動をスケジュール管理できますが、既定のメンテナンス期間「120分」（最後の30分は再起動のために確保されています）はWindows Server 2016には全く足りないでしょう（画面9）。

画面9　Update Managementサービスのメンテナンス期間は、更新プログラムのインストール開始から再起動が完了するまで待つ時間。既定の「120分」は、Windows Server 2016には足りない

筆者紹介

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

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